SPF present but overly broad

Your SPF record parses and evaluates, and authorises more of the internet than you send from. Three shapes cause it: +all, which authorises every host; ?all, which states no opinion; and wide ip4 ranges or bare provider includes, where a /16 covers 65,536 addresses. A record can end in -all and still be overly broad: the mechanisms in front of the qualifier grant the authorisation. This page is the other half of softfail vs fail.

Measured 2026-09-09 across 368 audited domains publishing an SPF record: 0 used +all, 0 published an ip4 range of /16 or wider, and 4 ended in ?all. For comparison, 214 ended ~all and 143 ended -all. On this corpus the overly-broad failure is rare; it is documented because it is severe and silent, not because it is common. These are domains someone had a reason to check, so this is an upper bound and not an internet-wide rate.

What was observed

A valid SPF record exists, and it authorises more than the hosts you send from. The final qualifier is not the issue here — that is softfail vs fail. The issue is the mechanisms in front of it.

An SPF record is an authorisation list. Every address it covers may send as your domain and produce an SPF pass.

The three shapes

+all — authorises every host on the internet. The record evaluates to pass for anyone.
?all — the neutral qualifier. It states no opinion, and RFC 7208 §8.2 says a neutral result MUST be treated exactly like the none result.
Wide ip4 / ip6 ranges — a /16 authorises 65,536 addresses; a /8 authorises 16,777,216. A bare provider include: can expand to the same thing without the number ever appearing in your record.

How to verify it yourself

Read the record
```
dig +short TXT example.com | grep spf1
```

Look for the permissive qualifiers

dig +short TXT example.com | grep -oE '[+?]all'

List every ip4 range and its width

dig +short TXT example.com | grep -oE 'ip4:[0-9./]+'

Check this record Reads the live record and counts every DNS lookup it costs.

The safe fix, and what it can break

Inventory first. Publish DMARC with rua=, read the aggregate reports until you can name every source sending as your domain, then remove what is not on that list. Replace +all or ?all with ~all as the first step, and narrow ranges to the addresses you actually use.

What can break: every authorisation you remove is a sender that now fails SPF. If that sender is real and you have not noticed it, its mail loses the SPF pass the moment you publish. Narrow on evidence from reports, one change at a time, and leave the final qualifier alone until the mechanisms are right.

Examples

Overly broad — authorises the entire internet

v=spf1 +all

Overly broad — neutral, states no opinion

v=spf1 include:_spf.google.com ?all

Overly broad — a /16 in front of a strict qualifier

v=spf1 ip4:198.51.0.0/16 -all

Narrow — the hosts actually used

v=spf1 ip4:198.51.100.10 ip4:198.51.100.11 ~all

Narrow — one provider, nothing else

v=spf1 include:_spf.google.com ~all

What the standard says

RFC 7208 §8.2: “A “neutral” result MUST be treated exactly like the “none” result”

What makes an SPF record “overly broad”?

It authorises senders you do not control. The three shapes are +all, which authorises every host on the internet; ?all, which is neutral and states no opinion; and a large ip4 or ip6 range, where a /16 authorises 65,536 addresses and a /8 authorises over sixteen million.

Is +all ever correct?

No. +all says every host on the internet is an authorised sender for your domain, which is the same authorisation state as publishing no record, with the added problem that it looks deliberate. Nothing legitimate requires it.

Is ?all the same as having no SPF record?

Close, in effect. ?all is the neutral qualifier: it states no opinion about hosts that do not match. RFC 7208 §8.2 says a neutral result MUST be treated exactly like the none result. The difference is that a record ending ?all still costs DNS lookups to evaluate.

How wide is too wide for an ip4 range?

Publish the addresses you actually send from. A /32 is one host. A /24 is 256 and is normal for a rented block you control. Anything at /16 or wider is almost always a whole provider's estate rather than yours, and everyone else on it inherits your authorisation.

What is wrong with including a whole provider?

Nothing, if you send through them. The problem is an include whose published range covers every customer of that provider, because SPF then authorises those customers to send as your domain. This is why SPF alone does not establish that a message is yours, and why DMARC alignment and DKIM matter.

Does narrowing SPF risk breaking mail?

Yes, and that is the whole difficulty. Removing an authorisation that a real sender was relying on makes that sender fail SPF. Read DMARC aggregate reports until you can name every source, then narrow.

Should I use ~all or -all?

That is a different question and it has its own page: softfail vs fail. This page is about what comes before the final qualifier. A record ending -all that authorises a /8 in front of it is still overly broad.

How do I find out which senders I actually use?

Publish DMARC with rua= and read the aggregate reports. They name the sources sending as your domain, which is the inventory you need before you can safely narrow anything.

What we do not claim

We report what your DNS publishes and what an SPF evaluator would return from it. We do not state what any mailbox provider will do with a broad authorisation: those decisions are theirs, they are not published, and we cannot measure them from here.

Reviewed by Venkat Nookala, last reviewed 2026-09-09.