An SPF change is a change to who can send mail as your organisation. Get it wrong and the symptom is other people’s mail silently failing, reported hours later by a customer rather than by monitoring. The sequence below is what makes it undoable.
The sequence
T-48h Lower the TTL on the TXT record to 300.
Must be at least one CURRENT TTL ahead of the change.
T-24h Confirm the short TTL is being served:
dig +noall +answer TXT acme.com
T-1h Write down the current record, verbatim. This is the rollback.
Write down the expected lookup count after the change.
T-0 Publish.
T+5m Verify against the authoritative server, then public resolvers.
Re-run the budget audit. Does it match what you predicted?
T+1h Send a real message through each affected sender and read
Authentication-Results.
T+24h Check aggregate reports for a new failing source.
T+48h Raise the TTL back.Lowering the TTL at the same time as the change does nothing
Resolvers holding the old record were told to keep it for the old duration, and they will. The reduction has to lead the change by a full old-TTL period, which is why "we will lower the TTL when we do the migration" is a plan with a hole in it. The TTL governs your rollback as much as your change.
Verify in the right order
# what you published dig +noall +answer @ns1.acme.com TXT acme.com # what the world sees for r in 1.1.1.1 8.8.8.8 9.9.9.9; do echo "== $r"; dig +short @$r TXT acme.com | grep spf1 done # and the thing that actually matters # send a message; read Return-Path and Authentication-Results
The authoritative server tells you whether you published what you meant. A public resolver tells you what receivers are getting. A real message tells you whether it works. They are three different questions and only the third is the one anyone asked.
Four rules
- One change at a time. Adding a sender and tightening
~allto-allin one edit means a failure has two candidate causes. - Never edit a live record by retyping it. Copy, modify, diff, paste. A dropped character in a CIDR is valid syntax authorising the wrong range.
- Re-count after every change. The prediction you wrote down is what makes the audit a check rather than a formality.
- Keep the previous record somewhere findable. Under pressure, "what was it before" is the question nobody can answer, and a screenshot in a chat thread is not a rollback plan.