SPF Hard Fail vs Soft Fail: Why ~all Is Safer with DMARC

What the "all" mechanism does

Every SPF record ends with an all mechanism that tells the receiving server what to do when an email comes from an IP address not listed in the record. There are four qualifiers:

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 someone forwards your email (mailing lists, auto-forwarding rules, shared mailboxes), the forwarding server relays it from its own IP address. That IP is not in your SPF record, so SPF fails. This is expected and normal.

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.

Real-world example

Your colleague at company.comsends a legitimate email. Their Outlook has an auto-forward rule to their personal Gmail. Gmail receives the email from Microsoft's forwarding servers, not from your authorised IPs. SPF fails.

• With ~all: Gmail marks SPF as SoftFail, checks DKIM (passes), checks DMARC alignment (DKIM aligns), delivers the email.
• With -all:Some servers reject at SMTP. The email may never reach Gmail's DMARC evaluation. 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 telling receivers: "If both SPF and DKIM fail to align, reject 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 rejects. 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 end result for spoofed email is identical: it gets rejected. The difference is that ~all gives DMARC the chance to save legitimate forwarded email via DKIM.

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:

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.

What you should do

1. Check your current SPF record. Use our free DMARC Checker to see your SPF qualifier, lookup count, and nested includes.
2. If you have DMARC with p=quarantine or p=reject and your SPF uses -all, change it to ~all. The DMARC policy is already enforcing rejection. The hard fail adds no protection but risks breaking forwarded email.
3. 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.
4. For non-sending domains, keep v=spf1 -all and pair it with p=reject.
5. 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 will fail both SPF and DKIM, and DMARC will reject it.

Sources and further reading

• RFC 7208 - Sender Policy Framework (SPF)
  Section 8.4 discusses how SPF results can be used at the SMTP layer to reject mail before further processing. Section 2.6.2 defines the qualifier semantics for -all and ~all.
  datatracker.ietf.org/doc/html/rfc7208
• RFC 7489 - DMARC
  Section 6.7 describes how DMARC evaluates SPF and DKIM results together. A DMARC pass requires only one of SPF or DKIM to align, which is why DKIM can save forwarded mail that fails SPF.
  datatracker.ietf.org/doc/html/rfc7489
• Google Email Sender Guidelines
  Google recommends ~all for sending domains and states that SPF hard fail provides no additional benefit when DMARC is in place, as Gmail evaluates DMARC regardless of the SPF qualifier.
  support.google.com/a/answer/33786
• Microsoft - How SPF works with DMARC
  Microsoft's documentation explains that DMARC overrides SPF hard fail results when DKIM alignment passes, but notes that not all receivers implement this consistently.
  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/documents