What is the difference between SPF authentication and alignment?
Updated on 21 Oct 2026: We clarified SPF domain matching and added a practical way to distinguish authentication from alignment in DMARC reports.
SPF (Sender Policy Framework) 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?
For DMARC to pass through SPF, 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.
Illustrative SPF record for the MAIL FROM subdomainDNS
bounces.example.com. 3600 IN TXT "v=spf1 include:mail.example.net -all"
In this example, include:mail.example.net delegates an authorization check; the SPF identity remains bounces.example.com. SPF records are not inherited by subdomains, so an SPF record at example.com does not automatically cover bounces.example.com. These lookup rules are defined in RFC 7208.
- 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. These are the RFC5321.MailFrom and RFC5322.From domains, respectively. Alignment compares domain names, not the parts before the @ sign or display names.
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. The DMARC tag aspf=r selects relaxed SPF alignment and aspf=s selects strict SPF alignment; omitting aspf defaults to relaxed. The adkim tag controls DKIM alignment independently. 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, none, temperror, or permerror.
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.
- Organizational boundary: A separate subdomain DMARC record does not automatically create a new organizational domain; psd=n explicitly marks that boundary under RFC 9989.
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. A separate HELO/EHLO SPF pass does not replace MAIL FROM authentication for ordinary mail with a nonempty reverse path.
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. For the DKIM route, a valid signature must have a d= signing domain that matches the visible From domain under adkim. Configuring both SPF and DKIM gives legitimate mail a second route when forwarding or message changes break one method. A p=none policy requests no DMARC enforcement action for failures; it does not change the pass criteria. A DMARC pass does not guarantee inbox placement.
|
|
|
|
|---|---|---|---|
Pass | Yes | Yes | SPF meets both requirements. |
Pass | No | No | DMARC needs passing DKIM with domain matching. |
Any non-pass result | Yes | No | Matching domains cannot rescue SPF authentication. |
Any non-pass result | No | No | SPF meets neither requirement. |
Common SPF and DMARC outcomes
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. For legitimate mail on a domain you control, fix SPF authorization and then confirm domain matching.
How to identify SPF authentication and alignment in email headers
Read the Authentication-Results header added by your receiving provider, following the trust model in RFC 8601. 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; dkim=none; 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 example also has no DKIM signature, so neither route supplies a DMARC pass. 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 correctly configured for the MAIL FROM domain. Manually adding a Return-Path header does not change the sending platform's SMTP MAIL FROM identity.
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; dkim=none; 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 read SPF results in DMARC reports
DMARC aggregate reports (RUA) expose authentication and DMARC evaluation separately. RFC 9990 defines these fields, so different SPF results in one record are not contradictory.
|
|
|---|---|
auth_results/spf/domain | The domain used for SPF authentication. |
auth_results/spf/result | The raw SPF result. A pass confirms authorization for that domain. |
identifiers/header_from | The visible From domain used for DMARC comparison. |
row/policy_evaluated/spf | The SPF result for DMARC. A pass requires authentication and domain matching. |
SPF authentication and domain matching in aggregate report XML
For example, auth_results/spf/result=pass with row/policy_evaluated/spf=fail means SPF authentication succeeded but the domain did not satisfy DMARC alignment. Check row/policy_evaluated/dkim before concluding that DMARC failed; a pass there supplies the DKIM route.
How to troubleshoot SPF authentication and alignment
Troubleshooting works best as two separate checks. First, check authorization for the MAIL FROM domain. Second, check its match with the visible From domain. Keeping those checks separate stops teams from changing the wrong DNS record.
- Identify the SPF domain: Read smtp.mailfrom in the receiver's Authentication-Results header and confirm it against Return-Path.
- Check SPF authorization: For a legitimate sending source, confirm the sending IP is covered by the SPF record for that MAIL FROM domain.
- Compare domains: Compare the SPF domain with the visible From domain under relaxed or strict mode.
- Review DKIM too: Check DKIM verification and the d= signing domain; a passing signature with domain matching can satisfy DMARC.
- Watch reports: Compare raw SPF authentication with the DMARC SPF evaluation in aggregate reports to find domain mismatches.
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 identifies sending sources, separates authentication failures from alignment failures, and provides remediation steps. Use those results to review each legitimate source when a sending service changes its Return-Path domain.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For ongoing operations, use Suped's DMARC monitoring to review results by sending source after configuration changes. Confirm legitimate sources pass DMARC before tightening the enforcement policy.
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 authorization: The MAIL FROM domain belongs to you, but its SPF record does not authorize the sending IP.
- Lookup limit: Evaluating more than 10 DNS-querying SPF mechanisms and modifiers, including nested includes, returns permerror.
- Duplicate SPF records: Publishing more than one v=spf1 TXT record at the same DNS name returns permerror. Merge authorizations into one SPF record.
- Forwarding: A forwarded message often arrives from a new IP that the original SPF record did not authorize. Rewriting MAIL FROM to the forwarder's domain can make SPF pass, but does not establish SPF alignment with an unrelated original From domain. RFC 7960 describes both cases.
- 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.
Assuming SPF is inherited leaves custom bounce subdomains without the required authorization.
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 view
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 view
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
Frequently asked questions
Yes. SPF can pass for the MAIL FROM domain while that domain does not match the visible From domain. DMARC does not pass through SPF in that case. The message can still pass DMARC through a valid DKIM signature with a matching signing domain.
A domain can appear to match, but DMARC cannot use SPF unless SPF authentication passes. Matching without proof is not a meaningful DMARC pass.
No. SPF checks the SMTP MAIL FROM domain, often seen as Return-Path after delivery. DMARC then compares that authenticated domain with the visible From domain.
For direct mail, configure SPF authentication with domain matching where supported. DMARC needs either SPF or DKIM to pass with a matching domain, so forwarded mail can still pass through DKIM when SPF fails.
If SPF authentication fails for a legitimate source, check authorization on its actual MAIL FROM domain. If SPF already passes, fix the domain mismatch in the sending platform or configure DKIM with a matching signing domain. Adding an include to the visible From domain does not repair a vendor-owned MAIL FROM mismatch.
