Email Records After Changing Providers

Four records and what each does

Mail depends on a small set of DNS records, and a provider change affects all of them.

The mail records say where to deliver incoming messages.

The sending record says which servers are allowed to send as your domain.

The signing records let a receiving server verify a message really came from you.

And the policy record tells receivers what to do when something fails those checks.

The order that avoids losing mail

• Set up the new provider fully first.
• Add the signing keys before switching.
• Update the sending record.
• Lower the time to live.
• Change the mail records last.
• Keep the old mailbox running.

The fifth is the actual cutover and everything before it is preparation. Changing the mail records first, then configuring the new provider, is the sequence that loses messages.

The two-sending-record failure

Which is the specific mistake that catches almost everybody.

A domain is permitted exactly one sending record, and having two is not treated as two lists combined.

It is treated as an error, and the effect is that the check fails for everything you send.

The new provider gives you a line to add, and adding it alongside the existing one produces exactly this.

The correct action is editing the single record to describe the new provider, not adding a second line.

Where you genuinely send from two services, both go inside the one record rather than in two records.

This is the single most common cause of mail suddenly failing after a migration.

A worked example

A business moved mail providers over a weekend.

They changed the delivery records on the Saturday and added the new sending line on the Monday, leaving the old one in place.

From Monday, quotes and invoices began landing in spam folders and several were never seen.

The cause was two sending records, which took a supplier ten minutes to identify and one edit to fix.

Deliverability recovered over the following week rather than immediately, since receiving systems remember.

Doing it in the right order would have avoided the whole episode.

Add the signing keys first

Since they take effect only once mail flows through the new provider.

The new provider generates keys and gives you records to add, and those can be added days before the cutover with no effect at all.

Adding them afterwards means a window where mail is flowing unsigned, which receiving systems notice.

So add them early, confirm the provider reports them as verified, and only then move the delivery.

That single ordering decision removes most of the deliverability dip people experience after a move.

Watch the policy record

Which can turn a small misconfiguration into total failure.

The policy record tells receiving servers what to do with mail that fails the checks: nothing, quarantine, or reject.

A domain set to reject, with a sending record that is now wrong, has all of its mail refused rather than filtered.

So if you have that set strictly, relax it to the monitoring setting before the migration and restore it a fortnight afterwards.

Where you do not have one at all, a migration is not the moment to add one.

Do that separately once the mail is stable.

Keep the old mailbox for a month

Since delivery does not switch cleanly for everybody.

Senders whose systems cached the old delivery records will keep delivering to the old provider for hours or days.

Leaving the old mailbox running and checking it daily catches those.

A month is a reasonable period, after which anything still arriving there is a sender with a badly behaved system.

Also check whether anything automated sends to an address there: a form, an accounting system, a supplier portal.

Those are the ones that quietly stop and nobody notices for a quarter.

Test before you trust it

Which takes ten minutes and settles everything.

Send a message from the new provider to an address at each of the two or three large mail providers your customers use.

Check whether it arrives, and whether it lands in the inbox or elsewhere.

Free tools will also analyse a message you send them and report on all four records at once, which is faster than checking each.

Do that on the day of the change and again a week later, since deliverability moves over days rather than instantly.

Note both results, so a later problem can be dated against a known good point.

Tell people the addresses have not changed

Since the human side matters as much as the records.

A provider change usually keeps the addresses identical, and nobody outside the business needs to know it happened.

What does help is warning your own people that a message may bounce or arrive twice during the cutover, so an odd delivery is expected rather than alarming.

Where a message genuinely bounces during the change, ask the sender to resend rather than assuming it will arrive later.

And check with anybody who sends you automated mail, since a bounce from an automated system frequently means it stops trying and nobody is told.

The counter-case

Providers increasingly handle this.

Several will configure the records for you if they manage your DNS, which removes most of the opportunity for error.

Deliverability also recovers on its own for most businesses, so a bad week is a bad week rather than a permanent state.

And a business sending twenty messages a day has considerably less at stake than one sending a thousand.

The records still need to be right, and the consequences of a bad week are smaller.

Set up the new provider first, add the signing keys early, edit rather than duplicate the sending record, and change delivery last.

The sequence

1. Configure the new provider fully.
2. Add the signing records early.
3. Relax a strict policy record.
4. Edit the single sending record.
5. Lower the time to live.
6. Change delivery last.
7. Keep the old mailbox a month.

Step four is where the damage happens, since adding a second sending record rather than editing the existing one causes every message you send to fail the check.

What the records actually are is covered in SPF, DKIM and DMARC without the acronyms.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.