SPF alignment: how SPF and DMARC work together

SPF alignment is the DMARC rule that connects an SPF result to the address a human actually sees. SPF validates the envelope sender domain (Return-Path), while recipients see the From header, and nothing in SPF itself requires the two to match. DMARC adds that requirement: an SPF pass only counts toward DMARC if the envelope domain aligns with the From domain. Misunderstanding this single rule produces the most common confusion in email authentication: mail that passes SPF and still fails DMARC.

Two senders in every message

Every email carries two sender identities. The envelope sender (MAIL FROM in the SMTP transaction, recorded as Return-Path) is where bounces go and is what SPF evaluates. The From header is what mail clients display. They legitimately differ all the time: bounce handling systems, ESPs with their own bounce processing, and mailing lists all set envelope senders on their own domains while the From header carries yours.

That gap is exactly what spammers exploited for years: pass SPF using a domain they own in the envelope, display your domain in the From header. SPF works as designed in that scenario and protects nothing the recipient can see. DMARC closes the gap by demanding alignment between the authenticated domain and the displayed one.

Relaxed and strict alignment

DMARC's aspf tag sets the comparison mode. Relaxed (aspf=r, the default) requires the two domains to share an organizational domain: bounce.mail.example.com aligns with example.com. Strict (aspf=s) requires an exact match: only example.com aligns with example.com. Relaxed is correct for nearly everyone, because production setups routinely use bounce subdomains, and strict alignment breaks them for no practical security gain in most threat models.

1From: news@example.com
2
3Return-Path: bounce@example.com          aligned (same domain)
4Return-Path: b-123@mail.example.com      aligned (same org domain)
5Return-Path: bounce@esp-platform.com     NOT aligned (different org domain)
6Return-Path: b-123@em.esp-platform.com   NOT aligned
7
8SPF can pass in all four cases. Only the first two help DMARC.

Why ESP defaults fail alignment

Out of the box, most ESPs and transactional providers use an envelope sender on their own platform domain so their systems can process your bounces. SPF passes, for their domain, and contributes nothing to your DMARC. The fix every serious platform offers is a custom bounce domain (also sold as custom Return-Path or domain authentication): a subdomain of yours, delegated to the provider, used as the envelope sender. After that, SPF passes for a domain that aligns with your From header.

Forwarding: where aligned SPF dies

When a message is forwarded, the forwarder retransmits it from their own servers. Your SPF record does not authorize those servers, so SPF fails (or the forwarder rewrites the envelope sender to their own domain, and SPF passes without alignment). Either way, aligned SPF is gone. This is inherent to how SPF works, and no record edit fixes it.

The consequence for DMARC strategy: never build enforcement on SPF alone. DMARC passes if either mechanism produces an aligned pass, and DKIM signatures travel inside the message, surviving normal forwarding. Aligned DKIM on every stream is the resilient leg; aligned SPF is the second witness that covers DKIM's own failure modes, like broken signatures after key rotation mistakes.

Getting to aligned SPF, stream by stream

For the fundamentals of how SPF itself evaluates, see the SPF overview; for placing records on subdomains correctly, the record syntax entry covers scope and placement rules.