How SPF records rot

An SPF record can go from passing to permanently failing without anyone at your company touching it. That sounds like a paradox until you remember what an SPF record mostly is: a list of pointers into other companies' DNS. You published the pointers. They control what sits behind them. Watching SPF break on monitored domains, I see the same five failure modes over and over, and only one of them requires you to make a mistake.

You know the mechanics from SPF, explained: one TXT record starting v=spf1, evaluated against the Return-Path domain, with a hard budget of 10 DNS lookups set by RFC 7208. What that lesson couldn't show you is the same record three years later. This one does.

Rot mode 1: the include chain drifts on its own

An include: mechanism is a live reference, resolved fresh every time a receiver evaluates your mail. It is never a snapshot. And includes nest: the vendor record you point at contains its own includes, which contain their own. Every include, a, mx, ptr, and exists mechanism in that whole expanded tree, plus any redirect, counts against your single budget of 10 lookups. ip4, ip6, and all cost nothing, which matters later.

The trap plays out in slow motion. The day you assemble your record, the tree resolves to, say, 7 lookups. Comfortable. Then one of your vendors reorganizes their sending infrastructure and splits their single include into three regional ones. Their change, their DNS, their reasons. Your count is now 9. A second vendor does something similar next quarter and you're at 11, past the limit, and every receiver evaluating your mail returns permerror. Your zone file is byte-for-byte identical to the one that passed last month.

No email arrives announcing that a vendor restructured their SPF. There is no changelog you could have subscribed to. The first symptom is downstream, in placement, weeks later.

Rot mode 2: lookup creep

Drift is the vendors moving. Creep is you accumulating.

Tools pile up over years. The workspace provider was first. Then the CRM, the helpdesk, the billing system, the survey tool. Each onboarding doc says "add our include to your SPF record", and each one costs at least one lookup, often more once its own tree expands. Nobody ever removes an include. Removals feel dangerous (who wants to be the person who broke email?), so the record only grows.

The uncomfortable part: a record at 9 lookups behaves perfectly and looks identical to a record at 11. SPF has no warning state. You get no yellow zone, only the cliff edge, and most teams find the cliff by falling off it during an onboarding that added one more include.

Dead includes make this worse than it needs to be. That outreach tool you cancelled in 2022 still holds its slot in your record, still burning lookups, and still authorizing a company you no longer pay to send mail as you. Pruning dead includes is the single cheapest SPF maintenance there is, and almost nobody does it.

One more wrinkle: a permerror here can hide for months. DMARC passes when either SPF or DKIM passes and aligns, so a healthy DKIM signature masks a dead SPF leg completely. Then DKIM has one bad day and everything folders at once. The rot was old; the symptom is what's new.

Rot mode 3: the second record

This is the one self-inflicted mode, and it happens on onboarding day. A vendor's setup doc shows a complete example record, something like v=spf1 include:vendor.example ~all, and whoever is doing the setup pastes it into DNS as a brand-new TXT record instead of merging the include: into the record that already exists. RFC 7208 is blunt about what happens next: more than one SPF record on a domain is an immediate permerror. Receivers don't merge them, and they don't prefer the newer one. Every SPF evaluation on the domain now fails, including for the tools that were configured perfectly for years.

The place I see this most is MailerLite setups, for a structural reason: MailerLite is one of the few ESPs that asks customers to touch SPF at all (an include on mlsend.com). Most ESPs use their own envelope domain and never send you near your SPF record. So a MailerLite onboarding is often the first time a marketer has ever edited SPF, the doc shows a full example record, and the paste-as-new-record mistake writes itself. Our MailerLite checker probes for exactly this failure because of how often it's the answer.

The signature of this mode: instant and total, yet invisible from inside the tools. The ESP dashboard still shows green, because the record it asked for does exist. The free health check counts SPF records before it evaluates anything else, for precisely this case.

Rot mode 4: flattening, the fix that decays

When a record blows the lookup budget, someone eventually suggests flattening: resolve every include down to its raw IP addresses and publish those as ip4: and ip6: mechanisms, which cost zero lookups. It works. The day you do it, the record passes and the budget problem is gone.

Then it starts aging. Vendors publish includes precisely so they can renumber their sending IPs without asking thousands of customers to edit DNS. Flattening opts you out of every future update. When the vendor shifts traffic onto new ranges, your frozen list silently stops covering part of their infrastructure, and some of your mail starts failing SPF depending on which vendor IP it happened to leave from. Intermittent failure, the most miserable kind to diagnose.

Automated flattening services re-resolve the tree on a schedule, which genuinely helps. But be honest about what you've bought: one more subscription whose lapse, or whose DNS API integration quietly breaking, resumes the decay where it left off. Flattening is a maintenance contract. Take it on if you must, and monitor it like one.

Rot mode 5: the migration wipe

Registrar transfers and DNS-host moves kill more SPF records than any attacker ever will. When a zone gets rebuilt at a new host, the A records and MX records come across fast, because the website and inbound mail visibly break without them and someone screams. TXT records look like clutter. Half of them genuinely are clutter (ancient site-verification tokens from services nobody remembers), so the person doing the migration triages them with a shrug, and the SPF record doesn't make the cut. Sometimes the import tool drops them on its own.

And nothing visibly breaks. Outbound mail keeps flowing, because most receivers treat a domain with no SPF record as "none" and degrade it softly rather than bouncing anything. DMARC loses its SPF leg without a sound. The symptom arrives weeks later as sagging opens, long after anyone would think to blame the hosting move.

What the five have in common

In four of the five, nobody on your side touched the SPF record; in the fifth, the person who touched DNS believed they were doing something unrelated. None of them produce an error message anywhere you look. All of them separate cause from symptom by weeks.

Which points at the only countermeasure that works: re-read the record the way receivers do, fully expanded, lookups counted, on a schedule rather than on suspicion. The health check does one pass of that right now, free. Making it continuous is the monitoring lesson.

The rot has a sibling on the signature side. How DKIM breaks over time is next, and its failures hide behind dashboards that stay green throughout.

Terms from this lesson

• include-chain drift - your SPF record failing because a vendor changed the record your include: points at, expanding the lookup tree without any change in your own DNS.
• lookup creep - the slow accumulation of includes as tools get added over years and never removed, edging the record toward the 10-lookup limit.
• dead include - an include: for a tool you no longer use. It still costs lookups and still authorizes that vendor to send as your domain.
• second-record accident - pasting a vendor's example SPF as a new TXT record instead of merging it. Two SPF records cause a permanent error on every evaluation.
• SPF flattening - replacing includes with their resolved ip4:/ip6: addresses to escape the lookup limit. The list goes stale when vendors renumber.
• migration wipe - losing TXT records (SPF among them) during a registrar or DNS-host move, because they look like clutter and nothing visibly breaks when they vanish.

Check yourself

1. Your SPF record has been returning permerror for months, yet placement only collapsed this week. What best explains the delay?

Receivers grant a grace period after a new permerrorA healthy DKIM signature kept DMARC passing until DKIM had a bad day, exposing the dead SPF legDNS caches kept serving the old, valid record until they expiredPermerror only affects a small share of receivers

2. The outreach tool you cancelled two years ago still has its include: in your SPF record. What does it cost you?

Nothing, since unused includes are skipped during evaluationA softfail on every message you sendLookups from your budget of 10, plus standing authorization for a vendor you no longer pay to send as your domainAn automatic listing on domain blocklists

3. Why does a flattened SPF record decay?

ip4 mechanisms count double against the lookup limitReceivers distrust records without includesFlattened records exceed the TXT length limit over timeThe vendor renumbers its sending IPs and the frozen list stops covering them

4. After a DNS-host migration drops your SPF record, why does the problem usually go unnoticed for weeks?

Mail keeps sending, since most receivers treat a missing record softly rather than bouncingDNS caches serve the old record indefinitelyThe new host emails a warning that gets ignoredSPF failures only affect inbound mail