MX records explained: what they are and how to set them

An MX (mail exchanger) record is a DNS record that names the server that accepts email for a domain. When someone writes to ana@example.com, their mail server looks up the MX records of example.com and delivers the message to the host listed there. Without one, mail to your domain has nowhere reliable to go.

example.com.  3600  IN  MX  10 mx1.provider.example.
example.com.  3600  IN  MX  20 mx2.provider.example.

Each line has the name the record belongs to (example.com.), a TTL in seconds (3600), the class and type (IN MX), a preference number (10) and the host that receives mail (mx1.provider.example.). The trailing dot means the name is complete; dashboards usually add it for you.

MX records only control incoming mail. Sending is a separate matter, handled by SPF, DKIM and DMARC. You can receive at one provider and send from another, as long as each is set up correctly.

The number in front of the host is its preference, often called priority. Lower means preferred. A sending server sorts the records, tries the lowest number first and moves to the next only if the first does not answer. Records with the same number share the load: RFC 5321 §5.1 tells senders to pick among them at random.

The numbers themselves mean nothing; only their order does. 10 and 20 behave exactly like 1 and 2. Use the values your provider gives you so their support can read your setup.

Every MX record must belong to the same provider. A backup MX at another company accepts mail your main provider never sees.

1. 1Open the DNS settings where your domain’s nameservers point (your registrar, Cloudflare, or your web host).
2. 2Delete the MX records of your old provider. Leaving them at a higher number still sends some mail there when the new host is slow to answer.
3. 3Add the new records: type MX, host @ (the domain itself), the priority, and the mail server host name your provider gives you.
4. 4Keep the TTL low (300 seconds) during the change and raise it to 3,600 or more once mail flows.
5. 5Send a test from an outside account (a personal Gmail, for example) and confirm it arrives at the new host.

Moving a whole team between providers needs more than the MX switch: mail has to be copied and the change timed so nothing lands in the old mailbox unseen. The full sequence is in how to migrate from Google Workspace, and it works the same for any provider.

From a terminal on macOS or Linux:

dig MX example.com +short
# 10 mx1.provider.example.
# 20 mx2.provider.example.

On Windows:

nslookup -type=MX example.com

To skip caches and see what your DNS host actually publishes, ask its nameserver directly: find it with dig NS example.com +short, then run dig MX example.com @ns1.your-dns-host.example. If the authoritative answer is right but a public resolver still shows the old records, you are waiting for the old TTL to run out.

The TTL is how many seconds resolvers may keep a record in their cache. When you change an MX record, resolvers that cached the old one keep using it until their copy expires. So the time a change takes is set by the TTL the old record had, not the new one.

• Before a planned switch, lower the TTL to 300 seconds at least one full old TTL ahead (a day ahead covers most cases).
• During the switch, changes reach most senders within five minutes.
• After, raise the TTL back to an hour or more. Some senders keep a stale route for longer, so keep the old mailboxes open for a few days.

“Propagation” is the name people give to this cache expiry. Nothing is pushed around the internet; each resolver simply asks again when its copy is old.

Null MX: saying “this domain takes no mail”

Domains that should never receive email, such as a marketing domain or a parked name, can publish a null MX (RFC 7505). Senders then fail fast instead of trying the web server. Pair it with v=spf1 -all and a DMARC p=reject so nobody can send as that domain either.

parked.example.   3600  IN  MX   0 .
parked.example.   3600  IN  TXT  "v=spf1 -all"
_dmarc.parked.example.  3600  IN  TXT  "v=DMARC1; p=reject"

Each name has its own MX records. Mail to team@support.example.com looks up the MX of support.example.com, not of example.com. That lets you receive replies to a newsletter or a help desk at another service without touching your main mail.

With Skein, the MX records point at its EU mail servers and are among the records it writes for you on supported DNS providers. To see what else a domain needs, read SPF, DKIM and DMARC explained.