Overbroad SPF ranges: when ip4 and ip6 CIDRs are too wide

How wide is wide

An ip4 or ip6 mechanism matches if the high-order bits of the connecting address match the network you specified, to the depth of the prefix. The smaller the prefix number, the more addresses fall inside it.

Common reference: /32 is 1 address, /24 is 256, /16 is ~65,000, /8 is ~16 million, /0 is the entire IPv4 internet.

One syntax note. You cannot abbreviate the address instead of using CIDR. RFC 7208 is explicit that you write ip4:192.0.2.0/24, not ip4:192.0.2. The short form is a syntax error, not a range. If you leave the prefix off entirely, ip4 defaults to /32 and ip6 to /128 - one address each, which is sensible.

What DNSAudit flags and why

Critical: ip4:0.0.0.0/0 and ip6:::/0

Authorizes every IPv4 (or IPv6) address that exists. Functionally identical to +all, with one difference that makes it worse in practice: nobody spots it. +all is well known and gets caught in reviews. A /0 sitting in the middle of a list of legitimate-looking ip4 entries reads as just another range. There is no legitimate reason to publish either.

Warning: IPv4 /1–/8 · IPv6 broader than /32

No mail provider assigns a customer a block anywhere near that size. A prefix in this range almost always indicates an error rather than intent - and the shared-hosting consequence is the same as for /0, just for a smaller universe of attackers.

Informational: IPv4 /9–/16

Broader than any single sender needs, but not the obvious error that a very short prefix is, and occasionally a legitimate large allocation. Flagged for review, not treated as a fault. The scanner cannot always tell whose range it is.

Why a wide range is a real risk, not just untidy

The obvious version is that you have authorized hosts you do not control. The more concrete version - the one that shows up in incidents - is shared infrastructure.

Suppose you authorize an entire provider netblock rather than the specific addresses your account sends from. Every other customer on that provider now sits inside your SPF record. Anyone who can send mail from any host in that range can produce an SPF pass for your domain. If you publish DMARC and rely on SPF for alignment, they get an aligned pass as well. The attacker does not need to compromise anything of yours; they need an account with the same provider, which is usually available for the price of a signup.

This is the cross-user forgery problem the RFC raises in its security considerations, and it is why "which addresses" matters more than "which provider."

Where wide ranges come from

• A placeholder that stayed. Someone needed the record to stop blocking mail during a migration, wrote something permissive, and moved on.
• A copied example. Documentation and forum answers use illustrative values, and those get pasted in literally.
• Prefix confusion. Writing /8 when /28 or /29 was meant is a one-character mistake with a six-order-of-magnitude effect.
• Over-broadening to fix a delivery failure. Mail from a sender was failing, widening the range made failures stop, and the actual sending addresses were never identified.
• Redundant additions. Records grow over time: each addition fixes a symptom without anyone removing what it supersedes.

How to fix it

1. Identify what actually sends from that range. If you cannot answer this, that is the finding, not the CIDR. Check your outbound infrastructure, and ask the provider which addresses your account uses.
2. Replace the wide range with the specific blocks. Most providers publish either exact ranges or an include you can use. Prefer the include when they offer one - they maintain it as their infrastructure changes.
3. If you must keep raw CIDRs, use the narrowest prefix that covers your senders, and write down where the range came from so the next person does not widen it again.
4. Treat a /0 as urgent. Do not wait for the rest of the record cleanup.
5. Re-scan to confirm the range is now scoped to what you actually send from.

One thing to watch while narrowing: if a range was covering a sender you had forgotten about, tightening it will make that sender start failing. Where DMARC reporting is available, check the aggregate reports for sources inside the old range before you cut it down.