What Is an MX Record? The DNS Switch Behind Cutover

The MX record is the single DNS entry that decides where mail for your domain ends up. During a migration, you can copy every byte of every mailbox to the new tenant, but until you change the MX record, new mail keeps landing on the old server. This page explains what an MX record is, how priorities and TTLs work in practice, and the specific mistakes that turn a clean cutover into a 3am incident call.

What an MX record is#

MX stands for Mail Exchanger. It is a type of DNS record that, when queried for a domain, returns a list of hostnames that are willing to receive mail for that domain. The sending mail server then opens an SMTP connection to one of those hostnames and delivers the message.

A typical MX record set looks like this:

• example.com. 3600 IN MX 10 mail1.provider.net.
• example.com. 3600 IN MX 20 mail2.provider.net.

The 3600 is the TTL in seconds. The 10 and 20 are priorities. The trailing dot on the hostname marks it as fully qualified.

How priorities work#

Senders sort MX records by priority, lowest first, and try them in that order. If the priority-10 host responds, mail goes there. If it times out or refuses, the sender falls back to priority 20, then 30, and so on.

Equal priorities are load-balanced. If you have two records at priority 10, the sender picks randomly, which gives you a basic form of redundancy across two relay hosts at the same provider.

You almost never use priorities to split mail across providers. Mail will land at whichever host responds first, and the result is a mailbox that is half on one tenant and half on another. Use a single provider's MX list, in the order they document, and let them handle failover internally.

TTL planning before a cutover#

The TTL is how long resolvers across the internet are allowed to cache the current MX record. If your TTL is 86400 (24 hours), then up to 24 hours after you change the record, some senders will still be delivering to the old host.

The standard playbook is:

1. A week before cutover, drop the TTL on the existing MX record to 300 seconds.
2. Wait for the old TTL to expire so resolvers learn the new short TTL.
3. On cutover day, change the MX value. New lookups now expire within 5 minutes.
4. After cutover stabilises, raise the TTL back to 3600 or 86400.

What "flipping MX" actually means#

When people say they're flipping MX, they mean editing the MX record at the authoritative DNS host to point at the new provider's mail hostnames. That single change is the moment mail starts arriving at the new mailbox. Everything else in a migration — IMAP sync, SPF, DKIM, Autodiscover — is preparation for that one DNS edit.

For the full sequence from waitlist sign-up through to post-cutover validation, see the complete email migration guide. For dual-MX failover designs and the cases where they actually make sense, Autodiscover and the provider's own redundancy documentation are usually the better reference.

Common MX mistakes#

These are the issues that show up most often during cutovers.

• Forgetting the trailing dot. mail1.provider.net without a dot becomes mail1.provider.net.example.com., which does not exist. Mail bounces with Host not found.
• Leaving the old MX in place. Some panels add the new record alongside the old one. Now you have two providers receiving mail at random.
• Mixing CNAMEs and MX targets. RFC 2181 forbids an MX target from being a CNAME. Some resolvers tolerate it, some don't.
• High TTL on cutover day. A 24-hour cache means a 24-hour tail of stragglers landing in the old mailbox.
• Missing SPF and DKIM at the destination. The MX change works, mail arrives, then receivers reject your outbound because SPF and DKIM and DMARC are not aligned with the new sending IPs.

Verifying the change#

Three quick checks will catch most of the failure modes above.

1. dig MX example.com @8.8.8.8 to see what a public resolver returns now.
2. Send a test message from an external Gmail or Outlook account and confirm it arrives in the new mailbox, not the old one.
3. Check the sending side. Reply to that test message and view the original. SPF and DKIM should both show pass against the new provider.

If anything looks off, the playbook in fix MX record propagation covers the next steps.