A rollback changes future observations; it cannot reach into every sender and erase a cached policy. When an enforce policy starts delaying legitimate mail, preserve the exact broken revision and find the fastest way to make a receiving path satisfy the policy that senders may already hold.
Stabilize delivery before removing controls
References: RFC 8461 §4, RFC 8461 §5.1.
Identify whether the failure is an omitted MX, a certificate problem, lost STARTTLS support or policy-fetch trouble. Restoring a previously compliant MX or repairing its certificate may help senders with both old and new cached policies more directly than attempting an emergency global policy withdrawal.
Check the affected sender's logs where available and test every intended receiving candidate. If one compliant MX remains, senders may be able to use it. Do not assume a backup is safe merely because its DNS preference is lower priority; it still needs to match the policy and pass transport validation.
Choose repair or deliberate withdrawal
References: RFC 8461 §3.2, RFC 8461 §8.1, RFC 8461 §8.3.
For a repair, publish the corrected HTTPS body before changing the TXT id. Keep previous policy copies and max_age values available to calculate the transition risk. A corrected current body does not prove that a sender has fetched it.
For deliberate removal, RFC 8461 section 8.3 recommends serving mode none with a small max_age (for example, one day) and updating the discovery record, then retaining the relevant policy infrastructure until all previously served policies have expired before removing it. Compute each version’s last-served time plus its own max_age, then use the latest expiry across every version. An older version with a longer lifetime can outlast the immediately preceding one. A none policy still needs version and max_age; mx lines are not required in that mode. Use a new valid id to announce the change.
Reproduce the stale-enforce case
References: RFC 8461 §3.3, RFC 8461 §5.
In a controlled sender, cache an enforce policy permitting only mx1.example.net with max_age 86400. Change public DNS and HTTPS to a none policy, but initially prevent that sender from obtaining the update. Attempt delivery to mx2.example.net. The old valid enforce policy still excludes mx2, despite the operator's new none body.
Then permit refresh and capture the sender applying none, or advance the controlled test clock through the original cache lifetime in a safe isolated environment. Do not change clocks on production mail infrastructure for this test. This is a lab procedure, not an executed MTA test; the new offline fixture demonstrates only state and last-served-lifetime arithmetic, not a real sender cache.
Close with evidence for both cohorts
References: RFC 8461 §8.3, RFC 8460 §4.1.
Verify behavior for a fresh sender with no cached policy and for a sender known to hold the previous enforce revision. Preserve queue outcomes, fetch results and policy metadata. TLS-RPT can help identify remaining failures but coverage is incomplete and reporting is delayed.
Keep the HTTPS host and discovery available during the planned withdrawal window, monitor the actual delivery path and document the final removal decision. Deleting _mta-sts alone is neither an immediate rollback nor a reliable incident-recovery strategy.
Retained historical evidence and remaining scope
The following describes preserved 7 November 2026 observations, not a network experiment rerun for this review. Newly executed offline checks are recorded separately.
The withdrawal calculation now includes every previously served version rather than only the latest max_age. In the executed logical ledger, A1 was last served at 1000300 with lifetime 86400, B2 at 1000600 with lifetime 3600, and C3 at 1000900 with lifetime 3600. Their expiry bounds are 1086700, 1004200 and 1004500 respectively. The computed removal boundary is therefore 1086700. The old A1 sender snapshot still rejects the new-only hostname even after the lab advertises and fetches B2. Restoring the old compatible route remains meaningful for that snapshot. This is a labelled state-and-route calculation, not an observed remote cache withdrawal or queued-message recovery. A production withdrawal must use actual last-served times and all prior versions.