A stale flattened SPF record is an authorisation copy that no longer represents its intended source. It may omit a newly used sending range, retain one that should have been removed, or combine both errors. The visible symptom may be failed mail, but the absence of complaints does not prove the copy is current.
Identify which copy is being maintained
Record the envelope domain, current SPF value and the system that generated it. Locate the original provider dependencies and the last successful generation and publication timestamps. If nobody can identify the upstream input, treat that missing provenance as a maintenance defect rather than guessing from the current addresses.
Keep three states distinct: the provider's current documented authorisation, the generator's latest output and the record receivers can resolve. A successful generation with a failed DNS update produces a different repair task from a generator that never noticed the provider change.
Compare additions and removals independently
Build a controlled comparison using the supported semantics of the original policy. RFC 7208 defines includes as evaluations, so an address scrape is not a sufficient baseline for policies with conditions or macros. Record any unsupported construct and stop automated replacement until its effect is understood.
An addition missing from the published copy is a potential delivery problem for a legitimate sender using that range. A removed range still present is an excess-authorisation problem. Give each difference an owner and reason. Do not call the record repaired merely because the most visible failing sender now passes.
In an illustrative incident, a provider starts using 192.0.2.40 while an old flattened copy contains only 192.0.2.10. Those documentation addresses are synthetic, not deployment values. Adding the observed address may hide the immediate failure while missing the rest of the provider's supported pool. Confirm the provider's intended scope before preparing a complete correction.
Find the failed stage
Check the refresh schedule, job status, upstream query results, parser warnings, generated diff, approval queue and publication receipt. Then query the published record and compare it with the intended output. Retain query times and resolver identities so a cached answer is not confused with a failed write.
DNS caching is a separate layer from generator freshness. Reducing a TTL does not make an old copied address list correct. It also does not force every resolver to discard data it already cached. Use observed answers, prior configuration and possible serve-stale behavior under RFC 8767 §4 when assessing convergence, rather than promising a universal propagation time.
Repair without widening trust
Save the current record and the proposed replacement. Resolve every unexpected added range before publication. Do not authorise an entire cloud provider because a single new sender appeared there. The origin of a network is not proof that the network should send using your envelope identity.
Validate the candidate's syntax, evaluated lookup paths, address families and terminal result. Confirm that only one applicable SPF record will exist at the owner name. After approval, publish through the established change process and test the affected application through its ordinary route.
Add a freshness signal that can fail visibly
Recommended monitoring should distinguish “last job ran,” “last source read succeeded,” “last output changed,” and “last publication verified.” A source that has not changed for a month can still be healthy; a job that reports success while repeatedly reusing failed input is not. Choose alert thresholds around business risk and the provider's operating model, not an invented protocol refresh interval.
Close the incident with a before-and-after comparison, received-message evidence and an explanation of the failed stage. Keep a follow-up owner for withdrawn ranges and recurring failures. If the copy cannot be maintained reliably, reconsider the model using flattening tradeoffs rather than repeatedly applying emergency address patches.
DNS background: RFC 1035 section 3.2.1 defines resource-record TTL; RFC 2308 §5 covers negative caching; RFC 8767 §4 updates TTL semantics and permits stale use when authoritative refresh fails. These describe DNS behaviour, not a universal completion time for a change.
Record the next decision
Use one row per range difference: added or withdrawn; provider evidence; generator version/time; approved output; authoritative answer/time; recursive answer/time; and affected route. Current generation plus old authoritative data points toward publication; current authoritative data plus an old recursive answer calls for resolver-state investigation. These are diagnostic branches, not measured incidents, and stale use can complicate timing.