How to Make DNS Changes Without Breaking Email Delivery

Why DNS Changes Are the Most Common Cause of Self-Inflicted Email Outages

The ability to make DNS changes without breaking email delivery is a skill that's easy to underestimate until you've caused an outage. DNS looks simple — just records in a zone file. But email depends on DNS across multiple layers simultaneously: MX records for routing, SPF TXT records for authentication, DKIM TXT records for signing verification, DMARC TXT records for policy enforcement, and PTR records for reverse lookup. Change any one of them incorrectly, at the wrong time, or without understanding how caching works, and you can stop mail from being delivered or authenticated for hours.

This guide covers how to make DNS changes safely — what to verify before touching anything, how to sequence changes, how to use TTL as your safety net, and how to roll back when something goes wrong.

The Pre-Change Checklist

Before modifying any DNS record related to email, confirm:

• Current record values: Document exactly what every relevant record says right now. Use dig or a web-based DNS lookup to capture the current MX, SPF, DKIM, and DMARC records before you change anything.
• Current TTL values: Note the TTL on each record. This tells you how long the old value will persist in resolver caches after you change it.
• Dependencies: Does your ESP use a CNAME for DKIM that would break if you changed the underlying record? Are there third-party senders in your SPF that need to stay? Who else is sending from your domain?
• Propagation behavior: Some DNS providers push changes to all nameservers within minutes. Others have queuing delays. Know which applies before you start.

Using TTL as Your Safety Net

TTL (Time to Live) controls how long DNS resolvers cache a record before asking for a fresh copy. A record with a 3600-second (one hour) TTL will continue delivering the old value to most resolvers for up to an hour after you make a change.

For planned changes, lower the TTL before you make the actual modification:

1. At least twice your current TTL before the planned change, lower the TTL to 300 seconds (5 minutes)
2. Wait for the old TTL to expire so resolvers are already picking up the shortened value
3. Make the actual record change
4. Verify the new value is propagating correctly using dig against multiple resolvers
5. Once the change is confirmed stable, raise the TTL back to a sensible value (1800–3600 seconds)

This technique means that if something goes wrong after the change, reverting takes 5 minutes instead of 24 hours. The additional planning time is worth it for any record that affects email delivery.

Changing MX Records Safely

MX records control where inbound mail is delivered. Changing them incorrectly means mail either goes to the old server (which may be decommissioned) or queues at sending servers that can't reach the new destination.

Safe MX migration process:

1. Set up and fully verify the new mail server first — it should be configured and accepting test connections before you touch the MX record
2. Lower the MX record TTL well before the planned change
3. Add the new MX record with a higher priority number (lower preference) while keeping the old MX temporarily active, so mail continues flowing during transition
4. Once the new server is confirmed working as primary, give sending servers time to pick up the updated record
5. Remove the old MX record only after confirming no new mail is arriving there

For context on how MX records and backup MX work, see MailDog's guide on how email routing works.

Updating SPF Records Without Causing Authentication Failures

SPF records are particularly sensitive because a syntax error — a double space, an extra mechanism, or a malformed IP range — will cause the record to fail to parse, and suddenly every message you send fails SPF validation simultaneously across all receiving servers.

Rules for safe SPF changes:

• Validate the complete new SPF record in an SPF syntax checker before publishing it
• Don't exceed 10 DNS lookups — this is a hard limit in the SPF specification that silently causes failures when exceeded
• Change only one mechanism at a time when adding or removing authorized senders
• After publishing, send a test message and verify the SPF result in the Authentication-Results header

Rotating DKIM Keys Without Causing Signing Failures

DKIM key rotation is a security best practice that requires careful sequencing. The new public key must be published in DNS and fully propagated before you start signing messages with the new private key. Reversing that order — rotating the signing key before the DNS record is live — causes DKIM failures on every message until the new TXT record propagates.

1. Generate the new key pair
2. Publish the new public key as a new DKIM TXT record using a different selector (e.g., mail2025._domainkey vs mail2024._domainkey)
3. Wait for propagation and verify the new selector resolves correctly with dig TXT mail2025._domainkey.yourdomain.com
4. Switch your mail server's signing configuration to the new key and selector
5. Leave the old selector in DNS for 30–60 days before removing it, to cover delayed or cached message delivery

Verifying After Every Change

After any DNS change affecting email records, run a verification pass before considering the work done:

• Send a test message to a Gmail account and inspect the full email headers for authentication results
• Confirm MX records with dig MX yourdomain.com against multiple resolvers
• Check Google Postmaster Tools for any sudden authentication failure signals in the next 24 hours
• Confirm that DMARC aggregate reports continue arriving after the change

For a comprehensive guide to configuring and validating your email authentication records, see MailDog's DNS security documentation. The docs portal covers DKIM selector setup and SPF record syntax for hosted accounts. If you're planning infrastructure changes and want a second set of eyes on your configuration, reach out to the team before making changes in production.