Guide

SPF hard fail vs soft fail: choosing -all or ~all with DMARC

Q: How do receivers treat SPF -all and ~all?

Each receiver decides. -all gives a fail result for servers the record does not list, and a receiver may reject that mail during the SMTP conversation (RFC 7208, section 8.4). ~all gives a softfail, and receivers should not reject mail on that result alone, though they may look at it more closely (RFC 7208, section 8.5). ?all is neutral, and +all lets any server pass, so do not publish it.

Q: Should I use ~all or -all when I have DMARC?

Use ~all on a domain that sends mail and publishes DMARC, and -all on a domain that sends none. On a sending domain, DMARC already applies your policy to mail that neither SPF nor DKIM passes in alignment, and ~all keeps the DKIM path open for forwarded mail. Google recommends ~all for Google Workspace domains; Microsoft recommends -all so that DMARC can act on unsigned mail.

Q: Does switching from -all to ~all make my domain less secure?

Not when DMARC is at enforcement. At p=reject you ask receivers to refuse mail that fails DMARC, and each receiver makes the final call (RFC 9989, section 5.4). The SPF qualifier does not change that request. Without DMARC, ~all alone does not ask receivers to refuse spoofed mail, so publish DMARC first: start at p=none, and move to p=reject once your reports show every legitimate sender aligning. Set up DKIM for every service that sends as you too, because ~all relies on DKIM to carry forwarded mail through.

Use ~all (soft fail) on a domain that sends mail and publishes DMARC, and -all (hard fail) with p=reject on a domain that sends none. Some receivers refuse mail on an SPF hard fail before DMARC checks DKIM, so -all can lose forwarded mail that aligned DKIM would have passed (RFC 9989, section 7.1). Microsoft recommends -all so that DMARC can act on unsigned mail; Google recommends ~all. For how SPF works and what the rest of a record does, see What is SPF?

By ShieldMarc · Updated October 2026

Facts checked against live DNS, the relevant RFC or the provider’s own documentation.

How do receivers treat -all and ~all?

The qualifier on the final all sets the SPF result for a server your record does not list, and RFC 7208 leaves what happens next to each receiver. What is SPF? covers the mechanisms before it.

Qualifier	SPF result	What a receiver may do
-all	Fail (hard fail)	Reject the message during the SMTP conversation, or mark it (section 8.4)
~all	Softfail	Accept it, perhaps with closer scrutiny: it should not reject on this result alone (section 8.5)
?all	Neutral	Treat it as if there were no SPF result (section 8.2)
+all	Pass	Nothing: every server passes, so do not publish it

On the surface, -all sounds like the obvious choice. Reject anything not authorised. The problem is what happens between the SPF check and the DMARC check.

The forwarding problem with -all

When a forwarder relays your email without changing the envelope sender, as a plain alias or a simple forwarding service does, the message arrives from the forwarder's IP address. That IP is not in your SPF record, so SPF fails at the next server. This is expected and normal. Forwarders that rewrite the envelope sender, and mailing lists, which send under their own domain, are checked against their own SPF record instead.

The critical question is: what happens next?

With ~all (soft fail), the receiving server notes the SPF failure but continues processing. It then checks DKIM. If your email was DKIM-signed, the signature survives forwarding because DKIM signs the message content, not the sending IP. DMARC sees the valid DKIM signature, alignment passes, and the email is delivered.

With -all (hard fail), some receiving servers reject the email immediately at the SMTP layer, before DMARC or DKIM is ever evaluated. The email is gone. The sender gets a bounce. Your DKIM signature, which would have saved it, is never checked.

The sequence matters

A receiver that rejects on an SPF fail may do it before any DMARC processing, so DMARC never gets the chance to check DKIM. Mail refused early in the SMTP conversation never appears in aggregate reports (RFC 9989, section 7.1).

An example: mail sent to a forwarding address

Your colleague at example.com emails a supplier whose old address at example.net forwards to a new mailbox elsewhere. The forwarder relays the message unchanged, so the envelope sender is still example.com, but the message now comes from the forwarder's IP address, which your SPF record does not list. SPF fails at the new mailbox's server.

With ~all: the server records a soft fail and carries on. DKIM still passes for example.com, so DMARC passes on aligned DKIM and the message is delivered.
With -all: a server that acts on SPF before DMARC can refuse the message during the SMTP conversation, and it bounces.

How DMARC changes the equation

Before DMARC existed, -all was the only way to tell receivers to reject unauthorised email. SPF was the sole line of defence.

DMARC changed this. With p=reject, you are asking receivers: "If neither SPF nor DKIM passes in alignment, refuse the email." DMARC is now the policy enforcer. SPF's job is reduced to being one of two authentication signals that DMARC evaluates.

When DMARC is enforcing policy, the SPF qualifier becomes less important:

~all + DMARC p=reject: SPF soft-fails unauthorised senders. DMARC checks both SPF and DKIM alignment. If neither aligns, DMARC fails and your policy applies. Forwarded mail with valid DKIM still passes.
-all + DMARC p=reject: Same DMARC outcome, but with the added risk that some servers reject at the SPF layer before DMARC runs.

The DMARC outcome for spoofed email is the same either way. At p=reject you ask receivers to refuse mail that fails DMARC, and each receiver makes the final call (RFC 9989, section 5.4). The difference is that ~all gives DMARC the chance to save legitimate forwarded email via DKIM.

What Google says

Google's Set up SPF page recommends ending a Google Workspace domain's record with ~all (soft fail). Gmail's forwarding guidance says forwarded messages often fail SPF, which is why Google recommends DKIM alongside it.

When hard fail is still correct

There is one scenario where -all is the right choice: domains that never send email.

If you have a parked domain, a defensive registration, or an alias domain with no outbound mail, there is no legitimate email to forward. No DKIM signatures exist. The correct SPF record is:

v=spf1 -all

Combined with v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; this is the strongest possible configuration for a non-sending domain. There are no senders to accommodate, no forwarding to worry about, and no reason to use soft fail.

Domain type	Recommended SPF qualifier	Why
Active (sends email)	~all	Lets DMARC handle enforcement. Preserves DKIM path for forwarded mail.
Parked / defensive	-all	No legitimate mail exists. Block everything at every layer.
Alias / email-only	-all	Only receives mail, never sends. No forwarding to protect.

What you should do

Check your current SPF record. Our free SPF Checker shows your SPF qualifier, the lookups used out of 10 and the include tree.
If you have DMARC with p=quarantine or p=reject and your SPF uses -all, change it to ~all. Your DMARC policy already asks receivers to act on mail that fails it, so the hard fail adds no protection and risks losing forwarded email.
If you do not have DMARC yet, create one with our DMARC Generator before changing your SPF qualifier. You can also use our SPF Generator to rebuild your SPF record with the correct qualifier. Without DMARC, ~all alone does not reject spoofed email. Start with p=none to monitor, then progress to p=reject once your aggregate reports confirm every legitimate source aligns. The DMARC p=none to p=reject rollout runbook covers each stage.
For non-sending domains, keep v=spf1 -all and pair it with p=reject.
Ensure DKIM is configured for all your sending services. ~all only works safely when DKIM is in place to authenticate forwarded email. Without DKIM, forwarded email fails both SPF and DKIM, so it fails DMARC and your policy applies.

Frequently asked questions

How do receivers treat SPF -all and ~all?

Each receiver decides. -all gives a fail result for servers the record does not list, and a receiver may reject that mail during the SMTP conversation (RFC 7208, section 8.4). ~all gives a softfail, and receivers should not reject mail on that result alone, though they may look at it more closely (RFC 7208, section 8.5). ?all is neutral, and +all lets any server pass, so do not publish it.

Why does SPF hard fail (-all) break forwarded email?

A forwarder that keeps your address as the envelope sender relays your message from its own IP address, which your SPF record does not list, so SPF fails at the next server. With -all, some receivers refuse the message during the SMTP conversation, before DMARC checks the DKIM signature that would have passed it. Mail refused early in the SMTP conversation never appears in aggregate reports (RFC 9989, section 7.1).

Should I use ~all or -all when I have DMARC?

Use ~all on a domain that sends mail and publishes DMARC, and -all on a domain that sends none. On a sending domain, DMARC already applies your policy to mail that neither SPF nor DKIM passes in alignment, and ~all keeps the DKIM path open for forwarded mail. Google recommends ~all for Google Workspace domains; Microsoft recommends -all so that DMARC can act on unsigned mail.

When is SPF hard fail (-all) still the correct choice?

On a domain that never sends email, such as a parked domain, a defensive registration or an alias domain with no outbound mail. There is no legitimate mail to forward and no DKIM signature to protect, so publish v=spf1 -all with a DMARC record such as v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;.

Does switching from -all to ~all make my domain less secure?

Not when DMARC is at enforcement. At p=reject you ask receivers to refuse mail that fails DMARC, and each receiver makes the final call (RFC 9989, section 5.4). The SPF qualifier does not change that request. Without DMARC, ~all alone does not ask receivers to refuse spoofed mail, so publish DMARC first: start at p=none, and move to p=reject once your reports show every legitimate sender aligning. Set up DKIM for every service that sends as you too, because ~all relies on DKIM to carry forwarded mail through.

Sources and further reading

RFC 7208: Sender Policy Framework (SPF)
Section 4.6.2 maps the qualifiers in -all and ~all to the fail and softfail results. Sections 8.4 and 8.5 leave their handling to the receiver: a fail may be rejected during the SMTP conversation, and a softfail should not be rejected on that result alone.
datatracker.ietf.org/doc/html/rfc7208
RFC 9989: DMARCbis, which replaced RFC 7489 in May 2026
Section 5.3.5 passes a message when SPF or DKIM passes in alignment, which is why DKIM can save forwarded mail that fails SPF. Section 7.1 warns that an SPF hard fail can get such mail rejected before DMARC runs.
rfc-editor.org/rfc/rfc9989 (DMARCbis) · datatracker.ietf.org/doc/html/rfc7489
Google Workspace Admin Help: Set up SPF
Google's record for a domain that sends through Google Workspace ends with ~all, the soft fail Google recommends. Gmail's forwarding guidance adds that forwarded messages often fail SPF.
knowledge.workspace.google.com: Set up SPF · support.google.com: Gmail forwarding guidance
Microsoft: Set up SPF for Microsoft 365
Microsoft's guide to SPF for Microsoft 365 domains: one SPF record per domain, the limit of 10 DNS lookups, and its recommendation to end the record with -all.
learn.microsoft.com: Configure SPF
M3AAWG Email Authentication Recommended Practices
The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) publishes best-practice guidance used by major email providers. Their recommendations align with using DMARC as the policy layer rather than relying on SPF hard fail alone.
m3aawg.org/published-documents

Check your SPF record now

Our free DMARC Checker shows your SPF qualifier, counts nested DNS lookups, and flags hard fail on active domains with a recommended fix. No sign-up needed.