Remove a Legacy SPF Include Without Breaking Email

How to Remove a Legacy SPF Include When Your Team Won't Approve It

The technical part of removing a legacy SPF include is simple. The hard part is getting approval.

Your inbox is full of emails from the last time someone tried and got blocked with "if it works, don't touch it." The person blocking removal usually isn't making a technical argument - they're making a risk-aversion argument, and it's not wrong. Changing DNS records can break email. But the risk of leaving stale includes in place is different: you burn lookup budget with every include: mechanism, and when you hit the RFC 7208 hard cap of 10 DNS lookups, receivers softfail your entire domain. That doesn't announce itself either.

This article is about the workflow: how to audit what you have, build evidence that an include is unused, make the organizational case for removal, and execute the change safely.

Step 1: Identify Which Includes Are Actually Being Used

Before you ask anyone to approve a change, you need evidence. Three sources give you a complete picture.

DMARC aggregate reports are the most useful starting point. Your DMARC policy generates XML reports sent to the addresses in your rua tag. These reports list every sending source that tried to deliver mail on your domain's behalf, along with pass/fail breakdown. Any include whose sources generate no auth results - or only consistent failures - is a candidate for removal.

If you do not receive DMARC reports yet, the absence itself is evidence. A vendor generating legitimate mail will produce failures in your reports when it tries to send. Zero appearances over 30 days suggests zero current use. DMARCFlow makes it straightforward to verify this across all your included domains at once rather than manually reviewing individual reports - you can see whether a legacy vendor's IPs are generating any auth traffic or sitting completely silent in your reporting.

External SPF check tools show you exactly what your current record resolves to and how many lookups it generates. Tools like MXToolbox, IntoSPF, and Kitterman show the full include chain and the count. Run one before you start and record the result as your baseline.

Your MTA logs show what your servers actually sent and where. Any include whose domains never appear as sending sources in your logs over the past 60-90 days is a candidate.

Document everything. Screenshot the DMARC report showing zero auth results from the legacy vendor's IPs. Save the SPF check output showing the include chain. That documentation is the difference between "I think this isn't used" and "here's the evidence."

Step 2: Build the Case for Removal

The objection you will face is some version of "what if it breaks email?" Reframe it: the risk of leaving stale includes is hitting the 10-lookup ceiling, which causes receivers to softfail all your outbound mail with no warning. You cannot predict which receiver enforces it first or when.

Write a short internal memo:

> What we have: An SPF include for a vendor we stopped using in [year]. This vendor was used for [marketing platform / CRM / legacy ERP system].

> What the data shows: In the past 60 days, this include's IPs have generated zero appearances in our DMARC aggregate reports. External SPF check confirms the include resolves to IPs that have not sent mail to any DMARC-enabled receiver in our reporting window.

> What the risk is: This include consumes 2 lookups of our 10-lookup budget. We currently have 9 active includes. When we exceed 10 lookups, receivers softfail our outbound mail - not just from this vendor, from all our sending IPs.

> What we propose: Remove the include, switch to ~all for a 48-hour monitoring window, then move to -all if nothing spikes. Rollback takes under 5 minutes if anything goes wrong.

This works because the concern is addressed directly without requiring technical fluency from the reader. The evidence is there. The rollback plan is there. The person blocking removal now has a defensible reason to say yes.

Step 3: Remove the Include Safely

Once you have approval, stage the change in phases.

Phase 1 - Change -all to ~all. This keeps the record functional but treats failures as softfail instead of fail. Wait 24-48 hours and check your DMARC failure rate. If it spikes, revert. If it stays flat, proceed.

Phase 2 - Remove the include entirely. If you have -all or ~all already, just remove the stale include: mechanism. If you have +all (which passes everything - a security problem), fix that first.

Phase 3 - Monitor for 48-72 hours. Watch DMARC failure rates and your inbox. If nothing unusual appears, the removal is clean.

Rollback is restoring the previous TXT record from your documentation. SPF record TTLs are typically short (300-3600 seconds), so a full rollback takes effect in minutes.

Before and after example:

Before (9 lookups - one away from the ceiling):

v=spf1 include:_spf.legacyvendor.com include:_spf.google.com include:_spf.salesforce.com ~all

After removing the stale vendor include (7 lookups):

v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

The stale includes freed up 2 lookups. If your remaining includes are still approaching the limit, SPF flattening (replacing include: with direct ip4: entries) can reduce the count further.

`When You Cannot Remove It: SPF Flattening and Subdomain Strategies`

Sometimes removal genuinely isn't possible - the vendor is still authorized, legal won't approve, or the include is buried in a contract you cannot renegotiate. Two strategies reduce the lookup burden.

SPF flattening replaces include: mechanisms with their actual IP ranges. Where you have include:_spf.vendor.com, you resolve the IPs and substitute them directly: ip4:203.0.113.0/24 ip4:198.51.100.0/24. This eliminates the lookup but creates fragility - if the vendor's IPs change, your flattened record becomes stale and will silently break. Only flatten when you have a reliable process for tracking vendor IP changes, or a tool that keeps the record updated automatically.

Subdomain delegation moves less-critical sending to a subdomain with its own separate SPF record. Authentication failures on subdomains don't affect the primary domain's deliverability. This is a workaround, not a solution - but it buys time.

Neither approach solves the organizational problem. But both let you function within the lookup limit while you continue making the case for removal.

`The Real Problem Is Organizational, Not Technical`

Getting a legacy SPF include removed is a technical task with an organizational wrapper. The DNS work is straightforward. The hard part is that nobody wants to be the person who broke email by touching something that "worked."

That resistance is not irrational. But it is addressable. Collect the data. Show the lookup count. Demonstrate the unused include. Present the rollback plan. Make it easy to say yes.

Once the evidence is in front of them, they either approve or they explain why zero appearances in 30 days of DMARC reports is wrong. Either way, the decision becomes about the data, not about trust.

`Frequently Asked Questions`

How do I check if a domain in my SPF include is still sending mail?

Check your DMARC aggregate reports. Look for any auth results from the included domain. A domain that appears in the include chain but generates zero reports means the vendor is not sending or their mail is being rejected before it reaches a DMARC-enabled receiver. Cross-reference with your MTA send logs for confirmation.

My stakeholders won't approve without a guarantee nothing breaks. What do I do?

There is no zero-risk option, but you can reduce risk to near-zero: switch to ~all first, monitor DMARC failure rates for 48-72 hours, then move to the final record only if nothing spikes. This gives you a rollback window with no permanent change to the final state.

The include is from a vendor we stopped using but they still have access to send on our behalf. What then?

This is a security problem, not just a deliverability problem. Audit what access the former vendor still has - SMTP credentials, API keys, send-as permissions. Revoke those first, then remove the include. An unused include with active credentials is a vector for unauthorized sending.

We really cannot remove this. Is there a tool that can help us stay within the 10-lookup limit?

Flattening tools resolve include chains and replace them with IP ranges. DMARCFlow can help identify which includes are generating auth failures versus which are truly silent, giving you the data to make the case for removal or confirm that flattening is the right tradeoff for your situation.

What does -all at the end of an SPF record actually mean?

-all means "reject mail that doesn't match any of the above mechanisms." ~all means "softfail mail that doesn't match." +all means "accept everything" and is almost never correct on a production domain. If you change from -all to ~all` as a rollback step, you are widening the acceptable window - watch your DMARC failure rates during that window.