Why does SPF alignment show as 0% on Validity, even when SPF passes?
Updated on 5 Oct 2026: We clarified SPF alignment checks and added a DMARC report example for diagnosing 0% results.
SPF alignment can show as 0% on Validity even when SPF passes because those are different checks. SPF passing means the sending IP was authorised by the domain used in the SMTP envelope sender. SPF alignment means that same envelope sender domain also matches, or shares the same organisational domain as, the visible From domain.
That means 100% SPF pass and 0% SPF alignment is possible. It usually means your email service provider is using its own bounce or return-path domain, while your visible From address uses your brand domain. Validity is then reporting a real DMARC alignment outcome, not saying SPF authentication failed.
The practical question is whether DKIM is aligned. DMARC only needs one path to pass: SPF must pass and be aligned, or DKIM must pass and be aligned. If aligned DKIM is carrying DMARC, 0% SPF alignment can be acceptable. If neither mechanism supplies an authenticated, aligned domain, DMARC fails.
SPF pass and DMARC pass are different
A 0% SPF alignment result points to the envelope domain first. It does not prove that SPF is broken. Check the Return-Path, also called the bounce domain, because that is usually the domain SPF evaluates. Then compare it with the header From domain that the recipient sees.
- SPF pass: The sending IP is authorised for the envelope sender domain.
- SPF alignment: The envelope sender domain matches the visible From domain under DMARC rules.
- DMARC pass: Either SPF or DKIM passes and has domain alignment with the visible From domain.
- Validity 0%: The selected view reports no aligned SPF at its displayed precision. Check the underlying message counts to confirm an exact zero.
Read all results together
Read SPF pass, SPF alignment, DKIM pass, DKIM alignment, and the DMARC result together. Disposition describes the policy action, not whether authentication passed. A domain can have clean SPF authentication and still have no SPF alignment at all.
- Expected state: SPF passes on the vendor domain, DKIM passes on your domain, and DMARC passes through DKIM.
- Risky state: SPF passes on the vendor domain, DKIM uses a vendor domain, and DMARC fails.
Why SPF can pass without SPF alignment
SPF does not check the domain in the visible From header. For DMARC, the relevant identity is the SMTP MAIL FROM (RFC5321.MailFrom), also called the envelope sender and usually exposed in message headers as Return-Path or smtp.mailfrom. If a bounce message has a null reverse path, SPF derives the MAIL FROM identity as postmaster at the HELO or EHLO domain. A separate HELO-only SPF pass does not replace a nonempty MAIL FROM identity for DMARC.
SPF checks the MAIL FROM domain, then DMARC compares it with the visible From domain.
In relaxed alignment, the authenticated domain and visible From domain have the same organisational domain. A bounce domain like bounce.example.com normally has relaxed alignment with example.com. In strict alignment, the domains must match exactly. Relaxed SPF alignment is the default unless the DMARC record says aspf=s. The valid strict setting is aspf=s, not aspf=strict.
|
|
|
|---|---|---|
SPF pass | Sending IP authorised for the MAIL FROM domain | Requires domain alignment to satisfy DMARC |
SPF pass with alignment | Authenticated MAIL FROM domain compared with From | Satisfies DMARC |
DKIM pass with alignment | Validated DKIM d= domain compared with From | Satisfies DMARC |
DMARC pass | At least one passing, aligned authentication path | Does not guarantee inbox placement |
How SPF pass, SPF alignment, DKIM alignment, and DMARC relate.
Keep SPF authentication and alignment separate when diagnosing reports. The names sound similar, but they answer different questions.
How current DMARC rules affect alignment
RFC 9989 is the current Standards Track DMARC specification and obsoletes RFC 7489 and RFC 9091. SPF must pass with an aligned authenticated identifier, or DKIM must pass with an aligned signing domain. The standard changes organisational-domain discovery, not the need for a passing, aligned domain.
- Relaxed alignment: Receivers implementing RFC 9989 use a bounded DNS Tree Walk to determine organisational domains. Legacy implementations use the Public Suffix List method in RFC 7489; do not assume every receiver has switched.
- Strict alignment: Exact domain equality still decides the result, so the tree-walk change does not affect a strict match.
- Alignment settings: aspf controls SPF alignment and adkim controls DKIM alignment. Both default to relaxed mode (r); strict mode uses s.
- Aggregate data: RFC 9990 retains the distinction between DMARC-evaluated SPF and DKIM fields in policy_evaluated and raw authentication results in auth_results. That distinction also existed in RFC 7489.
What this means for a 0% result
Receivers using different organisational-domain discovery methods can disagree at some domain boundaries. An unrelated vendor MAIL FROM domain and a brand From domain remain unaligned under either method. Confirm the authenticated domain and the receiver's evaluated alignment result.
Why Validity reports 0% SPF alignment
A 0 percent SPF alignment view in Validity is common when a domain sends through platforms that authenticate SPF with their own return-path domain unless a custom bounce domain has been configured. This often appears in marketing automation and transactional sending setups where the visible From domain has been branded but the envelope sender remains under the provider.
Illustrative Validity report with SPF pass at 100%, SPF alignment at 0%, and aligned DKIM passing DMARC.
Check report scope before treating 0% as an exact statement about every message. Aggregate records group messages by source IP, authentication identifiers, and evaluated outcome, while a product screen can combine records across a source or time range. Check the From domain, source, and reporting period filters. If the display rounds percentages, a small aligned share can appear as 0%; the underlying counts establish the actual result.
Forwarding creates another pattern. If the forwarder changes the sending IP, SPF often fails. If it uses Sender Rewriting Scheme (SRS), SPF can pass for the forwarder's domain but remain unaligned with the original From domain. DKIM can still carry DMARC when the signed content survives unchanged. ARC can explain a receiver policy override, but it does not turn an unaligned SPF identity into an aligned one.
What Validity is likely showing
- SPF pass: The vendor return-path domain authorised the sending IP.
- Alignment 0%: The authenticated MAIL FROM domain fails the published aspf alignment requirement, or the summary needs checking against message counts.
- DMARC pass: When SPF is unaligned, a passing, aligned DKIM signature supplies the DMARC pass.
What to verify before fixing
- Envelope domain: Check the Return-Path or smtp.mailfrom value.
- DKIM domain: Check a passing signature's d= domain against the From domain under the published adkim mode.
- Report scope: Confirm the view is not filtered to one unaligned stream.
How to confirm the cause
The fastest check is to send a real message through the same source and inspect the raw headers. Use the Authentication-Results header added by the receiving mailbox's trusted server, plus Return-Path and From; earlier or sender-supplied results are not reliable evidence of that receiver's verdict. If the message has gone through forwarding or security rewriting, use a fresh mailbox that receives the original message directly.
Header pattern that explains 0% SPF alignmenttext
Return-Path: <bounce@esp-mail.example.net> From: Brand <news@example.com> Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=esp-mail.example.net; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
In that example, SPF passes for esp-mail.example.net, but the visible From domain is example.com. SPF is authenticated, but SPF is not aligned. DMARC still passes because DKIM uses example.com as the signing domain.
- Check From: Record the domain after the @ in the visible From address (RFC5322.From).
- Check envelope: Record the Return-Path or smtp.mailfrom domain. For an empty reverse path, check the HELO or EHLO domain used to derive the MAIL FROM identity.
- Check DKIM: Record each passing signature's d= domain and compare it under adkim. One passing, aligned signature is enough even if another signature fails or uses a vendor domain.
- Check DMARC: Pair each authentication result with its alignment result to identify the path that satisfies DMARC.
Suped's DMARC checker validates the published policy. Suped's domain health checker reviews DNS authentication settings before sender changes. A delivered message or aggregate report is still needed to prove which MAIL FROM and DKIM signing domains the sender actually uses.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Read the SPF fields in a DMARC report
A DMARC aggregate report (RUA) records raw SPF authentication separately from the SPF result used for DMARC. RFC 9990 defines these fields. In this illustrative record, the provider's MAIL FROM domain passes SPF, but it differs from the visible From domain, so the DMARC-evaluated SPF result is fail.
Illustrative aggregate record: SPF passes without alignmentxml
<record> <row> <source_ip>192.0.2.10</source_ip> <count>100</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> <envelope_from>esp-mail.example.net</envelope_from> </identifiers> <auth_results> <dkim> <domain>example.com</domain> <selector>news</selector> <result>pass</result> </dkim> <spf> <domain>esp-mail.example.net</domain> <result>pass</result> </spf> </auth_results> </record>
- auth_results/spf/result is pass: the sending IP is authorised for esp-mail.example.net.
- row/policy_evaluated/spf is fail: SPF does not provide a passing, aligned identity for DMARC.
- row/policy_evaluated/dkim is pass: a verified DKIM signature has alignment, so DMARC passes.
- row/count is 100: this record describes 100 messages, not one. Weight percentages by message count rather than by XML row count.
The none disposition is a policy action, not proof of a DMARC pass. When both DMARC-evaluated fields are fail, DMARC fails even if disposition is none because p=none applies or the receiver overrides enforcement. To reproduce a source's SPF alignment percentage, divide message counts with DMARC-evaluated SPF pass by the total reported message count in the same scope, then multiply by 100.
How to fix SPF alignment
Fixing this means configuring an authenticated MAIL FROM domain that satisfies the published aspf mode, or relying on consistently passing, aligned DKIM for that source. Start in the sending platform: adding an IP to the From domain's SPF record does not correct a vendor-owned MAIL FROM domain.
An SPF include does not fix a domain mismatch
Adding more includes to your From domain's SPF record does not create alignment when the MAIL FROM domain is still owned by the vendor. SPF is checked at the actual MAIL FROM domain; a subdomain does not inherit its parent's SPF record. Unnecessary includes also consume the ten DNS-lookup-causing terms allowed during SPF evaluation. See RFC 7208 for SPF record lookup and processing limits.
- Configure bounce: Set a custom MAIL FROM, return-path, or bounce domain in the sending platform. Confirm the option applies to the sending identity and mail stream being tested.
- Publish DNS: Publish the CNAME, MX, or TXT records the sender specifies at the custom domain, and confirm the platform verifies the setup.
- Keep DKIM: Use a passing DKIM signing domain with relaxed alignment under adkim=r, or an exact From-domain match under adkim=s.
- Retest mail: Send fresh messages after DNS has propagated and inspect the actual MAIL FROM in trusted receiver headers. A configured setting alone does not prove the sender used it.
- Watch reports: Compare message counts in reporting periods after the change. Older aggregate reports still describe the previous configuration.
The example below uses p=none for monitoring and a placeholder reporting address. Preserve an existing quarantine or reject policy while correcting the sender; changing p does not fix SPF alignment. Use your own aggregate-report address when publishing a record.
Illustrative monitoring policy with relaxed alignmenttext
v=DMARC1; p=none; rua=mailto:dmarc@example.com; aspf=r; adkim=r
Suped's DMARC monitoring product groups report data by sending source, shows where SPF passes without alignment, and identifies whether passing, aligned DKIM satisfies DMARC. After a custom MAIL FROM change, compare the same source's alignment and message counts in reports covering the new configuration. See DMARC monitoring for that workflow.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For teams managing policy changes across many domains, Suped's Hosted DMARC product can stage policy changes without repeated manual DNS edits. Keep the sender's custom return-path work separate from enforcement changes so each result is easy to verify.
When 0% SPF alignment is acceptable
A 0% SPF alignment number is not automatically a deliverability problem. It is acceptable when DKIM consistently passes with alignment, DMARC is passing, and the source is intentionally configured to rely on DKIM alignment. It deserves action when DKIM alignment is missing, when DMARC failures appear for the same source, or when the sender requires SPF alignment for a compliance reason.
How to read SPF alignment percentages
These values describe the selected traffic. They are not universal deliverability scores.
All reported mail aligned
100%
SPF passes with alignment for all messages in the selected scope.
Mixed alignment
>0% and <100%
The selected traffic contains different envelope domains or sender configurations.
No reported alignment
0%
Check aligned DKIM and the underlying message counts before deciding on a fix.
A dedicated IP does not determine SPF alignment. SPF authorises that IP for the MAIL FROM domain, while DMARC compares authenticated domains. The examples below assume SPF passes and the subdomains share example.com as their organisational domain.
|
|
|
|
|---|---|---|---|
example.com | esp-mail.example.net | Fail | Fail |
example.com | bounce.example.com | Pass | Fail |
news.example.com | bounce.example.com | Pass | Fail |
news.example.com | news.example.com | Pass | Pass |
The same MAIL FROM domain has different outcomes under relaxed and strict SPF alignment.
Practical SPF alignment checks
Best practices
Inspect raw headers before changing DNS; the envelope domain explains most SPF alignment gaps.
Treat SPF pass and SPF alignment as separate results when reviewing DMARC report data.
Verify aligned DKIM for each sender before accepting 0% SPF alignment as harmless.
Common pitfalls
Adding SPF includes to the From domain does not fix alignment when MAIL FROM differs.
Assuming DMARC needs both SPF and DKIM aligned leads to the wrong remediation plan.
Reading a filtered report view as whole-domain truth can hide mixed sender behaviour.
Expert tips
Ask vendors for custom return-path support, not only sender IP ranges or SPF include text.
Use relaxed alignment deliberately; strict SPF alignment breaks many subdomain setups.
Check DKIM d= alignment when DKIM passes but DMARC still fails for a daily stream.
Marketer view
Marketer from Email Geeks says 0% SPF alignment is possible when the sending platform uses a different envelope domain.
2024-02-03 - Email Geeks
Marketer view
Marketer from Email Geeks says several email platforms show SPF pass without SPF alignment unless custom bounce handling is configured.
2024-02-03 - Email Geeks
Frequently asked questions
Yes. SPF passes when the sending IP is authorised for the envelope sender domain. SPF alignment fails when that envelope sender domain does not match the visible From domain under DMARC rules.
Not always. DMARC passes if DKIM passes and the DKIM signing domain is aligned with the visible From domain. DMARC only needs one aligned authentication path.
Fix it when DMARC depends on SPF, when DKIM alignment is unreliable, or when your program requires branded return-path domains. If aligned DKIM is stable, it can be acceptable.
Compare the From domain with the Return-Path or smtp.mailfrom value in the receiving server's trusted Authentication-Results header. Apply the published aspf mode: relaxed alignment requires a shared organisational domain, while strict alignment requires an exact match. For an empty reverse path, SPF derives the MAIL FROM identity using the HELO or EHLO domain.
Yes. DKIM must pass and have alignment under the published adkim mode. A passing vendor-domain signature alone does not satisfy DMARC. If a message has multiple signatures, one passing signature with an aligned d= domain is enough.
Confirm the custom domain is verified and enabled for the same sending identity and mail stream. Inspect a new direct message to establish which MAIL FROM domain is actually used, then compare aggregate reports covering traffic after the change. With aspf=s, a branded bounce subdomain still fails alignment when the From domain differs.
