MX records and priority

Module 4: Records for email · Reading time: 8 minutes

Learning objective: After this lesson, you'll be able to read and set up MX records, choose the right priority, and explain what happens when a domain has no MX record.

Key concepts: MX record, priority (preference), backup MX, mail server (hostname), implicit MX, null MX, local delivery

Where should the mail go?

When someone sends an email to info@example.com, the sender's mail server needs to work out which server that mail should be delivered to. It looks this up in the DNS, by asking for the MX record (Mail eXchanger) of example.com.

The answer isn't an IP address, but a list of mail servers, each with a number in front of it:

example.com.   3600  IN  MX  10 mail.example.com.
example.com.   3600  IN  MX  20 backup.example.net.

The sending server then looks up the A or AAAA record of mail.example.com, and only then does it know which IP address to contact. So an MX record always points to a name, which itself has an A or AAAA record.

The MX record is almost always set on the domain name itself (@), because it concerns the part after the @ in the email address. If you want to receive mail at info@nieuws.example.com, then nieuws.example.com needs its own MX record.

Priority: lowest goes first

The number in front of the mail server is called the priority (in the standard, RFC 5321, it's called preference). The rule is simple:

• The lower the number, the sooner that server is tried.
• If that server isn't reachable, the sender tries the next one.
• If two servers have the same number, the sender distributes mail randomly between both. This lets you spread the load.

The number itself doesn't mean anything on its own. 0, 1, 5, 10 or 100: only the order counts. A record with priority 10 and one with 20 works exactly the same as 1 and 2. If your mail provider gives you a number, use it as given. If they give you only one server, the number doesn't matter.

A server with a higher number is often called a backup MX. This used to be common practice: if your own server went down, the backup would hold on to the mail. Nowadays, a sending server keeps mail itself for a few days and tries again. A backup MX that isn't set up properly (for example, without a spam filter) actually attracts spam. So only use one if your provider specifically tells you to.

Rules for a good MX record

1. A name, not an IP address. MX 10 192.0.2.25 is invalid. Create an A record mail with 192.0.2.25 and point the MX to mail.example.com.
2. Not to a CNAME. The name in an MX record must itself have an A or AAAA record, not a CNAME (RFC 2181, section 10.3). Many servers resolve it anyway, but not all.
3. The trailing dot. In many panels you type mail.example.com. with a dot. Without the dot, the panel appends your domain name again: mail.example.com.example.com. That name doesn't exist, and your mail won't arrive.
4. The mail server must exist. If the MX points to a name without an A or AAAA record, nothing will arrive. In practice, this often happens when someone moves their domain's nameservers to a website builder: the MX record moves along, but the A record for mail doesn't.
5. Remove old records. If you switch to a different mail provider, remove the MX records from the old provider. If you leave them in place, some of your mail will still arrive at the old provider.

No MX record: implicit MX and null MX

What happens if a domain has no MX record at all? According to RFC 5321, the sending server then tries the A or AAAA record of the domain name itself. This is called the implicit MX. If your website runs on a server without mail, the world will try to deliver its mail to your web server. This causes delays and error messages for the sender.

If you want to make clear that a domain never receives mail, use a null MX (RFC 7505):

example.net.  3600  IN  MX  0 .

Priority 0 and just a dot as the mail server. A sender then sees immediately that there's no point trying, and sends the sender a clean error message straight away. Combine this with an SPF record v=spf1 -all (lesson 4.3) if the domain also doesn't send mail.

Local delivery: the trap with hosting plus mail

Many hosting packages run a web server and a mail server on one machine. By default, that server thinks: "I'll deliver mail for this domain myself." If you move your mail to a different provider, you update the MX records, but the server doesn't automatically remember that. Result: mail from your own contact form, and from other websites on the same server, stays stuck on the old server and never reaches your new provider. The sender sometimes gets a 550 Unknown user error back.

Hosting companies get this question a lot. That's why most panels have a toggle with a name like "Use this server to handle my emails" or "Local mail delivery". Moving your mail to another party? Change the MX and turn off that toggle. Do only one of the two, and it will go wrong.

In practice: what it looks like in a panel

In this example, we use DirectAdmin. Under E-mail Manager, MX Records, you'll see your domain's MX records. For each record, you type the priority in a box and the mail server after it, with a dot at the end. Below that is a checkbox, Use this server to handle my emails. Under MX Template, you can choose ready-made settings for, for example, Microsoft 365 or Google Workspace.

In My WebOké, you'll find the same thing on the DNS tab of a domain; there the toggle is called Delivery.

In cPanel, Plesk, Cloudflare, or at your registrar, the screen looks different, but you always fill in the same three things: the name (@ or blank), the priority, and the mail server.

Summary

• The MX record tells the world where mail for your domain should go. It points to a name, never to an IP address or a CNAME.
• Lowest priority first; equal numbers share the mail; the number itself has no meaning.
• Without an MX, the world tries your A record (implicit MX). If you never receive mail, use MX 0 . (null MX).
• If you move your mail, remove the old MX records and turn off local delivery on your hosting server.

Quiz

Exercise

Exercise Z4.1: Looking up an MX. Look up the MX records of wikipedia.org (or your own domain). Fill in which mail server has the lowest priority number, and what that number is.

Exercise O4.1: Setting it up yourself in your practice zone. In your practice zone <code>.dnspractice.eu, create two MX records: priority 10 to mail.<code>.dnspractice.eu and priority 20 to backup.<code>.dnspractice.eu. Create an A record for both names: mail to 192.0.2.25 and backup to 192.0.2.26. Then click Check.

Further reading

The steps in these articles apply to WebOké's panels; in other panels, it works in a similar way.

• DirectAdmin guide 5.5: MX records: where does your email arrive?
• Your email elsewhere: Microsoft 365, Google Workspace, or your own mail server
• Sending email via PHP fails, MX records point elsewhere
• DirectAdmin guide 18.9: I'm no longer receiving email
• RFC 5321 section 5.1 (mail routing), RFC 7505 (null MX)