MX Records Explained:How Email Delivery Works for Your Domain

An MX (mail exchanger) record tells other mail servers where to deliver email for your domain. When someone sends a message to [email protected], their mail server looks up the MX records of example.com and delivers the message to the server listed there, trying the record with the lowest priority number first.

If your MX records are wrong, missing or pointing at the old provider, email to your domain bounces, is delayed, or arrives at a mailbox nobody checks.

What an MX record looks like

example.com.  3600  IN  MX  10 mail.example.com.

• example.com.: the domain receiving email (@ in most editors).
• 3600: the TTL in seconds.
• 10: the priority (also called preference). Lower is preferred.
• mail.example.com.: the hostname of the receiving mail server, which must have its own A (or AAAA) record.

Priorities and backup servers

With more than one record:

example.com.  MX  10 mx1.mailprovider.com.
example.com.  MX  20 mx2.mailprovider.com.

Senders try mx1 first and use mx2 if it is unavailable. Records with the same priority share the load. Large email services often give you several entries; enter all of them exactly as listed.

Rules MX records must follow

• They point to hostnames, never directly to IP addresses.
• The target hostname must not be a CNAME.
• Each target must resolve to a working mail server for your domain.
• If there are none at all, some senders fall back to the domain's A record, which is rarely what you want.

How to check your MX records

• Use a DNS lookup tool and query the MX type.
• From a terminal: dig example.com MX or nslookup -type=MX example.com.
• In cPanel, Email Routing and Zone Editor show the domain's MX setup when DNS is hosted on the server.

Common MX problems and fixes

Symptom	Likely cause	Fix
Email bounces with "no MX" or "domain not found"	Records deleted, or domain expired	Recreate them; check domain status
Email still goes to the old provider	MX not updated, or still cached	Update MX; wait for TTL
Some messages arrive, some do not	Old and new providers both listed	Remove the old provider's entries
Email to your own domain stays on the server	Email routing set to "local" while mail is hosted elsewhere	In cPanel, set Email Routing to "Remote Mail Exchanger"
Mail delayed by hours	Primary MX unreachable, falling back slowly	Fix or remove the failing MX target

Email routing in cPanel

If your website is on cPanel hosting but your email is hosted elsewhere (for example a separate business email service), set Email Routing to Remote Mail Exchanger for the domain. Otherwise, messages sent from your own server to your domain (such as contact form notifications) may be delivered locally and never reach your real inbox.

Worked example: email stopped after a website move

A company moved its website to new hosting by changing nameservers. The website works, but no one has received email since. The investigation:

1. Check the records being served: dig example.com MX returns 10 mail.example.com., created automatically by the new host's DNS zone.
2. But email is hosted with a separate business email service. Its required records (for example two MX entries with priorities 1 and 5) existed only in the old DNS zone, which stopped being used when the nameservers changed.
3. Fix: in the new DNS zone, delete the host's default MX record and add the email provider's mail-exchanger entries exactly as documented; recreate its SPF and DKIM records too.
4. In cPanel, set Email Routing to "Remote Mail Exchanger", so the web server does not try to deliver mail locally.
5. Wait for the TTL and test by sending messages from an outside account.

Mail that was sent during the outage was usually retried by sending servers for a while, so much of it may still arrive; some may have bounced.

Reading an MX lookup

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

The TTL (3600) is how long resolvers cache the answer, 10 and 20 are priorities, and the hostnames must themselves resolve to the provider's servers. If the answer is empty, the domain has none; if it lists your old provider, the change has not been made (or is still cached).

Changing email provider safely

1. Create the mailboxes at the new provider first.
2. Lower the MX record TTL a day in advance.
3. Replace the old entries with the new provider's.
4. Update SPF, and add DKIM and DMARC for the new provider; see SPF, DKIM and DMARC explained.
5. Check the old mailboxes for a few days for messages delivered before the change was seen everywhere, and move them across.

MX records only cover receiving

These records decide where email arrives. Whether your outgoing email is trusted depends on SPF, DKIM and DMARC, plus the reputation of the sending server.

Frequently Asked Questions

Can I have email with one company and my website with another?

Yes. Point the A record to your web host and the mail records to your email provider.

How long do MX changes take?

Usually minutes to a few hours, depending on the TTL. Some senders cache longer, so keep the old mailbox for a few days.

Do subdomains need their own MX records?

Only if you want to receive email at addresses on that subdomain, such as [email protected].

Related reading

For the full picture of record types, see DNS record types explained, and for how DNS works, what is DNS. To set up mailboxes, follow how to create a business email account. Email accounts are included with the ServerNeed shared hosting plans.

Sources

• Cloudflare Learning Center: What is a DNS MX record?
• cPanel documentation: Email Routing

Featured image: “eMail” by Esparta, licensed under CC BY 2.0.