How Email Delivery Actually Works

Every email you send has two separate identities, and almost no one outside email infrastructure knows they're different.

The envelope vs. the header

When a sending server hands a message to a receiving server, it first has a short SMTP conversation:

MAIL FROM:<bounces@sender-example.com>
RCPT TO:<you@your-domain.com>

That MAIL FROM is the envelope sender (also called the Return-Path) – it's where bounce notifications go, and it's the address SPF actually checks. It's metadata for mail servers, not something a mail client typically shows a person.

What you actually see in your inbox – the "From:" name and address – lives inside the message content, in the header block, written by the sending application itself:

From: "Billing Team" <billing@sender-example.com>
Subject: Your invoice is ready

Nothing about basic SMTP requires these two to match. A sending server can put anything it wants in the header From: – that's not a bug, it's how the protocol was designed in the 1980s, long before spam and phishing were a business risk anyone had to plan for.

Why that matters

This is the entire reason email spoofing is so easy without authentication: a sender can set the envelope to one domain and the visible header From: to a completely different one – yours. The receiving server has no built-in way to know that's wrong. It'll happily deliver a message that says it's from your CEO, sent from infrastructure that has nothing to do with your company.

SPF, DKIM, and DMARC exist specifically to close this gap – each checking a different piece of "does this message actually have the right to claim this identity," and DMARC specifically ties the result back to that visible header From: address people actually read. The rest of this course covers each one, in the order they build on each other.