Blog · Spf
The Temporary SPF Include from 2019 That Nobody Will Let Me Remove
Your SPF record has 14 includes. You hit the 10-DNS-lookup limit. Nobody knows what the include from 2019 was for. Nobody will take responsibility for removing it. And now your mail is softfailing at Gmail.
This is not a technical failure. It is organizational. SPF records accumulate includes the same way shared calendars accumulate declined meetings: nobody explicitly agreed to any of it.
Why the 10-lookup limit exists
RFC 7208 caps SPF lookups at 10 per message. Each include: triggers a DNS query. mx: triggers one per MX server. a: triggers one. The receiver must complete all lookups before deciding what to do with the message.
If your record requires more than 10, receivers treat it as a temporary failure - not a hard pass or fail. Messages retry later. Delivery becomes unpredictable. Some receivers softfail the message, which means it lands in spam instead of the inbox.
The limit exists to prevent DDoS amplification via DNS queries. It is not a suggestion.
How to count your current SPF lookups
dig TXT yourdomain.com +short | grep -i "v=spf1"
Every include: is one lookup. But includes chain. An include:_spf.google.com that contains its own includes means two, three, or more lookups just for that one directive.
To count accurately: resolve each include: target, count its includes, repeat until you reach ip4:, ip6:, or all - which stop counting.
DMARCFlow's SPF diagnostic shows the full lookup chain and flags when you are within 2 lookups of the limit. This gives you time to act before a receiver starts retrying your mail.
The "temporary" include problem
Nobody adds an include intending to leave it forever. The pattern is always the same:
1. 2019: You add a SendGrid include for a campaign. Email works. Nobody documents it. 2. 2021: A different team adds an include for a new transactional vendor. 3. 2023: Someone adds an include "just while we test" a new CRM mail relay. 4. 2025: You have 13 includes. Gmail starts softfailing your mail.
The DNS record - if it has a comment at all - says "temp" or "remove after Q3 2019." Nobody added a ticket. Nobody followed up. Six years later, that include appears in every SPF lookup for every message your domain sends.
The real problem: nobody owns the SPF record as a living document. It gets written once and reviewed never.
Decision framework: which includes to remove
| Include | Action |
|---|---|
| You can't identify what service uses it | Investigate first. Remove last. |
| Service migrated off 2+ years ago | Safe to remove |
| Include points to a domain you don't recognize | Investigate - may be a vendor you still use |
| Include is for a sender that sends FROM your domain (From header matches your domain) | Keep. Removing breaks your own delivery. |
| Include is for a sender that sends from their own server using your domain in From | Keep, but plan to move them to DKIM-only |
| Include was added "for testing" | Safe to remove if testing ended |
The key distinction: include: mechanisms authorize a server to send mail from your domain. If you remove an include for an active sender that uses your domain in the From header, their mail will start SPF-failing.
If the sender sends from their own infrastructure with their own SPF record - but uses your domain in the From header - removing the include breaks their mail. In that case, either keep the include, or coordinate with the sender to switch to DKIM-aligned sending from their own domain.
DMARCFlow's aggregate reports show which includes have sending history in the last 30 days. If an include appears in your DNS record but has no traffic, it is a candidate for safe removal.
How to remove an include safely
Before you change anything:
1. Save your current record: dig TXT yourdomain.com +short 2. Export your DMARC aggregate reports for the last 30 days 3. Confirm no sending history from the include's authorized IP ranges 4. Identify what each include is for - check with whoever last modified DNS
Making the change:
1. Prepare the new record before touching DNS. Never delete the old record before the new one is live. 2. Upload the new record. Use your DNS provider's atomic update if available. 3. Wait 5 minutes for propagation. 4. Confirm: dig TXT yourdomain.com +short 5. Send a test message to Gmail and Outlook. Check headers for Received-SPF: pass.
If mail breaks: Revert immediately. Identify which messages stopped arriving. Add the include back only after confirming the sender is still active for your domain.
How to prevent SPF record accumulation
The only durable fix: make SPF changes tracked operations, not ad-hoc DNS edits.
- Keep a change log: why each include was added, who requested it, when to revisit
- Review your SPF record every 6 months. Count the includes. Check DMARC reports for usage.
- When adding a new include, ask: "What happens when this service is no longer used? Who removes it?"
- Consider subdomains for high-volume third-party senders. A marketing vendor sending from
marketing.yourdomain.comcan have its own SPF record, keeping your root domain lean.
DMARCFlow monitors your SPF record for changes and alerts when a new include is added. It tracks which includes generate mail traffic, so stale ones appear as unused even while still in the record.
FAQ
What happens if I leave my SPF record with too many lookups?
Receivers treat an unresolved SPF record as a temporary failure and retry the message. Messages may arrive hours late or not at all if the retry window expires. Some receivers softfail the message, sending it to spam. This is not a hard bounce - it is an unpredictable delivery delay that is difficult to debug.
Can I split my SPF record to avoid the limit?
No. The 10-lookup limit applies to the total per message regardless of how you split records across DNS entries. The only fix is removing includes, consolidating redundant ones, or delegating high-lookup subdomains to their own SPF records on subdomains.
What if the vendor refuses to reduce their SPF chain?
If the vendor's own SPF record has too many includes, you cannot fix it from your side. Either stop using that vendor for sending from your domain, or move that sender to a subdomain with its own separate SPF record.
Nobody knows what the 2019 include does. Should I just remove it?
Only if you have confirmed no mail is being sent through its authorized servers for your domain in the last 6 months. Check DMARC aggregate reports for any auth results from the IP ranges in that vendor's SPF record. If there is no traffic, remove it. If you cannot confirm, investigate first.