How to Make DNS Changes Without Causing Email Downtime

There's a specific kind of anxiety that comes with making DNS changes to a live email domain. One wrong move and mail starts bouncing, and by the time you notice, hours of messages may already be lost. The good news is that DNS changes are manageable — they just require preparation, the right sequence, and patience.

This guide walks through how to plan and execute DNS changes that affect email delivery without causing downtime.

Why DNS Changes Are Risky for Email

Email routing depends on several DNS records that all need to be correct simultaneously. Your MX records tell other servers where to deliver mail for your domain. Your SPF record authorizes your sending infrastructure. Your DKIM records hold the public keys for signature verification. Your DMARC record specifies what to do when authentication fails.

When you change a DNS record, the change doesn't propagate to all DNS resolvers instantly. Depending on the TTL (time to live) of the record, different servers across the internet will see different values for an extended period. During this window, some senders will route to your old mail server; others will route to the new one. Mail can end up delivered inconsistently or, in the worst case, rejected entirely.

Understanding how TTL values affect propagation is the foundation of safe DNS change management.

Start Early: Lower TTLs Well in Advance

The single most important thing you can do before a DNS change is reduce your TTLs. Standard TTLs for email records are often 3,600 seconds (one hour) or higher. Some registrars set defaults of 86,400 seconds (24 hours).

With a 24-hour TTL, after you make a change, DNS resolvers that cached the old record may continue routing to the old server for up to 24 hours. If you've already taken the old server offline, those deliveries fail.

The fix: lower your TTLs to 300 seconds (5 minutes) at least 48 hours before you plan to make the change. This reduces the maximum propagation delay to 5 minutes. Once the change is complete and verified, raise the TTLs back to a reasonable value.

If you're using a DNS host with a minimum TTL higher than 300 seconds, use whatever minimum they allow — even 600 seconds (10 minutes) is far better than a multi-hour TTL during a cutover.

The Right Order for MX Record Changes

If you're migrating to a new mail server, the sequence matters. Don't cut over the MX records and then migrate data — that's backwards. The correct order:

1. Set up the new mail server fully. It should be accepting connections and delivering mail correctly before any MX records change.
2. Test the new server directly by connecting to it manually (using telnet or openssl s_client) and confirming it accepts mail for your domain.
3. Add the new server as a lower-priority MX record alongside the existing one. This means it starts receiving some mail while the old server continues to handle most traffic. Watch for a few hours to confirm delivery is working.
4. Raise the new server's priority (lower MX priority number) so it becomes the primary. Keep the old server as a backup with a higher priority number for now.
5. Monitor for 24–48 hours. Watch mail logs on both servers.
6. Remove the old server's MX record once you're confident traffic has fully shifted.

This gradual approach means no mail is lost even if the new server has problems — the old server catches anything that falls through.

For a detailed look at how MX records work and what the priority numbers mean, the MX records explainer covers the protocol mechanics.

SPF and DKIM During a Migration

When migrating email infrastructure, authentication records need careful attention. If you update your MX records to point to the new server but don't update your SPF record to include the new server's sending IP, outbound mail from the new server will fail SPF checks.

The sequence for authentication records:

• Before cutover: Add the new server's IP to your SPF record alongside the old server's IP. This way, both servers can send authenticated mail during the transition period.
• For DKIM: Generate new DKIM keys on the new server and publish them in DNS before you start routing mail through it. Run both old and new DKIM selectors simultaneously during the transition.
• After cutover is stable: Remove the old server's IP from SPF and retire the old DKIM selector. Don't rush this — wait at least a week to be certain no legitimate mail is still routing through the old infrastructure.

Verifying Propagation After Changes

After making DNS changes, don't assume they've propagated everywhere just because they look correct from your location. Your own resolver may have cached the updated record while resolvers elsewhere still hold the old value.

Tools for checking propagation:

• dnschecker.org: Shows your record as seen from dozens of geographic locations simultaneously
• dig with a specific nameserver: dig MX yourdomain.com @8.8.8.8 queries Google's public resolver directly
• MXToolbox: Validates your MX records and highlights configuration problems

Check from at least three different external resolvers before considering the change fully propagated.

Timing Your Changes

When you make DNS changes matters almost as much as how you make them. Avoid:

• Friday afternoon changes (if something goes wrong, you're debugging over the weekend)
• Changes during business hours when mail traffic is at its peak
• Changes during active promotional campaigns or high-send periods
• Making multiple infrastructure changes simultaneously

The safest window is early in the week, during off-peak hours for your region — Tuesday or Wednesday morning before the business day starts. This gives you maximum working time to observe and respond if anything unexpected occurs.

Rollback Planning

Before making any DNS change that affects email routing, document your current configuration completely and know exactly how to revert it. If your TTLs are already low, rolling back is fast. If your TTLs are still high and something goes wrong, recovery will be slow and painful.

Keep a running change log with timestamps for every record modification. If you need to diagnose a problem hours later, knowing the exact sequence of changes and when they happened is invaluable.

If you're migrating to MailDog and want help planning the DNS transition, the email hosting migration checklist and the DNS tools are good starting points. The full configuration details are in the documentation.