Your SPF record is an access control list
Ask a security team about VPN accounts and they will tell you about quarterly access reviews: who has standing access, who still uses it, whose access should have died with their contract. Ask the same team about the SPF record on their own domain and most will admit nobody has read it in years. Yet every include line in that record is exactly the same thing as a dormant VPN account: standing permission, granted once, that works forever until someone removes the line.
What an include actually grants
include:sendgrid.net does not mean "we use SendGrid." It means: every IP address SendGrid operates, now and in the future, may send mail that passes SPF as your domain. The grant is not scoped to your account with the vendor. It is scoped to the vendor's entire sending infrastructure, shared with every other customer they have.
That is fine while you use the vendor: it is the mechanism that makes your legitimate mail authenticate. It stops being fine the day the contract ends and the line stays. From that day the include grants a capability nothing on your side exercises, and two kinds of people can still exercise it: anyone with an account at that vendor who can set a custom From domain the vendor fails to verify, and anyone who compromises the vendor. Large senders have had exactly these incidents, and when they happen, every domain whose SPF still names that vendor is deliverable, SPF-passing spoof.
A published DKIM key is the same grant in the other protocol: whoever holds the private key can sign as you for as long as the public key stays in your DNS. A key your old agency's ESP still holds is an authorization your DNS is still asserting, months after anyone last used it legitimately.
Why nobody reviews it
Access reviews exist wherever there is a list of grants and a log of use to compare it against. VPN accounts have login logs. API keys have request logs. SPF records historically had neither half in one place: the record says who MAY send, and nothing on your side says who DID. So the review never happened, and records only ever grew. Trying three email vendors before settling on one leaves two dead includes; every dead include is both standing permission and one of the ten DNS lookups SPF allows you before it breaks entirely.
DMARC aggregate reports supply the missing half. Receivers report which IPs actually sent mail as your domain and how it authenticated. Cross that against the ranges each include resolves to and every line in your record gets a usage answer: this include carried mail last Tuesday; that one has carried nothing in 90 days.
Running the review honestly
The mechanics are simple; the honesty rules are where reviews go wrong. Four of them matter:
- "Unused" is an observation, not a verdict. A vendor that sends quarterly invoices or yearly renewal notices can look unused in any 90 day window. The claim worth making is "no report attributed traffic to this include in the last 90 days," stated with its window, and a human who knows the business decides what it means.
- Enough history, or no claim. If you have been collecting reports for three weeks, you cannot call anything unused. A review that answers before it has the history is guessing.
- Removal safety is coverage math, not usage math. Vendors share network blocks. Before removing a line, verify every IP that DID send in the window is still authorized by the rest of the record afterward. Zero attributed traffic on a line does not by itself prove removing it changes nothing.
- Some lines cannot be judged, and should say so. An include whose tree uses SPF macros resolves differently per message and cannot be attributed by IP. A record using
aormxmechanisms authorizes hosts you cannot enumerate from the record alone. An honest review marks these unreviewable rather than quietly calling them unused.
What removing a line buys you
Least privilege, applied to email. Fewer parties who can send as you means a smaller blast radius the next time any ESP has an account takeover incident. It also buys back an SPF lookup: records grow toward the 10-lookup cap one vendor trial at a time, and pruning dead includes is the cleanest way back from the edge. The same review that names your unused includes should also name published DKIM keys that signed nothing, so idle keys get retired through a proper rotation instead of lingering in DNS.
In trustyourinbox this review is the Access review segment on every domain's Senders tab: each SPF grant with its attributed traffic over the last 90 days, the published DKIM keys with their observed signing volume, and a one-click, undoable removal for an include the review found unused, behind a preview that shows the coverage proof and the exact record change. Quarterly is a fine cadence, the same one your security team already uses for everything else that grants standing access.
Keep reading
Counting your SPF lookups
The 10-lookup cap that unused includes quietly spend.
Turning on p=reject: what actually happens
Enforcement is the front door; this article is about the keys you already handed out.
Lookalike domains: the attack DMARC cannot stop
The other post-enforcement risk that quiet dashboards hide.
Was this page helpful?
Free for one domain. Set up in five minutes. We parse the reports; you read plain-English summaries.