Should SPF hardfail be enforced if DMARC is in place?
Published 31 Jul 2025
Updated 12 Aug 2026
10 min read
Summarize with
Updated on 12 Aug 2026: We updated this guide for RFC 9989 and clarified when SPF softfail or hardfail fits a DMARC-protected domain.
No, receivers should not use SPF hardfail as an automatic rejection decision when DMARC applies. SPF hardfail is a useful authentication result, but the receiver should obtain the message, evaluate DKIM, compare authenticated domains with the visible From domain, and calculate DMARC before making a domain-policy decision. Normal spam and abuse filtering still applies after a DMARC pass.
Publishing -all is a separate choice. For most active sending domains protected by DMARC, ~all avoids early SPF-only rejection without weakening DMARC. -all remains appropriate for domains that send no email and for deliberate cases where the operator accepts the delivery risk.
If SPF fails against a record ending in -all but an aligned DKIM signature passes, DMARC passes. Rejecting at the SMTP MAIL FROM stage prevents that later result from being calculated, which is why SPF fail alone should not override an eventual DMARC pass.
Suped's DMARC monitoring separates sources that pass through SPF, sources that pass through DKIM, and sources that fail alignment. That report data supports sender inventory work and shows whether changing an SPF ending would affect legitimate mail.
How receivers should handle SPF hardfail
A receiver should delay any DMARC-based disposition until DMARC can be evaluated. SPF checks the envelope sender during the SMTP transaction. DMARC evaluates the visible From domain after the headers and DKIM signature are available.
- Do not reject early solely because SPF returned fail. A valid aligned DKIM signature can still make DMARC pass.
- Use SPF fail as a risk signal, especially when DKIM is missing, invalid, or unaligned.
- Calculate DMARC after SPF and DKIM results are available, then apply the published DMARC policy when DMARC fails.
- Continue local filtering because a DMARC pass confirms domain authorization, not message safety or inbox placement.
The term "hardfail" sounds like a mandatory rejection instruction, but the SPF standard calls the result "fail" and leaves disposition to receiver policy. It means the connecting IP is not authorized for the SPF identity. That identity is normally the envelope sender, not necessarily the visible From domain the recipient sees.
DMARC adds visible-domain protection through identifier alignment. It passes when either SPF passes for an aligned MAIL FROM domain or DKIM passes for an aligned signing domain. SPF often fails after forwarding or relaying, while DKIM can survive when the signed headers and body remain unchanged. Mailing-list modifications can still break DKIM.
|
|
|
|
|---|---|---|---|
Fail | Aligned pass | Pass | Continue local filtering |
Fail | Fail or unaligned | Fail | Apply DMARC and local policy |
Aligned pass | Fail or unaligned | Pass | Continue local filtering |
Aligned pass | Aligned pass | Pass | Continue local filtering |
How SPF and DKIM results affect DMARC.
Why SPF hardfail is not a DMARC policy layer
SPF checks whether the connecting IP is permitted to send for an SMTP identity. DMARC uses only the SPF-authenticated RFC5321 MAIL FROM domain, which later appears in Return-Path. A pass based only on the HELO or EHLO identity cannot produce a DMARC pass. DMARC compares the authenticated MAIL FROM or DKIM signing domain with the RFC5322 From domain shown to the recipient.
That sequence creates a timing problem. At the MAIL FROM stage, the receiver has not seen the header From domain, DKIM signature, or body hash. It cannot make a DMARC decision. A rejection on SPF hardfail at that stage is an SPF-only local-policy decision.
Flowchart showing SPF checked before DMARC can be evaluated.
SPF hardfail first
- The receiver can reject before headers, DKIM, and DMARC are evaluated.
- Forwarding and vendor bounce domains can make SPF fail or authenticate a domain that does not have DMARC alignment.
- A valid DKIM-authenticated message can be blocked before its aligned signature is checked.
DMARC after authentication
- The receiver has the visible From domain plus SPF and DKIM results before calculating DMARC.
- The domain owner publishes none, quarantine, or reject as the requested handling for DMARC failure.
- An aligned DKIM pass can preserve DMARC authentication when SPF fails after a routing change.
Publishing an SPF record and forcing SPF-only rejection are separate decisions. A domain owner can publish -all while receivers retain discretion over how they handle the resulting fail. The domain owner should still account for receivers that reject early.
What RFC 9989 says about -all
RFC 9989 is the current DMARC specification and replaces RFC 7489. It keeps the operational warning about SPF hardfail: because SPF can run before message content is transmitted, a receiver can reject a message before DMARC processing and before an aligned DKIM signature can be considered.
DMARC does not give fail, softfail, neutral, or none different paths to a pass. Only an SPF pass for a MAIL FROM domain with identifier alignment can support a DMARC pass. Any aligned DKIM pass can support DMARC independently of the SPF result.
- SPF fail and softfail both fail the SPF side of DMARC.
- An unaligned SPF pass also cannot support a DMARC pass.
- An aligned DKIM pass is enough for DMARC, even when SPF fails.
- Final handling remains receiver policy, even after DMARC passes.
This means -all does not strengthen a DMARC pass or fail decision. Its practical difference is the chance that a receiver applies an SPF-only rejection before DMARC is available.
When -all makes sense
For most active sending domains with DMARC, ~all is the safer default. It lets a receiver continue to DKIM and DMARC without changing the DMARC outcome for mail that does not pass SPF. Consider -all on an active domain only when the source inventory is complete, all important streams have aligned DKIM, and the delivery risk is understood.
Common SPF endingsdns
example.com. TXT "v=spf1 include:send.example.net ~all" example.com. TXT "v=spf1 include:send.example.net -all" unused.example. TXT "v=spf1 -all"
SPF ending choices
Choose the ending based on mail use and the risk of early SPF-only rejection.
Active sending domain
~all
Use softfail with DMARC so aligned DKIM can be evaluated when SPF fails.
Controlled exception
-all
Use hardfail only after testing and accepting the early-rejection risk.
No-mail domain
-all
Use hardfail with a reject DMARC policy when the domain sends no email.
Unknown sources
~all
Keep softfail while legitimate senders and authentication gaps are identified.
Hardfail often causes trouble when an old SPF record remains in DNS after a sender or vendor changes. The record still says fail, but the current mail flow no longer matches the authorization list. Aggregate reports and bounce logs should be checked after every sending-platform migration.
A domain that sends no mail is the clear exception. Publish an SPF record that authorizes no senders and pair it with DMARC reject. Suped's record generator can produce the DMARC TXT syntax, which should still be reviewed before publication.
No-mail domain recordsdns
example.com. TXT "v=spf1 -all" _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Why DKIM often carries the DMARC pass
Many sending platforms use their own envelope sender domain for bounce handling. SPF can pass for the platform's domain without having identifier alignment with the brand's visible From domain. The message then depends on aligned DKIM for a DMARC pass. That result is normal.
The mail path can be legitimate even when SPF does not authenticate the domain the recipient sees. DKIM lets the sender authenticate the visible brand domain while the bounce domain belongs to the sending platform. DKIM also survives simple forwarding when intermediaries do not alter signed content.
Audit the visible From domain's DMARC result and identify whether the pass came through SPF, DKIM, or both. An isolated SPF pass does not help DMARC when its authenticated domain lacks identifier alignment.
- An aligned SPF-only pass supports DMARC, but it depends on the envelope sender surviving the delivery path.
- An aligned DKIM-only pass supports DMARC when the signature validates.
- Passing through both methods gives legitimate mail another authentication path if one method later fails.
- If neither method passes with alignment, apply the DMARC policy and investigate the source.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A domain health check shows SPF, DKIM, and DMARC posture together. For a focused record parse, use Suped's DMARC checker, then compare the DNS record with real aggregate reports.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product maps authentication failures to sending sources, flags missing DKIM and SPF lookup errors, and provides remediation steps. This makes it possible to fix legitimate sources before changing DMARC policy or the SPF ending.
How to set policy without breaking mail
Use DMARC data to guide rollout. Start with monitoring, identify legitimate sources, fix DKIM and SPF coverage, then move DMARC toward quarantine or reject. The SPF ending is part of the DNS configuration, but it should not be the main enforcement control.
- Inventory every system that sends with the domain in its visible From address.
- Enable aligned DKIM for each source that supports custom signing.
- Remove stale SPF mechanisms and keep terms that cause DNS lookups within the SPF limit of 10.
- Move DMARC from monitoring to quarantine or reject only after legitimate failures are explained.
- Review the forwarding failure guide when SPF loses alignment after recipient-side forwarding.
If a receiver rejects SPF hardfail before DATA, DKIM cannot preserve a valid DMARC pass. If the receiver waits until authentication results are available, the domain owner's DMARC policy can address unauthenticated mail without treating normal routing changes as conclusive.
For a refresher on the standards, see SPF, DKIM, and DMARC. The important distinction here is that DMARC evaluates authorization for the visible sender domain, while final delivery remains receiver policy.
For an active sending domain, use SPF softfail during discovery and as the usual DMARC-era default. Use hardfail only after testing a specific need, and enforce DMARC after aggregate reports show that legitimate mail has reliable alignment.
Views from the trenches
Best practices
Treat SPF hardfail as a risk signal, then calculate DMARC after DKIM is fully checked.
Use softfail while sender discovery is active, then document any stricter choice.
Rely on aligned DKIM for platform mail that uses a separate envelope sender domain.
Review aggregate reports before policy changes, especially after vendor migrations.
Common pitfalls
Rejecting at MAIL FROM can block aligned DKIM before the DMARC check can run at all.
Copied SPF records with hardfail often remain in DNS after a sending platform changes.
Assuming every sender supports a custom bounce domain creates false SPF expectations in reports.
Treating DMARC quarantine as exact handling ignores receiver policy differences.
Expert tips
For non-sending domains, combine SPF hardfail with DMARC reject and aggregate reports.
Investigate SPF hardfail bounces because early rejects can be absent from reports.
Check whether each DMARC pass came through SPF or DKIM before changing DNS policy.
Document sender ownership so platform migrations do not leave obsolete SPF includes.
Marketer from Email Geeks says most receivers defer to DMARC and do not commonly reject solely because SPF hardfail failed.
2023-10-19 - Email Geeks
Marketer from Email Geeks says rejecting at MAIL FROM prevents DMARC validation because the visible From domain has not been received yet.
2023-10-20 - Email Geeks
Recommended configuration in practice
Do not enforce SPF hardfail ahead of DMARC. Publish SPF as one authentication method, use softfail for most active sending domains, and rely on DMARC to express the domain owner's requested handling for mail that fails visible-domain authentication.
Use this test: if a valid aligned DKIM signature would produce a DMARC pass after DATA, an SPF fail should not cause an earlier SPF-only rejection. If neither SPF nor DKIM passes with alignment, apply the published DMARC policy and receiver-local filtering.
Suped's product shows which authentication path each source used, flags broken sources, and supports staged DMARC enforcement. That evidence is more useful than treating -all as a universal rejection command.
