auth.spf.record_too_long
SPF Record Too Long
What we check
We measure the assembled length of the SPF record. RFC 7208 §3.4 recommends keeping it small enough that the whole DNS answer fits in a 512-byte UDP response. Past that, resolvers fall back to TCP or fail, and receivers can hit a PermError.
What this finding means
The SPF record is large enough to risk UDP truncation. A single TXT record can hold multiple quoted strings, but the overall record has grown big enough that some resolvers may not return it cleanly — turning a valid policy into an intermittent failure.
Oversized records usually come from listing many ip4:/ip6: ranges inline, or from stacking includes that each add length.
Why it matters
- Intermittent failures. Truncation-related problems don't fail every time — they fail for some resolvers, some of the time, which makes them hard to diagnose.
- A growth signal. A record this long is usually one that's been added to repeatedly. It's worth consolidating before it also crosses the 10-lookup limit.
- Not a hard failure by itself. Well-behaved resolvers retry over TCP, so mail may still flow — but you're relying on every receiver's resolver behaving well.
How to fix
Consolidate IP ranges. Merge adjacent
ip4:/ip6:CIDRs into larger blocks.Move rarely-changing blocks behind a single include. Replace a long inline list with one
include:pointing at a record you control:example.com. IN TXT "v=spf1 include:_spf1.example.com include:_spf.your-provider.example -all" _spf1.example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 -all"Drop redundant mechanisms that duplicate ranges already covered by an include.
How it's graded
An overly long SPF record is a warning and carries no point deduction on its own. See Grading Methodology for the full scoring model.
Evidence example
$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 ip4:192.0.2.0/24 ... " (record assembled to 512+ bytes)
Record length exceeds the 512-byte UDP guideline (RFC 7208 §3.4) — risks truncation