Finding: SPF Record Approaching or Over the 10-Lookup Limit
This finding means your domain's SPF record contains 8 or more DNS-lookup-consuming mechanisms, counting only the record's own top-level terms. RFC 7208 caps SPF evaluation at 10; over that limit, receivers must treat the whole record as a permanent error.
Last updated August 11, 2026.
What it means
RFC 7208 section 4.6.4 requires that evaluating an SPF record use no more than 10 DNS-lookup-consuming mechanisms or modifiers — include, a, mx, ptr, exists, and redirect. Nivaronix counted the top-level occurrences of these in your record. This is a shallow count of your record's own tokens — it does not resolve include: targets to count what's nested inside them, so it is a lower bound, not the certified total a full SPF evaluation would reach.
Why it matters
If a record's real total lookup count — including everything inside every include: — exceeds 10, receivers are required by the RFC to treat it as a permanent error, which for most receivers means SPF is silently ignored for the domain. That is the same practical outcome as publishing no SPF record at all, except it happens invisibly: the record looks complete and correctly formed, and nothing about it changes until a receiver actually evaluates it and hits the cap. Because Nivaronix cannot see inside include:targets, a record flagged here as "approaching" the limit could already be over it once those nested lookups are counted.
What Nivaronix checks
Nivaronix counts the top-level include/a/mx/ptr/exists mechanisms and any redirect= modifier in your SPF record. This finding fires at 8 or more such terms, and its description changes depending on whether the count is at or under 10 (approaching the limit) or already over it (treated as broken by RFC 7208).
Example evidence (illustrative — not live scan data)
TXT example.com: v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com include:salesforce.com include:zendesk.com include:helpscout.net include:hubspot.com include:mailgun.org -all (top-level lookup-consuming terms: 8)
How to fix it
- Run the record through an SPF-flattening tool that follows every
include:chain to get the true total lookup count, not just the top-level count Nivaronix reports. - Remove
include:entries for services you no longer use. - Where possible, replace multiple
include:entries with directip4:/ip6:ranges for services that publish stable sending IPs, which don't consume the lookup budget. - Re-check the total after any change to your record or your senders' own SPF records, since a sender changing their infrastructure can silently push you over the limit.
How to verify the fix
Re-run the SPF & DMARC checker and confirm the top-level count has dropped below the approaching threshold, and cross-check with a full-chain SPF flattening tool.