How to Update Email DNS Records Without Causing Downtime

DNS changes are among the most disruptive things you can do to an email system — and also one of the most routinely handled incorrectly. The mistakes aren't complicated: wrong order of operations, ignoring TTL values, not testing before cutting over, or making too many changes at once. Any of them can drop email during the transition window, which for a business can mean lost orders, missed communications, and hours of troubleshooting under pressure.

The good news is that making email DNS changes safely is straightforward once you understand what's happening at each step. Here's how to approach it.

Understand TTL Before You Touch Anything

TTL — Time To Live — controls how long DNS resolvers cache your records before checking for updates. It's measured in seconds. A TTL of 3600 means resolvers can cache that record for an hour. A TTL of 86400 means they can cache it for a day.

TTL is the primary cause of "I changed the record but it's not working yet" — and more importantly, it's why you need to start preparing for a DNS change well before you actually make it.

Before any planned DNS change, lower the TTL on the affected records to 300 seconds (5 minutes) or less. Do this 24–48 hours before your planned change window. That gives time for the lower TTL to propagate and replace cached values. Once you've made the change, resolvers will start picking up the new values within minutes instead of hours.

After the change is confirmed working and stable, you can raise the TTL back to a longer value. High TTLs (1–24 hours) are fine for stable records because they reduce DNS query load. Low TTLs (5–10 minutes) are useful when you anticipate changes or are actively migrating, but they increase DNS query volume.

Changing MX Records: The Highest-Stakes Change

MX records tell the internet where to deliver email for your domain. Getting an MX change wrong means email goes to the wrong server, or nowhere.

The safe approach for any MX migration is to run both the old and new servers in parallel during the transition. Here's the sequence:

1. Lower TTL on existing MX records to 300 seconds. Wait 24–48 hours for the old TTL to expire everywhere.
2. Add the new MX records alongside the old ones, with a higher priority value (lower priority number = higher preference). Set the new server to a lower priority initially so it only receives mail if the old server is unavailable.
3. Verify the new mail server is accepting and processing mail correctly before you promote it.
4. Swap priorities — raise the new server's priority and lower the old server's, so the new server now receives mail first. Keep both active.
5. Monitor for 24–48 hours. Confirm no mail is misrouted. Watch the old server's logs to see volume drop to zero as TTL caches expire.
6. Remove the old MX records once mail flow is clean on the new server.
7. Restore normal TTL values on the new MX records.

The parallel operation window is the key protection. During that window, email can be delivered to either server, and you can catch problems before committing fully to the new configuration.

Updating SPF Records

SPF records specify which mail servers are authorized to send email for your domain. They're TXT records and typically have short TTLs, which makes them easier to update — but they still require care.

The most common SPF update scenarios:

Adding a New Sending Service

If you're adding a new email platform or SMTP relay, you need to add its include mechanism or IP range to your SPF record before you start sending from it. The sequence: update SPF first, verify the syntax, then configure the new service to send.

Never configure a new service to send before updating SPF. Messages will fail SPF checks during the window where you're sending but haven't updated the record, which damages deliverability and potentially triggers DMARC failures.

SPF Record Syntax

SPF has a hard limit of 10 DNS lookups per evaluation. Complex records with many include: mechanisms can exceed this limit, causing SPF to return a permerror — which is treated as a failure by strict receivers. Before adding another include, count your existing lookup mechanisms. If you're near the limit, consider flattening your SPF record (replacing includes with direct IP ranges) or using a service that manages SPF flattening automatically.

Always validate the updated record syntax with a tool before publishing it. A typo in an SPF record breaks authentication for your entire domain.

Rotating DKIM Keys

DKIM key rotation — replacing an existing signing key with a new one — is one of the trickier DNS changes because the keys need to match between your mail server's configuration and your DNS.

The safe sequence:

1. Generate the new key pair on your mail server or in your sending platform.
2. Publish the new public key in DNS as a new DKIM selector (e.g., selector2._domainkey.yourdomain.com) before you start using it for signing. This is the parallel operation that prevents failures — both keys exist in DNS simultaneously.
3. Wait for the new DKIM DNS record to propagate — at least the duration of its current TTL, ideally longer.
4. Configure your mail server or platform to sign with the new key.
5. Verify that outgoing messages are being signed with the new key and that signatures are validating.
6. Remove the old DKIM selector from DNS only after you're confident all mail is signing with the new key. Keep the old record for at least 48 hours after the switchover to allow for in-flight messages signed with the old key to be delivered and validated.

The old key should stay in DNS longer than you think you need it. Messages that were signed with the old key while in the queue will still need that key to validate when they're delivered.

Updating DMARC Policy

DMARC policy changes are generally low-risk because DMARC records describe policy rather than actively routing mail. The risk is in moving too quickly to a strict policy (p=reject) before your authentication is clean.

If you're tightening DMARC policy — moving from p=none to p=quarantine to p=reject — do it in stages with monitoring between each stage. Moving directly to p=reject without first confirming that all your legitimate sending sources pass SPF and DKIM alignment will cause legitimate mail to be rejected.

Use the percentage (pct) tag to apply the policy to a fraction of traffic first. Start at pct=10, monitor DMARC aggregate reports for failures, resolve any alignment issues, and increment gradually. MailDog's guide on reading DMARC reports covers how to interpret the data at each stage.

Changes to Avoid Doing Simultaneously

Making multiple DNS changes at the same time is tempting — "let's get everything updated at once" — but it makes troubleshooting nearly impossible if something goes wrong. If you change MX records, SPF, and DKIM in the same window and mail stops flowing, which change caused it?

Sequence changes with monitoring time between them. In a planned migration, the order typically looks like:

1. Lower TTLs across all affected records (24–48 hours before)
2. Publish new DKIM public key
3. Update SPF to include new sending sources
4. Switch mail server signing to new DKIM key; verify
5. Add new MX records at lower priority; verify new server receives and processes mail
6. Promote new MX to primary; monitor
7. Remove old MX; verify; restore TTLs
8. Remove old DKIM selector

Verification At Every Step

DNS changes should always be followed by verification before moving to the next step. Tools you'll use regularly:

• dig MX yourdomain.com — check current MX records from your terminal
• dig TXT yourdomain.com — check SPF and DMARC records
• dig TXT selector._domainkey.yourdomain.com — check DKIM public key
• MXToolbox or similar online tools — verify propagation from external resolvers
• Send a test message and check headers — confirms what's actually being used for signing and routing

MailDog's DNS security tools can also audit your current configuration and flag common issues. For documentation on configuring email DNS records for MailDog's mail service, see the setup guides. If you're planning a migration and want to talk through the sequence, the support team can help you plan the change window safely.

The Underlying Rule

The principle behind all of this is: publish before you send, and keep the old thing working until the new thing is proven. For MX changes, run both servers. For DKIM, publish the new key before signing with it. For SPF, add new senders before they send. The window where both configurations are active is your safety net — use it.