Skip to content
correct.email
correct.email
Mail infrastructure

How to troubleshoot MX records

How MX records route incoming mail, how to look them up, and how to fix the common problems: missing records, CNAME or IP targets, dead hosts and migrations.

By Exmoor Software4 min read

MX (mail exchanger) records tell the rest of the Internet which servers accept email for your domain. When they are wrong, mail to you bounces or disappears — usually without any error on your side, because it’s the senders who can’t deliver.

How MX records work

example.com.  3600  IN  MX  10  mx1.mail.example.net.
example.com.  3600  IN  MX  20  mx2.mail.example.net.

Each record has a preference (priority) and a host name. A sending server looks up the MX records of the recipient’s domain, tries the host with the lowest number first, and falls back to higher numbers if it can’t connect. Records with equal numbers share the load.

The host name must itself resolve to an address (A or AAAA record). If there are no MX records at all, senders fall back to the domain’s own A/AAAA address — the “implicit MX” of RFC 5321, section 5.1.

Looking them up

The quickest way is the MX lookup tool, which also resolves each host and flags problems. From a terminal:

dig +short MX example.com
dig +short A mx1.mail.example.net

On Windows:

Resolve-DnsName example.com -Type MX
nslookup -type=mx example.com

Query a public resolver (dig @1.1.1.1 …) as well as your local one: if they disagree, you are looking at caching or a recent change.

Common problems and fixes

No MX records

The domain then relies on implicit MX, which only works if the web server behind the domain’s A record also runs a mail server — it almost never does. Add the MX records your mail provider documents.

If the domain intentionally receives no mail, say so with a null MX (RFC 7505):

parked.example.  IN  MX  0  .

Senders then get an immediate error instead of retrying for days. Don’t send mail from such a domain: bounces and replies to it can’t be delivered, and receivers may reject it (RFC 7505, section 4.2). More in Null MX: declaring that a domain accepts no email.

The MX points to a CNAME

example.com.       IN  MX     10  mail.example.com.
mail.example.com.  IN  CNAME  mx.provider.example.

An MX target must not be an alias (RFC 2181, section 10.3). Many senders cope, some don’t. Point the MX directly at the provider’s host.

The MX points to an IP address

MX 10 192.0.2.25 is not valid: the field takes a host name, so senders try to resolve a host literally called “192.0.2.25” and fail. Create an A record (mail.example.com → 192.0.2.25) and point the MX at that name.

The host doesn’t resolve or resolves to a private address

A typo in the host name, a decommissioned server, or an internal address like 10.0.0.5 that works inside your office but not from the Internet. The MX lookup tool shows each host’s addresses and marks private or reserved ones.

Relative names in zone files

In a BIND-style zone file, a name without a trailing dot is relative to the zone:

; in the zone for example.com
@  IN  MX  10  mx1.mail.example.net     ; becomes mx1.mail.example.net.example.com.
@  IN  MX  10  mx1.mail.example.net.    ; correct

Web-based DNS panels usually handle this for you; zone files and some APIs don’t.

Old and new providers mixed after a migration

MX records pointing to both your old and new provider split incoming mail between them. Some messages land in mailboxes nobody reads any more. The MX lookup tool warns when hosts belong to different providers.

Migrating to a new mail provider

  1. Lower the TTL of the MX records (for example to 300 seconds) well in advance — at least as long as the current TTL, often a day — so that cached copies expire quickly after the switch.
  2. Create the mailboxes at the new provider and verify the domain there.
  3. Replace the MX records with the new provider’s — don’t add them next to the old ones.
  4. Keep the old mailboxes for a few days: senders with cached records may still deliver there.
  5. Update SPF and DKIM for the new provider if it also sends your mail.
  6. Raise the TTL again once everything works.

When MX is fine but mail still doesn’t arrive

If every host resolves correctly, the problem lies further along:

  • The server doesn’t accept connections on port 25 — check that it’s running and that a firewall or hosting provider isn’t blocking inbound SMTP. Many residential and cloud networks block outbound port 25, which affects testing from a laptop.
  • TLS problems — an expired certificate can make senders that require TLS defer mail.
  • The message is rejected or filtered — the sender gets a bounce with a reason; ask them for it.
  • The address doesn’t exist — valid syntax and a working MX say nothing about a particular mailbox.

A quick manual test of the SMTP service, from a machine allowed to use port 25:

openssl s_client -starttls smtp -connect mx1.mail.example.net:25 -crlf

You should see the server’s certificate chain and the TLS session details, ending with Verify return code: 0 (ok) if the chain is trusted. openssl handles the 220 greeting, EHLO and STARTTLS itself, so they aren’t printed.

References