What is the difference between SPF authentication and alignment?
Updated on 13 Aug 2026: We updated this guide for RFC 9989, including DNS Tree Walk alignment and null reverse-path handling.
SPF authentication and SPF alignment answer two different questions. SPF authentication asks: did this message come from an IP address that the SMTP MAIL FROM domain has authorized? SPF alignment asks: does the domain that passed SPF match the domain in the visible From header closely enough for DMARC?
Authentication is proof and alignment is matching. Proof without matching is useful, but it does not satisfy DMARC through SPF. Matching without proof has no real value, because the receiver has not verified that the sending IP was allowed by the SPF domain. For SPF to pass DMARC, the message needs both: SPF authentication must pass, and the authenticated SPF domain must match the visible From domain under the domain matching mode in the DMARC record.
The short answer
SPF authentication checks the SMTP MAIL FROM domain, often shown as Return-Path after delivery. SPF alignment compares that authenticated domain with the visible From domain. DMARC gives SPF credit only when both checks pass.
What SPF authentication checks
SPF authentication happens during the SMTP transaction. The receiving mail server looks at the connecting IP address and the MAIL FROM domain, often shown later as Return-Path. It then checks the SPF TXT record published by that domain. If the record authorizes the connecting IP, SPF authentication passes.
The important detail is that SPF does not authenticate the visible From domain by itself. A person can see mail from billing@example.com, while the SPF check uses bounces.sender-service.example. That setup can produce a normal SPF pass while still failing SPF alignment for example.com.
SPF authentication exampleDNS
bounces.example.com. 3600 IN TXT "v=spf1 include:mail.example.net -all"
- Domain checked: SPF checks the MAIL FROM domain, not the visible From domain.
- IP checked: SPF compares the connecting server IP with the mechanisms in the SPF record.
- Result meaning: A pass means the SPF domain authorized that server to send mail.
- Main caveat: A pass does not automatically mean the visible From domain received DMARC credit.
Flowchart showing how SPF authentication checks the sending IP against the envelope sender domain.
What SPF alignment checks
SPF alignment is a DMARC concept. After SPF authentication runs, DMARC checks whether the authenticated SPF domain matches the visible From domain. The visible From domain is the domain recipients see, so DMARC checks whether the authentication result connects back to that domain.
There are two SPF alignment modes. Relaxed alignment accepts the same organizational domain, so bounces.example.com can match example.com. Strict alignment requires the exact same domain, so bounces.example.com does not match example.com. Relaxed alignment is the default when the DMARC record omits aspf. A deeper explanation of relaxed domain alignment is useful when subdomains send mail.
DMARC alignment mode exampleDNS
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@example.com; " "aspf=r; adkim=r" )
Authentication
Authentication proves that the sending IP was allowed by the SPF domain.
- Checks: Connecting IP against the SPF record.
- Domain: SMTP MAIL FROM identity.
- Output: SPF pass, fail, softfail, neutral, or related result.
Alignment
Alignment checks whether the authenticated SPF domain matches the visible From domain.
- Checks: SPF domain against the Header From domain.
- Domain: Visible brand or sender domain.
- Output: Aligned or not aligned for DMARC.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
How relaxed alignment finds the organizational domain
RFC 9989 is the current DMARC standard and obsoletes RFC 7489. The relaxed and strict alignment outcomes remain familiar, but RFC 9989 changes how a receiver determines the organizational domain. It uses a bounded DNS Tree Walk for DMARC records instead of the older Public Suffix List method.
For a typical setup, mail.example.com and example.com still share the organizational domain example.com and have relaxed alignment. The DNS Tree Walk matters most for private suffixes, deeply nested domains, and organizations that publish DMARC records at several levels of the DNS hierarchy.
- Relaxed mode: The SPF-authenticated domain and Author Domain need the same organizational domain.
- Strict mode: The two domains must be identical, so no organizational-domain lookup is needed.
- Default mode: If aspf is absent, DMARC uses relaxed SPF alignment.
- Publishing practice: Publish explicit DMARC records for Author Domains that need separate administrative boundaries.
Null reverse-path mail
When SMTP uses a null reverse path such as MAIL FROM:<>, RFC 7208 defines the MAIL FROM identity as postmaster at the HELO domain. SPF can authenticate that derived identity, and DMARC compares its domain with the visible From domain.
Why both matter for DMARC
For DMARC, SPF only helps when SPF authentication passes and SPF alignment passes. If either side fails, DMARC cannot pass through SPF. DMARC uses OR logic across its two routes: aligned SPF or aligned DKIM can produce a DMARC pass. Within the SPF route, authentication and alignment are both required. Configuring both SPF and DKIM gives legitimate mail a second route when forwarding or message changes break one method.
|
|
|
|
|---|---|---|---|
Pass | Yes | Pass | Ready |
Pass | No | Fail | Proof only |
Fail | Yes | Fail | No proof |
Fail | No | Fail | Neither |
Common SPF and DMARC outcomes
This is where a lot of reporting confusion starts. A tool or report might show that the Return-Path domain resembles the From domain, while the SPF result is still fail. That does not create a useful DMARC pass. If the sending IP was not authorized by the SPF domain, the matching part cannot carry the message.
Do not treat matching as proof
A message can use a Return-Path domain that looks right and still fail SPF authentication. In that case, DMARC does not pass through SPF. Fix the SPF authorization first, then confirm alignment.
What DMARC needs from SPF
A simplified view of the two conditions required before SPF can satisfy DMARC.
SPF auth
Domain match
Missing
How this appears in real email headers
A simplified header tells the story. The SPF domain comes from the SMTP MAIL FROM identity and is often recorded in Return-Path after delivery. The visible From domain is what the recipient sees. DMARC compares the two after SPF has already produced a result.
Header pattern with SPF pass but no SPF alignmenttext
Return-Path: <bounce@sender-service.example> From: Example Billing <billing@example.com> Authentication-Results: mx.example; spf=pass smtp.mailfrom=sender-service.example; dmarc=fail header.from=example.com
In that example, SPF authentication passes because sender-service.example authorized the sending IP. SPF alignment fails because sender-service.example does not match example.com. The fix depends on the sending platform. You either configure a custom bounce or Return-Path domain under example.com, or you rely on aligned DKIM for DMARC while keeping SPF healthy for reputation and receiver checks.
Header pattern with SPF pass and SPF alignmenttext
Return-Path: <bounce@mail.example.com> From: Example Billing <billing@example.com> Authentication-Results: mx.example; spf=pass smtp.mailfrom=mail.example.com; dmarc=pass header.from=example.com
The second example passes SPF authentication and relaxed SPF alignment because mail.example.com and example.com share the same organizational domain. Under strict SPF alignment, the exact domain would need to match, so mail.example.com would not be enough for the visible From domain example.com.
How to troubleshoot the difference
Troubleshooting works best as two separate checks. First, prove the sender. Second, prove the domain match. Keeping those checks separate stops teams from changing the wrong DNS record.
- Find the Return-Path: Inspect headers and identify the MAIL FROM domain used for SPF.
- Check SPF authorization: Confirm the sending IP is covered by the SPF record for that domain.
- Compare domains: Compare the SPF domain with the visible From domain under relaxed or strict mode.
- Review DKIM too: A message can still pass DMARC when aligned DKIM passes.
- Watch reports: Use aggregate DMARC data to find sources that pass SPF but miss alignment.
If you need a quick DNS check, Suped's DMARC checker shows the policy tags that control alignment. For a broader view, the domain health checker checks SPF, DKIM, and DMARC together.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's DMARC reporting product turns these checks into a repeatable workflow. It identifies sending sources, separates authentication failures from alignment failures, assigns issue severity, and provides remediation steps. That helps when a domain uses several sending services and one quietly changes its Return-Path domain.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For ongoing operations, DMARC monitoring is more useful than a one-time check. The practical goal is to see every source, catch new failures, and move policy forward without blocking legitimate mail.
Common causes of SPF authentication and alignment problems
Most SPF confusion comes from outsourced sending. Marketing platforms, billing systems, CRMs, support desks, and internal apps often send with your visible From domain while using their own MAIL FROM domain. That can be acceptable if DKIM is aligned, but it surprises teams that expect SPF to carry DMARC by itself.
- Shared Return-Path: The sender authenticates with its own domain, so SPF passes but does not match your From domain.
- Missing include: The MAIL FROM domain belongs to you, but its SPF record does not authorize the sending IP.
- Lookup limit: SPF exceeds the DNS lookup limit, causing permerror instead of a clean pass.
- Forwarding: A forwarded message often arrives from a new IP that the original SPF record did not authorize.
- Strict mode: Strict SPF alignment fails when the authenticated subdomain differs from the visible From domain.
Best practical setup
Use a custom Return-Path under your domain when the sender supports it, publish the correct SPF record for that Return-Path domain, and configure DKIM with your domain as a second route to DMARC pass.
If DMARC fails even when SPF and DKIM appear to pass, inspect which domains passed. Authentication results without domain context can mislead you. The detailed pattern is covered in DMARC authentication failures, especially for systems that use vendor-owned MAIL FROM domains.
Views from the trenches
Best practices
Separate SPF proof from domain matching before changing DNS for any sender source.
Confirm the Return-Path domain first, because SPF does not check the visible From domain.
Use aligned DKIM as a second DMARC path, especially where forwarding affects SPF results.
Common pitfalls
Treating a domain match as a pass causes missed SPF failures in real authentication results.
Adding SPF includes to the From domain fails when the Return-Path uses a different domain.
Ignoring subdomain policy creates gaps when services send through custom bounce domains.
Expert tips
Read Authentication-Results with the header From and smtp.mailfrom values side by side.
Use relaxed SPF alignment for normal subdomain sending unless strict matching is required.
Track source-level results over time, since one vendor change can break SPF alignment.
Marketer from Email Geeks says SPF authentication cares about the Mail From domain, while alignment checks whether that domain matches the visible sender domain.
2019-10-08 - Email Geeks
Marketer from Email Geeks says passing SPF authentication is important, and passing with alignment is better when a team plans to enforce DMARC.
2019-10-08 - Email Geeks
SPF authentication vs alignment: the practical answer
SPF authentication is the sender proof check. SPF alignment is the domain matching check. DMARC needs both before SPF can pass DMARC. If SPF passes but alignment fails, the message is authenticated for the MAIL FROM domain only. If the domains match but SPF fails, there is no verified SPF proof to use.
The operational fix is to identify every legitimate sending source, configure SPF on the MAIL FROM domain each source uses, set up aligned DKIM wherever available, and monitor aggregate DMARC reports until the pattern is stable. Suped's DMARC reporting product groups results by source, separates authentication and alignment failures, alerts teams to changes, and tracks remediation across domains.
