An unused-looking SPF permission may still support an annual campaign, a failover route or several applications behind one include. An agent should prepare a retirement case rather than deleting permissions because a reporting window is quiet. The risk is not just a syntax error: a valid edited record can stop legitimate mail from authenticating.
Inventory the authority being removed
Expand the dependency conceptually and identify the service owner, account, affected applications and retirement evidence. RFC 7208 defines include evaluation and limits DNS-querying terms; it does not say a missing aggregate-report observation proves an authorization is obsolete.
Compare expected schedules with the observation period. Check failover and incident-only senders, vendor migration overlap and forwarding paths. Preserve the current record and dependencies with retrieval times. A shared include must not be removed solely because one customer application retired.
Require positive retirement evidence
Use positive owner-confirmed decommissioning and a dependency review. Consider this written ledger with a hypothetical observation interval of 1–30 September 2026 UTC; it is not actual monitoring data.
- Seasonal service: include:seasonal.test, expected run in December, no September traffic stipulated, retirement unconfirmed. Hold and review the service schedule with its owner.
- Shared service: include:shared.test, app-A retired but app-B still active by assumption. Retain the shared include while app-B depends on it.
- Dedicated retired service: include:retired.test, decommission and no remaining dependents stipulated. Prepare a removal candidate for owner review; actual evidence and approval remain to be supplied.
- Annual trap: include:annual.test, expected run in January, no September traffic stipulated. Keep unresolved; the observation window excludes the expected run.
Only the dedicated case is a proposed candidate. No classifier, DNS resolver or mail test ran, and no service was actually retired. These reserved-domain labels must never be copied as production configuration.
Prepare and review the narrowed record
Show the exact before and after text, affected identities, expected effect, test plan and rollback trigger. Re-evaluate SPF syntax and DNS-querying behavior after the edit. Removing one dependency can change which later terms are reached, so do not assume that a shorter record is automatically correct.
Approval must identify the tenant and exact change. If the live baseline changed meanwhile, stop and reconcile. Apply through authorized change control only. This written ledger proposes a recommendation and publishes nothing. Its result is safe to read as a candidate decision, not as a completed retirement.
Observe after the change
Test representative legitimate flows and monitor relevant receiver reports across the service schedules. Keep rollback time-bounded and retain the previous configuration securely. A new authentication failure needs identity and route analysis rather than automatic restoration of every old permission.
Report the reduction in explicit authority separately from deliverability or spoofing claims. DMARC can pass through aligned DKIM even when SPF fails, so a high DMARC pass rate alone cannot establish that an SPF change had no effect. RFC 9989 explains the alternative aligned authentication paths. The decision record should say what was removed, why, who approved it and what evidence supports closure.
Retain an exception when a dependency cannot yet be resolved. Give it an owner and a date tied to the next expected service run. Repeatedly extending an exception without collecting evidence should become an explicit risk decision rather than an invisible permanent permission.
Primary reading: RFC 7208 SPF, RFC 9990 DMARC Aggregate Reporting, RFC 9989 DMARC.