How does SPF validation actually happen during SMTP?

SPF validation happens during the SMTP handshake, before any message content is transferred. Most people think of authentication as something that happens to the email itself, but SPF actually runs on the connection.

And Here's the sequence, step by step:

1. Connection established. Your sending mail server connects to the receiving server and introduces itself with a HELO or EHLO command. The receiving server notes the connecting IP address.

2. MAIL FROM command. The sending server specifies the envelope from address, something like MAIL FROM: <captain@deepcurrent.io>. This is the domain SPF validates. It's different from the "From:" header your recipient sees in their inbox. The receiving server extracts the domain part: deepcurrent.io.

3. DNS lookup. The receiving server queries DNS for a TXT record at deepcurrent.io that starts with v=spf1. This is where your published SPF record gets retrieved.

4. Mechanism evaluation. The server evaluates your SPF record left to right, checking each mechanism against the connecting IP. If it finds a match (say, ip4:203.0.113.5 matches the sending server), it stops and applies the result. The first match wins.

5. Result applied. The match result (pass, fail, softfail, neutral) is recorded in a "Received-SPF" header attached to the message. This result then feeds into DMARC, which checks whether the SPF-validated domain actually aligns with the visible "From" header.

All of this happens before the message body is transmitted. If SPF fails hard (-all), the receiving server can reject the connection outright. If it's a soft fail (~all), it accepts the message but flags it for spam filtering consideration.

One practical implication: because SPF validates the envelope from domain (not the visible "From"), forwarded email often breaks SPF. The forwarder's server IP isn't in your SPF record. This is one reason DKIM exists: it's a signature on the message content itself, which survives forwarding.