MX Records Explained: Priority, Backup Servers and Mistakes
MX records decide where your domain's email is delivered. Learn how priorities work, why they must be hostnames, and the errors that make mail bounce.
When someone sends an email to [email protected], their server needs to know which server accepts mail for example.com. It finds out by asking DNS for the domain's MX records. MX stands for mail exchanger. These records are small, but a mistake in one can stop all your incoming mail, so it is worth understanding them properly.
What an MX record contains
Each record has two parts: a preference number and a hostname.
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 mail2.example.com.The number is the priority, and lower numbers are preferred. A sending server tries the lowest number first, and only moves to a higher number if the first is unreachable. If two records share the same number, senders pick between them, which spreads load.
The hostname must be a hostname
The target of an MX record must be a domain name that resolves to an address with an A or AAAA record. Two rules to remember:
- It must not be a bare IP address. Writing an IP in the MX field is invalid.
- It must not be a CNAME. Pointing an MX at a name that is itself a CNAME is not allowed by the standards, and while some servers cope, others reject it.
MX records and the root of the domain
MX records are usually published at the domain root, but they can exist on subdomains too, such as support.example.com, if you want to receive mail at [email protected]. A name that has a CNAME cannot hold other records, so you cannot publish MX records on a name that is also a CNAME.
What happens when no MX exists
If a domain has no MX record, sending servers fall back to the domain's A or AAAA record and try to deliver there. That fallback is easy to forget, and it can send mail to your web server by accident. If you do not want a domain to receive mail, there is a convention for a "null MX" record that explicitly says so, which saves senders from retrying.
Using more than one MX
Backup servers
Adding a second, higher-numbered MX used to be a common way to keep accepting mail if the main server was down. Be careful. A backup that does not know which addresses exist may accept everything and then bounce messages later, and spammers deliberately target backup servers because they are often less strictly filtered. Only add a secondary MX if it is run by a provider who is configured to the same standards as your primary.
Hosted providers with several servers
Some providers give you several MX records on purpose, with the same or different priorities. Copy them exactly as supplied.
Changing MX records safely
- Create the mailboxes on the new system first.
- Lower the TTL of the existing MX records a day or two before the change.
- Copy old mail across with an IMAP migration tool.
- Replace the MX records, and remove the old ones. Leaving records that point to the old provider means some mail still goes there.
- Test by sending from several outside accounts, and keep checking the old mailboxes for a few days.
During the changeover, a few senders may still use cached answers, so mail can arrive at either system for a short time. That is why a low TTL beforehand helps.
Common MX problems
| Symptom | Likely cause |
|---|---|
| Bounces saying the domain cannot be found | No A or MX records, or a typo in the domain |
| Mail goes to the old provider | An old MX record is still present, or cached |
| Some mail arrives, some does not | Mixed MX records pointing to different systems |
| Delivery errors mentioning the MX host | MX target has no address record or is a CNAME |
| Mail lands on the website server | No MX, falling back to the A record |
How to check your records
You can look up MX records with a command line tool such as dig example.com MX or nslookup -type=MX example.com, or with any online DNS lookup. Check from more than one location if you have just changed them, and compare against the values your provider gave you.
MX records and your hosting
If you manage DNS elsewhere, for example behind Cloudflare, remember that mail records must not be proxied. Only web records can pass through a proxy, and the mail hostname needs to resolve to your mail server's real address.
TTL and caching
Each DNS record carries a time-to-live value that tells resolvers how long they may cache the answer. A long TTL on MX records means a change can take hours to reach every sender. Keep the TTL moderate in normal use, and lower it before planned moves. Remember that the cache is held by other people's servers, which you cannot clear, so plan changes for a quiet period.
MX setup with Zebra Hosting
When you take a Zebra Hosting email plan, the records you need are straightforward, and the team can move your existing mail across for free. Support in 17 languages is on hand if a record does not behave as expected. See the email plans or the free migration page.
