Dr.Who
← blog

No MX record found: why inbound email bounces

· mx · dns · email · deliverability · bounces

mxdnsemaildeliverabilitybounces

"No MX record found" means a sending mail server queried DNS for your domain's mail-exchanger records and got nothing back, so it has no idea which host to deliver mail to. The result is bounced inbound email — senders get a 550 or a delayed-delivery report instead of reaching your inbox. The fix is almost always to publish a valid MX record pointing at a mail host that actually resolves, then wait out the TTL.

What an MX record is

An MX record is a DNS record at your domain's apex (or a subdomain) that names the host responsible for receiving mail, plus a priority. A working set looks like this:

dig +short MX example.com
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
10 alt2.aspmx.l.google.com.

Lower priority numbers win; senders try the lowest first and fall back to higher ones. The hostname on the right (the MX target) must resolve to an A or AAAA record — that is where the SMTP connection actually goes.

Why you see "no MX record found"

A handful of root causes, in rough order of frequency:

  • No MX record is published. The domain has A/TXT records but nothing of type MX. Common on domains set up for a website but never configured for mail.
  • The MX target does not resolve. You published 1 mail.example.com. but mail.example.com has no A/AAAA record, so the connection has nowhere to land.
  • Only an A record exists. Per RFC 5321, a sender may fall back to the domain's A record when no MX exists (the "implicit MX" rule). Many do not — never rely on it, publish an explicit MX.
  • Recent change still propagating. The old (empty) answer is still cached for the length of its TTL.
  • The MX points at a CNAME — illegal. RFC 2181 and RFC 5321 forbid an MX target from being a CNAME. It must name a host with A/AAAA records directly. Some resolvers reject it; others behave unpredictably.

How to fix it

Publish an MX record pointing at your mail provider's hostnames. For Google Workspace that is aspmx.l.google.com (priority 1) plus the alternates; for Microsoft 365 it is <tenant>.mail.protection.outlook.com (priority 0). Then confirm the target resolves:

dig +short A aspmx.l.google.com

If that returns addresses, mail has somewhere to go. After publishing, mail keeps bouncing only until the previous record's TTL expires — set a low TTL before a planned cutover so you are not stuck for hours.

The null MX (deliberate "no mail")

If your domain genuinely never receives mail, do not just leave MX blank — declare it. RFC 7505 defines the null MX: a single record with priority 0 and a target of . (a bare dot).

example.com.  IN  MX  0 .

This tells senders explicitly that the domain accepts no mail, so they bounce immediately instead of timing out or falling back to your A record. It is the correct posture for a parked or send-only domain.

Run the MX check on your domain →

Further reading