Email DNS Check

SPF Missing All Mechanism

An SPF record must end with an all mechanism that tells receivers what to do with IPs that do not match any other mechanism. The all mechanism is usually ~all (softfail) or -all (hard fail). If your record has no all mechanism, receivers do not get a clear policy for unmatched senders. Many parsers treat such records as neutral or invalid, which weakens SPF as an authentication and anti-spoofing signal.

One-Minute Fix

Add ~all or -all to the end of your SPF record. Use ~all while you are still validating senders; use -all when your record is complete.

SPF with all mechanism
DNS TXT
v=spf1 include:_spf.google.com ~all

The all mechanism is required for a complete SPF policy. Without it, receivers cannot interpret how to treat unmatched IPs.

Re-check

Wrong vs correct setup

Record without all

Record without all
DNS TXT
v=spf1 include:_spf.google.com include:sendgrid.net

This record authorizes Google and SendGrid but does not define what happens for other IPs. Receivers may default to neutral, which weakens the policy.

Record with all

Record with all
DNS TXT
v=spf1 include:_spf.google.com include:sendgrid.net ~all

Adding ~all defines the default for unmatched IPs and gives receivers a clear, complete policy.

Why this happens

Incomplete SPF records often come from copy-pasting partial examples, adding only the include lines from provider documentation, or editing DNS without understanding that every SPF record must end with an all qualifier.

Why this is a problem

  • Receivers cannot apply a consistent default for unauthorized IPs.
  • SPF may evaluate as neutral instead of softfail or fail for spoofed traffic.
  • DMARC alignment can be harder to achieve when SPF results are ambiguous.
  • The policy looks incomplete and may reduce trust with mailbox providers.

How this affects deliverability

When SPF lacks an all mechanism, receivers treat the policy as incomplete. That can weaken anti-spoofing and make authentication less predictable. Adding ~all or -all gives a clear signal and improves the usefulness of SPF for deliverability.

Common causes

  • Provider documentation showed only the include line without the all qualifier.
  • The record was truncated during manual editing or migration.
  • Multiple people edited DNS and the final all was accidentally removed.
  • An old template or tutorial omitted the all mechanism.

What we checked

We verified whether your SPF record ends with a valid all mechanism (~all, -all, ?all, or +all). Records without all are reported as incomplete.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

What is the difference between ~all and -all?

~all (softfail) means probably not authorized. -all (hard fail) means definitely not authorized. Use ~all during rollout; -all when your sender list is complete.

Can I use ?all or +all instead?

?all is neutral and usually too weak. +all means all IPs pass, which defeats SPF. In practice, use ~all or -all.

Where exactly does all go in the record?

The all mechanism must be the last mechanism in the record, after all include, ip4, ip6, and other mechanisms.

Next steps

  • Open your current SPF record in DNS and check the end.
  • Add ~all if you are still validating senders.
  • Add -all if your record is complete and you want stricter enforcement.
  • Publish the updated record and allow propagation.
  • Re-run the check to confirm the all mechanism is present.
  • Review the full troubleshooting guidance in the SPF Hub.
  • Check signing and selector issues in the DKIM Hub.
  • Review alignment and policy issues in the DMARC Hub.

Related fixes

Explore more issues