← 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.