How a correct record stops being correct

A correct SPF record does not stay correct. Almost everything that breaks one is a change somebody else made, which is why "we set that up last year" is not an answer to "is it working".

Five ways it decays

What happens	Caused by	How it surfaces
The lookup count rises past 10	A platform adds an include to its own record.	permerror. SPF is off entirely, including for hosts you listed.
Void lookups accumulate	A vendor is decommissioned and their name stops resolving.	permerror, and a lookup count that does not explain it.
A flattened range goes stale	The platform renumbers.	Silent. Legitimate mail fails one host at a time.
A sender appears	A team signs up for something with a card.	Mail failing from a source nobody authorised — visible only in reports.
mx cost grows	Someone adds a fourth MX host for redundancy.	One more lookup, from a change unrelated to email authentication.

Four of those five happen without anyone touching your SPF record, and two produce a hard failure with no warning at all.

What to actually monitor

The lookup count, on a schedule. Not whether it is valid — the number, with an alert on the trend. Going from 8 to 9 is the warning; going to 11 is the incident.
Void lookups. Any include target that stops resolving, checked as its own thing rather than inferred from the count.
The record itself, diffed. An unexpected change is either a colleague who did not tell you or something worse.
SPF results in aggregate reports. A rising permerror or temperror share is the earliest external signal, and it arrives before anyone complains.
New sending sources. The reports name them; nobody else will.

Alert on headroom, not on breakage

A check that fires when the record is already at permerror has told you after the outage started. Alert at 9 of 10. The gap between 9 and 11 is one vendor’s routine change, and it is the only window in which the fix is cheap.

A review cadence

daily      automated: lookup count, void lookups, record diff
weekly     aggregate reports: permerror/temperror share, new sources
quarterly  re-classify the estate; retire vendors nobody uses
at renewal ask unalignable vendors again — the answer changes

Write it down

The register from module 5 and the inventory from module 6 are what let someone else take this over. Without them, the next person inherits a record, no idea which of the eight includes is still needed, and no safe way to find out — which is how records end up with vendors from 2019 in them.

Knowledge check

An SPF record has not been edited in eighteen months. Today receivers begin reporting permerror. What is the most plausible explanation?

A platform you include restructured its own record and added lookups, pushing the cumulative total past ten.
The record’s TTL expired and it needs republishing.
Receivers have tightened their interpretation of the limit.
DNS caches expired, so the record is being re-read.

Correct — A platform you include restructured its own record and added lookups, pushing the cumulative total past ten. An include costs one lookup plus the entire cost of someone else’s record, and they change theirs without telling you. This is why the budget needs monitoring rather than a one-time count — the record goes over on its own.

Not this — The record’s TTL expired and it needs republishing. TTL governs how long resolvers cache an answer. A record does not need republishing when its TTL elapses, and nothing about expiry produces permerror.

Not this — Receivers have tightened their interpretation of the limit. The limit is fixed at ten in RFC 7208 and has not changed. A coordinated reinterpretation across receivers is not what happened.

Not this — DNS caches expired, so the record is being re-read. Re-reading an unchanged, valid record produces the same valid result. Something in the tree beneath it changed.

Five ways it decays

What to actually monitor

A review cadence

Write it down

Try it on a real domain