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 say which mail is legitimate. DMARC says what to do when mail is not legitimate. If SPF hard fail causes early rejection, a message that has valid 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.
- 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 what the domain owner wants done with hosts that did not match any earlier SPF mechanism.
|
|
|
|---|---|---|
~all | Softfail | Suspicious, accept and score |
-all | Fail | Not authorized |
?all | Neutral | No strong statement |
+all | Pass | Any host allowed |
Common SPF qualifiers and receiver meaning.
The word "fail" causes confusion here. SPF softfail is still a negative result. The difference is that the SPF specification says a softfail result should not be the sole reason for rejection. Hard fail gives the receiver a stronger instruction that the host is not authorized.
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 it exists enough that 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 if SPF passes and the SPF-authenticated domain matches the visible From domain. It can also pass through DKIM if DKIM passes and the DKIM 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. 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; fo=1
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.
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. 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 often tolerate hard fail.
- 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.
- High-change domains: Domains with frequent vendor changes should stay on soft fail until reporting shows stable authentication.
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 moving to hard fail. That proof includes several weeks of DMARC reports, bounce log review, known forwarding patterns, confirmed vendor ownership, and a clear rollback path.
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 is the strongest practical choice for teams that want DMARC monitoring, SPF and DKIM checks, hosted SPF, blocklist (blacklist) monitoring, and issue remediation in one place. Suped's hosted SPF helps when sender changes are frequent because teams can manage authorized senders without 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 after evidence shows the domain has stable, controlled sender paths.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS 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. Do not treat an unknown source as harmless just because current delivery looks fine.
A good SPF change has a rollback path
Keep the previous TXT record, know the DNS TTL, and watch DMARC failures and bounce logs 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, and vendor ownership agree cleanly.
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 together after the receiver has enough message data.
Hard fail is useful for non-sending domains and parked domains, plus controlled subdomains. 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. That is the work that matters before changing a single character at the end of an SPF record.
