Module 4 · 4.3

English

Nederlands English Deutsch Français Español

The DNS switch: MX, SPF, DKIM and DMARC

Module 4: Moving email · Reading time: 12 minutes

Learning objective: After this lesson, you'll be able to plan and carry out the DNS switch for email in the right order, so that no mail is lost, your outgoing mail doesn't end up in spam, and Outlook doesn't secretly keep contacting the old provider.

Key concepts: TTL, MX switch, SPF (one record), DKIM selector, DMARC (p=none, rua), autodiscover, autoconfig, verification record, accepted domain

Five records, one moment

For email on your own domain, there are a few records in the DNS that together determine whether mail arrives and whether your mail is trusted:

Record	Where	What it does
MX	`example.com`	where incoming mail is delivered
SPF (TXT)	`example.com`	which servers may send on behalf of your domain
DKIM (TXT or CNAME)	`<selector>._domainkey.example.com`	the key recipients use to check your digital signature
DMARC (TXT)	`_dmarc.example.com`	what recipients do if SPF and DKIM don't match, and where reports go
autodiscover / autoconfig	`autodiscover.example.com`, `autoconfig.example.com`	where mail programs find their settings

When you switch providers, almost all of this changes. The trick is the order. If you switch the MX while SPF and DKIM still only cover Microsoft, your mail will arrive, but the mail you send will land in spam. If you switch SPF first, Microsoft can no longer send mail on your behalf properly in the days before the switch.

This lesson is about that order. You can read exactly how each record works in the DNS course (lessons 4.1 to 4.5).

Step 1, two days ahead: lower the TTL and make a backup

Every DNS record has a TTL (time to live): how long other servers are allowed to remember the answer. If the TTL of your MX is 86400 seconds (one day), some servers may keep sending mail to the old server for up to a day after the switch.

So, at least one old TTL in advance, lower the TTL of MX, SPF and autodiscover to 300 or 3600 seconds. With a TTL of one day, do this at least a day beforehand; two days gives you plenty of margin. At the same time, make a backup of your DNS zone, or write down all the current records. That way you can always go back.

Bakkerij De Korrel sees:

example.com.            3600  IN  MX   0 example-com.mail.protection.outlook.com.
example.com.            3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey    3600  IN  CNAME selector1-example-com._domainkey.korrel.onmicrosoft.com.
selector2._domainkey    3600  IN  CNAME selector2-example-com._domainkey.korrel.onmicrosoft.com.
_dmarc.example.com.     3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
autodiscover            3600  IN  CNAME autodiscover.outlook.com.
example.com.            3600  IN  TXT  "MS=ms12345678"

The TTL is already 3600 (one hour). They set MX and SPF to 300.

Step 2, before the switch: get DKIM and SPF ready for the new provider

Records that won't break anything can be set up in advance:

DKIM from the new provider. The new provider gives you a selector and a key, for example x._domainkey with a TXT record v=DKIM1; k=rsa; p=.... Because the selector has a different name from Microsoft's (selector1 and selector2), they can sit side by side without any issue. Each recipient only looks at the selector named in the mail's signature.
Extend SPF, don't replace it. There may only be one SPF record. Add the new provider to the same record, so that both providers are allowed to send during the transition days:

"v=spf1 include:spf.protection.outlook.com include:spf.mailaanbieder.example ~all"

The bakery had -all. During the transition, they temporarily choose ~all (softfail): if a server is missing after all, the mail is treated as suspicious rather than rejected. That follows the rule of thumb: ~all if you're not completely sure, -all if you're certain all senders are included.

Don't forget the other senders from your list in lesson 4.1: the web shop, the newsletter service, the accounting software. They stay in the SPF record.

Step 3, the switch moment: MX and autodiscover

At the agreed moment, once the first copy of the mailboxes is ready (lesson 4.2):

Replace the MX records with those of the new provider. Remove the old MX; don't leave it in as a "backup" with a higher priority, because then mail will arrive at the old provider as soon as the new one is briefly slow.
Update autodiscover. Outlook looks for its settings via autodiscover.example.com. If that still points to autodiscover.outlook.com, Outlook will keep trying to log in at Microsoft, even if you add a new account. Remove it or point it to whatever your new provider specifies. Some providers use autoconfig.example.com instead (Thunderbird) or SRV records such as _imaps._tcp and _submission._tcp (RFC 6186).
Run a second copy of the mailboxes, so the mail from the last few hours comes across too.

There's a surprise with Microsoft 365 that catches many people off guard. As long as example.com is listed in the Microsoft 365 environment as an accepted domain, Microsoft delivers mail between users within that same environment internally, without looking at the MX. If a colleague who still works in Outlook at Microsoft emails another colleague, that mail ends up in the old mailbox. So switch all staff over on the same day, and remove the domain from the Microsoft environment after the transition period.

Step 4, DMARC: monitor during the transition

DMARC tells recipients what to do if a mail fails SPF or DKIM, and it sends you reports. The bakery had p=quarantine. That's good, but risky during a switch: if DKIM isn't yet active at the new provider, their own mail will end up in customers' spam folders.

The safe approach:

If you don't have DMARC yet, start with p=none and an rua address. Then nothing happens to your mail, but you do get reports.
If you already have quarantine or reject, check before the switch with a test email that DKIM from the new provider works (the header of a received email shows dkim=pass with d=example.com). If you're unsure, temporarily switch to p=none and monitor the reports for a few weeks.
After that, tighten it step by step: none, then quarantine, then possibly reject. Under the new DMARC standard (RFC 9989) you can also use t=y during the testing phase; the old pct tag is being phased out.

Step 5, after a few weeks: clean up

If everything has been working well for a few weeks, clean up the old records:

the old include in SPF (and possibly back to -all);
the old DKIM records (selector1 and selector2);
the verification record MS=ms... and any other Microsoft records, such as enterpriseregistration and lyncdiscover if you had those;
the TTL back to a normal value, such as 3600;
the domain out of the old Microsoft or Google environment.

If you leave the old include in place, the old provider can keep sending mail on behalf of your domain for years to come. That's an open door.

In practice: what it looks like with a provider

In My WebOké, the DNS tab shows the Email settings card. It displays MX, SPF and DMARC with a coloured dot, and in the top right which mail provider it recognises from your MX. With Quick setup you set the records for a provider in one go, and a yellow notice warns that existing MX and SPF records will be replaced. So make a DNS backup first and then check that the SPF record still contains your other senders. The product page of a hosting package shows the Set E-mail card, which shows per record whether it is Correct, Attention, Incorrect or Not found, and gives the value with a copy button. If your DNS is hosted with another provider, copy those values over there. Other providers and DNS panels have similar overviews; the records themselves are the same everywhere.

Summary

Lower the TTL at least one old TTL in advance and make a backup of your DNS zone.
Set up DKIM from the new provider and an extended SPF record (one record, both providers) before the switch.
Switch MX and autodiscover at the same time, and move all staff over on the same day; otherwise Microsoft will still deliver internal mail to the old mailboxes.
During the transition, don't set DMARC stricter than what you're certain of; if you have no DMARC yet, start with p=none and reports.
After a few weeks, clean up the old include, DKIM records, verification records and the domain in the old environment.

Quiz

Exercise

Exercise A4.3: Your mail records at a glance. Enter your domain, and the DKIM selector of your (new) provider. The program checks whether the MX points to your provider, whether there's exactly one SPF record, whether the DKIM key is present at that selector, and whether there's exactly one DMARC record. It also measures the TTL of your MX at the authoritative nameserver: for a planned switch this should be 3600 or lower.

Exercise E4.3: Your switchover script. Write out the script from this lesson for your own domain: for each step, the date and time, the records before and after (old and new SPF as one line), who does it, and what you check after each step.

Exercise E4.3: Your switchover script

Create a script you can work through on the day itself.

For each step (TTL down; DNS backup; prepare DKIM; extend SPF; first copy; switch MX and autodiscover; second copy; test mails; devices; tidy up after a few weeks): date and time, records before and after, who, how you check it.

Check: does your script have a moment anywhere with two SPF records? Does the TTL reduction happen at least one old TTL before the switch? Do all staff members switch over on the same day?

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing