How to update DNS records during migration?

You're switching ESPs, and somewhere in the middle of that process you have a window where authentication could break. SPF fails, DKIM stops signing, and suddenly your emails are landing in spam or getting rejected entirely. It doesn't have to go that way if you sequence the DNS changes correctly.

Here's the order that keeps things safe.

Step 1: Lower your TTL values before you start

TTL (Time to Live) tells the internet how long to cache your DNS records. If yours are set to 24 hours and something goes wrong, you're stuck with the problem for a full day. A week before migration, lower your TTL to 300 seconds (5 minutes) on every record you plan to touch. That means SPF, DKIM, and DMARC. Fast TTL means fast recovery if you need to roll back.

Step 2: Add the new ESP's records alongside the old ones

Don't delete anything yet. For DKIM, your new ESP will give you a new selector (something like esp2._domainkey.yourdomain.com). Add it. The old one stays. You can have multiple DKIM selectors active at the same time without any conflict.

For SPF, include the new ESP's sending mechanism in your existing SPF record. If your current record includes your old ESP's include: tag, add the new one next to it. Don't start a second SPF record. You're only allowed one SPF record per domain. Merging them into a single record is the move.

DMARC can stay exactly as it is through this step. No changes needed yet.

Step 3: Test before sending a single email from the new ESP

Send a test message from the new ESP to an address you control. Check the email headers. You want to see dkim=pass and spf=pass in the Authentication-Results header. If either is failing, stop and troubleshoot before you migrate any real traffic. You can also use our free email header analyzer to read those results without decoding raw header text yourself.

Step 4: Shift traffic gradually

If you're doing a phased migration (which is almost always the safer call), route a small percentage of sends through the new ESP first while both are still configured. Watch your deliverability signals during this window. Bounce rate, spam complaint rate, and open rates across the two platforms will tell you if something's off before you've moved everything.

Step 5: Remove the old records only after the old ESP is fully shut down

Still once you've confirmed all traffic is routing through the new ESP and everything is healthy, remove the old DKIM selector and the old ESP's include: tag from your SPF record. Do this in reverse order of importance: SPF last, since a broken SPF record affects every send.

Don't rush this step. Keeping both sets of records active for a few extra weeks costs nothing. Removing them too early while some emails are still queued on the old system will cause those to fail authentication.

What to monitor in real time

During the migration window, check these every day:

• DMARC aggregate reports show you which sources are passing or failing authentication. Use our free DMARC parser if you're reading raw XML reports.
• Bounce rate on the new ESP. A spike in hard bounces early in migration sometimes points to DNS misconfiguration, not list quality.
• Spam complaint rate. If it jumps above 0.1%, something's wrong with either reputation or authentication on the new stream.
• Inbox placement. You can't always see this from your ESP dashboard alone. Send test messages to seed accounts at Gmail and Outlook during the migration and check manually where they land.

Now if things do go sideways and you're not sure what's broken, the SPF checker and DKIM record lookup are a good first stop. And if it's turning into a genuine crisis, our SOS hotline is free. No pitch, just help.