SPF hard fail vs softfail: which should you use?

How do mail servers treat softfail vs hard fail?

SPF produces a signal, and the receiving server decides the outcome. RFC 7208 defines the results this way:

• Fail (-all) is an explicit statement that the client is not authorized to use the identity. Receivers are entitled to reject the message outright during the SMTP transaction.
• Softfail (~all) sits between neutral and fail: the domain believes the mail is probably unauthorized but is not certain. The RFC says receiving software SHOULD NOT reject a message based solely on a softfail, but MAY subject it to closer scrutiny than normal, which in practice often means the spam folder.

Note what SPF evaluates. SPF checks an SMTP identity, normally the envelope sender, not the address a person sees in their mail client. The SPF overview covers how that identity is chosen. The visible From domain is protected by DMARC alignment, usually with DKIM as the second authentication path.

What about ?all and +all?

?all and +all are the other two terminal qualifiers SPF defines. Neither belongs on a production sending domain:

• ?all (neutral) makes no assertion at all. Unlisted senders are neither authorized nor unauthorized, so receivers treat it roughly like having no SPF policy. Its only legitimate use is short-lived testing while you inventory senders.
• +all (pass) declares that every server on the internet is authorized to send as your domain. It actively helps spoofers and is treated by many filters as a spam signal in its own right. There is no good reason to publish it.

Why does forwarding break SPF hard fail?

Forwarding breaks SPF hard fail because the forwarding server relays your message from its own IP address, which your SPF record does not list. SPF cannot tell that hop apart from a spoof, so it fails on mail you legitimately sent. Here is the sequence:

1. When a recipient auto-forwards your email, say from a work address to Gmail, the forwarding server becomes the new sending server.
2. That forwarding server is not in your SPF record, so SPF fails.
3. With -all, the receiver may reject the forwarded message on the SPF result alone. A legitimate email is lost.
4. With ~all, the message is accepted with suspicion, which gives DKIM and DMARC the chance to authenticate it properly.

Is ~all less secure than -all if you have DMARC?

No. With DMARC enforcing your policy, softfail and hard fail provide equivalent protection against spoofing. RFC 9989, the current DMARC specification that obsoletes RFC 7489, evaluates SPF as a pass or not a pass, plus alignment with the visible From domain. It does not distinguish a soft failure from a hard one:

• If either SPF or DKIM passes and aligns, the message passes DMARC.
• If neither does, your DMARC policy, p=quarantine or p=reject, is applied.

What does the industry recommend?

The industry recommendation for a domain that sends email is ~all. The DMARC and deliverability world leans that way and says so in public:

• Google Workspace recommends softfail outright. Its SPF documentation gives v=spf1 include:_spf.google.com ~all as the record for a Workspace-only domain, and warns that with a hard fail qualifier "messages that fail the SPF check are more likely to be rejected by the receiving server, and you can't use those messages to troubleshoot your SPF record."
• Al Iverson, of Spam Resource, answered the question directly. His general answer was -all, but he added an update for anyone running DMARC: once your policy is at p=quarantine or p=reject, "~all (tilde all) is probably the better way to go," because SPF failures evaluated ahead of DMARC can cause rejections that never appear in your DMARC reporting at all.
• RFC 7208 is the reason the two results behave differently in the first place, since it tells receivers not to reject on a softfail alone.

The notable dissent is Microsoft. Its Microsoft 365 SPF guidance recommends -all, on the grounds that "the DMARC policy is effectively ignored for SPF ~all failures if the messages don't also contain DKIM signatures." Read that condition carefully, because it is the whole argument: it applies to messages carrying no DKIM signature at all. The DMARC specification itself draws no distinction between softfail and fail, so this describes one receiver's behavior rather than the standard. Sign every sending service with DKIM, which you should do regardless, and the objection stops applying to your mail.

Which should you use: ~all or -all?

Whether you should use ~all or -all depends on what the domain does, not on which qualifier sounds stricter. Decide by the domain's job:

• The domain sends email (your primary domain): use ~all, enable DKIM on every sending service, and enforce DMARC at p=quarantine and then p=reject. This blocks spoofing without sacrificing forwarded mail.
• The domain sends no email (parked domains, web-only domains): publish the bare record v=spf1 -all plus DMARC p=reject. Nothing legitimate can be lost, and spoofing is shut down completely.
• You are still inventorying senders: use ~all, which is where a sending domain settles anyway. What the inventory changes is which senders you authorize, not the qualifier at the end.

There is no industry migration date from ~all to -all, and no deliverability bonus waiting at the end of one. On a domain that sends mail, ~all is the end state rather than a stepping stone: the control you tighten over time is the DMARC policy, not the SPF qualifier. If you do change the record for any reason, keep the previous value and its TTL so you can roll back.

How do you implement ~all plus DMARC safely?

Implementing ~all plus DMARC safely means publishing softfail first, signing every sender with DKIM, and only then tightening the DMARC policy. Work the six steps in order:

1. Publish SPF with softfail, listing every legitimate sending service:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

This record is illustrative. Publish the mechanisms documented for your own senders, not the example values.

2. Enable DKIM signing for every service that sends as your domain. This is what makes softfail safe, and what answers Microsoft's objection above.
3. Publish a DMARC record starting at p=none. The DMARC record generator builds one correctly.
4. Monitor aggregate reports until every legitimate source passes with alignment. Aggregate reports take a day or more to arrive. For an immediate read on a single stream, the email deliverability test grades one message you send and shows whether SPF and DKIM aligned.
5. Move DMARC to p=quarantine, then p=reject. This is where the real anti-spoofing enforcement happens.
6. Keep the record current as you add new tools, and stay under SPF's limit of 10 DNS-querying terms.

You can validate the finished setup at any time with the SPF checker. Confirm there is one SPF record, the syntax is valid, all is last, and evaluation stays inside the 10-term limit.

Check the published SPF policy first

Run the domain through Palisade's SPF checker before you change the qualifier, then compare its DNS result against the evaluated identity and connecting IP from a delivered message. The checker reads the public record; it cannot reproduce a receiver's private disposition.

If repeated sender changes make the inventory hard to maintain, Palisade's DMARC Agent remediation guide documents how report findings become source-specific SPF, DKIM, and alignment work. Get started when recurring report-based sender monitoring is the remaining need.