← Back to Home

Why we flag SPF `+all` as High severity

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 High severity in DNS Watchdog - the top tier for a misconfiguration, since Critical is reserved for the two findings we can confirm are exploitable right now: a fingerprint-confirmed subdomain takeover and an open Docker API. Here's why +all earns it.

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 High Authorises any server on the internet
Missing v=spf1 prefix Medium Record is not a valid SPF record
Malformed mechanism syntax Medium Receiver will return a permanent error
More than 10 DNS-lookup mechanisms Medium Exceeds RFC 7208 Section 4.6.4 limit; receivers may return permerror
No terminal all Medium Unclear policy; behaviour depends on receiver
Deprecated ptr mechanism Low Slow, fragile, and deprecated by RFC

The 10-lookup limit trips up more companies than you'd think. Under RFC 7208, each include:, a, mx, ptr, and exists mechanism counts, and so does every lookup inside the records your includes pull in. DNS Watchdog counts the lookup mechanisms written in your own record; the nested ones inside a vendor's include are worth checking by hand when you add a new sender, because a record that started clean can silently break when that vendor adds an include: of its own.

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 the DNS-lookup mechanisms in the record, and check the terminal qualifier. When we find +all, it opens a High-severity 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.