What are the considerations for using soft fail vs hard fail in SPF policies?
Published 27 May 2025
Updated 1 Aug 2026
10 min read
Summarize with
Updated on 1 Aug 2026: We updated this guide for RFC 9989 and RFC 9990, including the DMARC reporting blind spot created by early SPF hard-fail rejection.
For most active sending domains, I recommend SPF soft fail with ~all, not hard fail with -all. Hard fail looks stricter, but it can cause receivers to reject mail on the SPF result before they evaluate DKIM and DMARC. Soft fail keeps SPF useful as an authorization signal while letting DMARC make the final policy decision.
The clean model is simple: SPF and DKIM authenticate sending identities. DMARC checks whether an authenticated identity matches the visible From domain and states the requested policy for failures. If SPF hard fail causes early rejection, a message that has valid, aligned DKIM can still be blocked before DMARC gets a full chance to evaluate it. That is why I treat ~all as the safer default.
- Default choice: Use ~all for normal business domains that send through multiple platforms, vendors, or cloud mail systems.
- Hard fail case: Use -all only for non-sending domains, tightly controlled subdomains, or infrastructure where every sender is known and early SMTP rejection is an accepted risk.
- Policy layer: Put broad reject or quarantine decisions in DMARC, because DMARC can consider both SPF and DKIM domain matching.
- Internal control: Do not rely on SPF to stop employees using approved accounts for unauthorized bulk mail. That needs account policy, sending controls, and reporting.
What soft fail and hard fail mean
SPF evaluates the connecting server against the domain used in the envelope sender or HELO identity. The final SPF qualifier guide choice tells a receiver how strongly the domain owner considers hosts that did not match an earlier SPF mechanism to be unauthorized.
|
|
|
|---|---|---|
~all | Softfail | Probably unauthorized; do not reject on this result alone |
-all | Fail | Explicitly unauthorized; local policy decides disposition |
?all | Neutral | No authorization assertion |
+all | Pass | Every host passes SPF |
Common SPF qualifiers and receiver meaning.
The word "fail" causes confusion here. SPF softfail is still a negative result. RFC 7208 says receiving software should not reject a message based only on softfail. Hard fail makes an explicit assertion that the host is not authorized, but the receiver still decides the message disposition under its local policy.
Soft fail SPF recorddns
v=spf1 include:_spf.example.net ip4:192.0.2.10 ~all
Hard fail SPF recorddns
v=spf1 include:_spf.example.net ip4:192.0.2.10 -all
Why I usually keep SPF at soft fail
The practical problem with -all is timing. Some receiving systems make SPF decisions during the SMTP conversation. If they reject the message at that stage, they do not have the full message body and headers available for DKIM verification. DMARC evaluation then gets skipped or never reaches the normal policy path.
This behavior is not universal across mailbox providers, but RFC 9989 now warns about it directly. I do not design active sending domains around hard fail unless there is a narrow reason. Soft fail asks the receiver to keep the message long enough to evaluate the rest of the authentication signals.
Flowchart showing SPF checked before DKIM and DMARC policy is applied.
Hard fail can move the block too early
The main risk is not that hard fail is invalid. The risk is that the receiver treats it as enough evidence to reject before DKIM and DMARC can protect valid mail that fails SPF because of forwarding, routing, or a vendor sending path.
Soft fail path
A receiver sees SPF softfail, keeps processing the message, checks DKIM, then applies the DMARC policy. This lets valid DKIM-authenticated mail survive when SPF breaks in transit.
Hard fail path
A receiver sees SPF fail and can reject during SMTP. That can be appropriate for a controlled domain, but it creates avoidable risk on busy business domains.
How DMARC changes the decision
DMARC changes the SPF decision because it does not require SPF to be the only path to success. A message can pass DMARC through SPF only when SPF returns pass and the SPF-authenticated domain matches the visible From domain. SPF softfail, fail, neutral, and error results cannot create an aligned SPF pass. A message can instead pass through DKIM when DKIM succeeds and its signing domain matches the visible From domain.
That is why soft fail works well with DMARC. SPF can identify unauthorized envelope senders, DKIM can cover messages that SPF cannot cover, and DMARC can apply the domain owner's quarantine or reject policy after both checks are available. RFC 9989 now defines the core DMARC protocol, while RFC 9990 defines aggregate reporting. For a deeper version of this question, the hardfail with DMARC discussion is the right next read.
Monitoring first DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
DMARC does not always rescue hard fail
If the receiver rejects before accepting the message content, DMARC cannot evaluate DKIM for that message. Once a receiver has enough content to evaluate DKIM and DMARC, a DKIM pass can save a message even when SPF fails.
I also separate domain authentication from internal governance. DMARC can show unauthorized sources and reduce domain spoofing, but it cannot stop a person from sending through an approved mailbox account or approved marketing platform. That requires access controls and approval workflows, with monitoring of sending volume.
Why hard-fail losses can be invisible
A hard-fail rejection can create a blind spot in DMARC reporting. If a receiver rejects during the SMTP transaction before the DATA phase, it has not received the visible From header. It cannot discover the applicable DMARC policy, evaluate aligned DKIM, or add the message to an aggregate DMARC report.
RFC 9989 states this reporting limitation directly. RFC 9990 aggregate data remains essential for mail that reaches DMARC processing, but a clean report does not prove that -all caused no early rejections.
- Check sender logs: Review bounce events and SMTP response text for SPF-related 5xx rejections.
- Test indirect paths: Send through known forwarding routes and distribution workflows, then verify that aligned DKIM survives.
- Compare receivers: A successful test at one mailbox provider does not establish how every receiving system handles SPF fail.
- Keep a rollback record: Save the previous TXT value and lower the TTL before a controlled qualifier test.
When hard fail makes sense
Hard fail has valid use cases. I use it when the domain is not used for normal business mail, when the sender list is small and stable, or when the subdomain exists for one controlled mail stream and early rejection is an accepted tradeoff. The mistake is treating hard fail as a universal maturity milestone for every active domain.
- Non-sending domains: A domain that never sends mail can publish v=spf1 -all and a DMARC reject policy.
- Dedicated subdomains: A subdomain used by one platform with a stable envelope domain can tolerate hard fail when the operator accepts early rejection risk.
- Central gateways: A domain that sends only through a controlled mail gateway is a better candidate than a domain with many SaaS senders.
- Parked domains: Domains held for brand protection should publish explicit no-send records instead of permissive SPF.
- Active, high-change domains: Keep ~all because vendor changes make hard fail fragile, and hard fail adds no separate DMARC authentication path.
Non-sending domain recordsdns
v=spf1 -all v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
For a main corporate domain, I want proof before testing hard fail. That proof includes several weeks of DMARC reports, sender-side bounce log review, known forwarding patterns, confirmed vendor ownership, receiver-specific tests, and a clear rollback path. DMARC reports alone are insufficient because pre-DATA rejections are absent.
How to roll out SPF policy safely
A safe rollout starts with visibility, not syntax. I first inventory every service that sends with the domain, confirm whether it uses the main domain or a subdomain, then compare that list with DMARC aggregate reports. Unknown sources are usually the real work.
Suped's product supports this workflow by turning DMARC aggregate reports into sender-level authentication results and investigation steps. Suped's hosted SPF helps teams manage authorized senders when vendor changes would otherwise require repeated DNS edits.
- Inventory senders: List mailboxes, marketing platforms, help desks, billing systems, CRM tools, and any application servers that send email.
- Publish soft fail: Start active sending domains with ~all while you confirm real-world mail paths.
- Monitor reports: Use DMARC aggregate data to identify valid senders, forwarding paths, and sources that need DKIM.
- Fix sources: Add missing includes, move risky senders to subdomains, or require DKIM signing before enforcement.
- Tighten DMARC: Move DMARC from monitoring to quarantine, then reject once legitimate mail passes consistently.
- Reassess hard fail: Consider -all only for a narrow use case after tests show stable sender paths and the business accepts reporting blind spots.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
The DNS lookup limit is another reason not to rush policy changes. SPF permerror can be worse than a policy preference because receivers cannot reliably evaluate the record. If you are close to the 10 lookup limit, SPF flattening helps reduce DNS lookup pressure while keeping the published SPF record maintainable.
Checks before changing the qualifier
Before changing the final qualifier, I check the record itself and the mail that actually leaves the domain. Syntax alone does not prove the domain is safe. You need record validation and source visibility, plus a plan for the systems that fail SPF for legitimate reasons.
Use an SPF checker to confirm the published TXT record, included mechanisms, lookup count, syntax, and final qualifier. Then send real test messages through each major sender and inspect the authentication results.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
The output should match your sender inventory. If a provider appears in DMARC reports but not in the SPF record, decide whether that sender needs SPF, DKIM, a dedicated subdomain, or removal. Also review sender-side SMTP responses because an early SPF rejection will not appear in aggregate DMARC data.
A good SPF change has a rollback path
Keep the previous TXT record, know the DNS TTL, and watch DMARC failures, bounce logs, and SMTP response codes immediately after the change. A policy change without monitoring is guesswork.
Views from the trenches
Best practices
Keep SPF at softfail unless the domain has a tightly controlled sender list and stable IPs.
Use DMARC reports before changing policy so unknown senders are visible before enforcement.
Treat SPF and DKIM as positive signals, then let DMARC make the domain policy decision.
Move parked and non-sending domains straight to reject with an SPF hard fail record.
Common pitfalls
Using hard fail on a busy domain can block DKIM-valid mail before DMARC is checked.
Treating SPF as internal compliance control misses mail sent with valid mailbox credentials.
Changing SPF without checking forwarding paths leads to failures that reports reveal later.
Adding many include mechanisms pushes the record past the DNS lookup limit and causes permerror.
Expert tips
Separate marketing subdomains so riskier senders cannot affect the main corporate domain.
Keep SPF records readable; use hosted SPF when sender churn makes DNS changes slow or risky.
Review DMARC source data weekly during rollout and daily after any major sender change.
Use hard fail only after bounce logs, report data, vendor ownership, and SMTP tests agree.
Expert from Email Geeks says softfail keeps receivers from rejecting on SPF alone before DKIM and DMARC are evaluated.
2024-04-30 - Email Geeks
Expert from Email Geeks says hard fail belongs in narrow cases because some smaller mailbox providers still reject too early.
2024-04-30 - Email Geeks
My practical recommendation
Keep ~all on active mail-sending domains unless you have a narrow, controlled reason to use -all. Use DMARC for enforcement because it can evaluate SPF and DKIM alignment after the receiver has enough message data.
Hard fail is useful for non-sending domains and parked domains, plus controlled subdomains where the risk is understood. For the main domain used by people, vendors, applications, and forwarding paths, soft fail plus a monitored DMARC rollout gives stronger operational control with fewer false blocks.
Suped fits this workflow by showing which sources pass, fail, or need fixes, then turning those findings into specific steps. Pair that report data with sender-side bounce logs before changing the final character of an SPF record.
