← Back to Home

Why we flag SPF `+all` as critical

There's a specific SPF misconfiguration that shows up on real production domains far more often than it should. It's a six-character mistake with billion-dollar consequences:

v=spf1 +all

That record says, in plain English: any server on the internet is authorised to send email claiming to be from this domain. Not "most servers." Not "servers on our allowlist." Any server.

If you have +all at the end of your SPF record and an MX pointing at Google Workspace, a spammer in a basement somewhere can send phishing emails with a perfect SPF pass, from your domain, to your customers, to your regulators, to your board. SPF validates. DMARC aligns. Nothing in the recipient's mail filter has any reason to flag the message.

We flag +all as critical in DNS Watchdog. Here's why.

What SPF is supposed to do

SPF - Sender Policy Framework, RFC 7208 - is the mechanism that tells receiving mail servers "here are the IPs that are authorised to send email on behalf of this domain." A well-configured SPF record looks something like:

v=spf1 include:_spf.google.com include:amazonses.com -all

Three parts:

  1. v=spf1 - version tag, required
  2. One or more mechanisms - include:, ip4:, a:, mx: etc., listing authorised senders
  3. A terminal "all" mechanism - tells the receiver what to do with everything that didn't match

That terminal mechanism is what matters. It takes one of four qualifiers:

Qualifier Meaning When to use
-all Hard fail - reject mail from unlisted senders Production domains you want to protect
~all Soft fail - accept but mark as suspicious Testing a new SPF policy before going strict
?all Neutral - no opinion, receiver decides Almost never
+all Pass - all senders are authorised Never. Genuinely never.

Why would anyone use +all?

Three reasons, in order of frequency:

1. Copy-paste from an outdated tutorial. Early SPF tutorials sometimes showed +all as "the default that allows everyone" before explaining why you'd want to lock it down. The warning was in paragraph four; the example was in a code block people copied into production.

2. "Fix" for a delivery problem. Someone complained that mail from a new SaaS tool was failing SPF, a sysadmin googled "SPF failing fix," the first result said "change -all to +all," and the problem "went away." The mail got delivered. The SPF record became worthless.

3. Debugging that got committed. An engineer set it to +all temporarily while testing something, the change got promoted to production, and nobody noticed because email still worked.

None of these are outlandish. All of them are on production domains we've scanned.

What an attacker does with +all

The attack is depressingly simple:

  1. Attacker rents a VPS for £5/month
  2. Installs Postfix
  3. Configures it to send mail with a From address of ceo@your-company.com
  4. Drafts a message to your finance team asking them to wire money to a "new supplier account"
  5. Sends

SPF check? Pass - +all authorises every IP. DMARC alignment? Pass - From address matches the SPF-authorised domain. Recipient's spam filter? Sees a legitimate-looking email from a domain with valid email authentication, from a sender they recognise. Delivered to inbox.

The financial impact varies. The reputational impact is consistent: your customers get phishing emails that technically came from you.

The other SPF traps we check

+all is the worst, but not the only SPF problem. DNS Watchdog validates SPF records against RFC 7208 and surfaces the following:

Finding Severity What it means
+all terminal Critical Authorises any server on the internet
Missing v=spf1 prefix Critical Record is not a valid SPF record
Malformed mechanism syntax Critical Receiver will return a permanent error
More than 10 DNS lookups Critical Exceeds RFC 7208 Section 4.6.4 limit; receivers may return permerror
Deprecated ptr mechanism Warning Slow, fragile, and deprecated by RFC
No terminal all Warning Unclear policy; behaviour depends on receiver

The 10-lookup limit trips up more companies than you'd think. Each include:, a, mx, and ptr mechanism in the record (and all nested includes) counts. A record that started clean can silently break when one of your vendors updates their own SPF record to add a new include:.

How we catch it

Every TXT record classified as SPF gets parsed the way a receiving mail server would. We walk the mechanisms in order, count DNS lookups recursively, and check the terminal qualifier. When we find +all, it opens a critical finding against the zone with a clear remediation step: change the +all to -all (or ~all if you're still in a monitoring phase).

Email auth is one of the easiest wins in DNS security. The records are small, the syntax is well-defined, and misconfigurations are mostly mechanical - the kind of problem software can catch reliably. If you haven't audited your SPF records in a while, it's worth doing.

See your SPF posture

Book a demo and we'll run a validation pass on your zones. If you have +all in production somewhere, you want to know before your board does.