SMTP is a conversation in plain text. Reading one is the fastest way to understand why email authentication had to be invented, because every identity in it is simply asserted by the sender and accepted by the receiver.
A real exchange
Lines beginning with a number are the server; the rest are the client. This is the whole protocol for delivering one message.
220 mx.recipient.org ESMTP ready EHLO mail.example.com 250-mx.recipient.org 250-STARTTLS 250 SIZE 52428800 MAIL FROM:<bounces@example.com> 250 2.1.0 Sender OK RCPT TO:<bob@recipient.org> 250 2.1.5 Recipient OK DATA 354 Start mail input; end with <CRLF>.<CRLF> From: "Alice" <alice@example.com> To: bob@recipient.org Subject: Invoice attached Hi Bob, the invoice is attached. . 250 2.0.0 Message accepted QUIT
Three identities, none of them proven
EHLO mail.example.com— the sending server naming itself. Per RFC 5321 §4.1.1.1, this should be the server’s own fully qualified domain name. Nothing enforces that. A server may say whatever it likes, and many say something wrong by accident.MAIL FROM:<bounces@example.com>— the envelope sender, also called the return-path. This is where a bounce would go. The recipient never sees it.From: "Alice" <alice@example.com>— inside the DATA section, part of the message rather than the envelope. This is the only address the recipient’s client will display.
Note that the envelope sender and the From: header are different addresses here, and the exchange is completely normal. That divergence is not suspicious — it is how bounce handling, mailing lists and most bulk senders work. It is also the crack that every authentication protocol in this course has to reason about.
Where the envelope stops
The envelope exists only during the SMTP conversation. Once the message is accepted, it is gone — except that the receiving server records the envelope sender into a Return-Path: header at delivery, per RFC 5321 §4.4. That header is the best evidence you have of the envelope sender in a message you are holding.
What the receiver has to work with
At the moment the receiving server must decide whether to accept this message, it knows: the connecting IP address, three names the client asserted, and nothing else. Of those, the IP address is the only fact — it cannot be forged without controlling the routing to it, because the TCP handshake completed.
That single reliable fact is what SPF is built on, and understanding that is enough to predict SPF’s limitations before you have read a word of its specification: it can only tell you about the connecting host, so it can only authorise the identity the connecting host claimed in the envelope.