EmailAuthKit

Email Authentication Change and Rollback Checklist

A DNS authentication change should have an evidence target and exact rollback value before publication.

Capture the baseline

Save the full existing record, name, type, TTL, provider, observed authentication results and known senders. A screenshot alone may omit significant text.

Define the hypothesis

State the exact problem and expected evidence—for example, DKIM should pass and align for messages sent by the billing platform.

Change one control

Avoid changing SPF, DKIM and DMARC enforcement simultaneously. One bounded change makes failures and recovery easier to attribute.

Wait for relevant caches

DNS propagation is not a single global moment. Use the TTL and provider behaviour to decide when tests are meaningful without assuming every resolver refreshes together.

Run production-path tests

Send through every affected legitimate workflow to independent recipients and inspect received headers. Check aggregate evidence over an appropriate period before broader enforcement.

Rollback and record

If legitimate mail fails, restore the exact previous value through the authorised DNS process and retest. Record the outcome, incident owner and next decision without storing credentials.

Authoritative references

Read the underlying standards and provider instructions before changing production DNS: RFC 7208 (SPF), RFC 9989 (DMARC), Google Workspace SPF guidance and your sending provider's current DKIM documentation.

Editorial responsibility

Published by Acerville Sparks Limited. Software assists research, drafting and automated record testing. Internet standards, provider documentation, reproducible checks and limitations are shown so readers can inspect the work. No independent deliverability consultant review is claimed. Reviewed 4 September 2026.

What this site does not do

No inbox guarantee. No live DNS checks. No storage of entered data. No passwords or private keys requested.