auth.spf.duplicate_include
Duplicate SPF Include
What we check
We scan the flattened SPF record — the apex record plus everything its nested include: targets pull in — for the same include: target resolved more than once. Duplicates don't change the result, but each one spends a DNS lookup against the RFC 7208 §4.6.4 budget of ten.
What this finding means
Your SPF record resolves the same include: target more than once. This is harmless to authentication — the extra pass returns the same answer — but it's wasted budget: every duplicate is one of your ten permitted DNS lookups spent for nothing.
It usually happens when two of your includes each pull in the same shared provider (for example, two SaaS tools that both include a common infrastructure SPF), or when the same include was added twice.
Why it matters
- Wasted lookups. With only ten DNS lookups allowed, a duplicate include brings you closer to the limit — and past it, SPF fails with a PermError.
- A cleanup signal, not a break. On its own the record still works. But it's a sign the policy has grown by accretion and is worth tidying before it hits the hard limit.
How to fix
Identify the repeated target with an SPF audit tool that shows the flattened include tree.
Remove the redundant include if you can — or, if two providers genuinely both pull in the same shared include, accept it but keep an eye on the total lookup count:
example.com. IN TXT "v=spf1 include:_spf.provider-a.example include:_spf.provider-b.example -all"
How it's graded
A duplicate include is informational and carries no point deduction. See Grading Methodology for the full scoring model.
Evidence example
Flattened SPF for example.com:
include:_spf.provider-a.example → include:_spf.shared.example
include:_spf.provider-b.example → include:_spf.shared.example
^^^^^^^^^^^^^^^^^^ resolved twice — one wasted lookup