If a domain has no MX record, will email still get delivered?

Sometimes — and that 'sometimes' is the whole problem. RFC 5321 §5.1 says a sender that finds no MX record SHOULD fall back to the domain's A/AAAA record and try to deliver there, treating the domain itself as an implicit mail exchanger at preference 0. The operative word is SHOULD, not MUST. Plenty of modern sending platforms skip the fallback entirely and bounce the message the moment they see no MX. So a domain with no MX but a working A record might receive mail from one sender and reject it from the next, with no pattern the recipient can see. Publish an explicit MX and the guesswork disappears.

What is a null MX and why is my mail bouncing because of it?

A null MX is a single MX record with preference 0 and a target of '.' (just a dot) — written as 'example.com. MX 0 .'. RFC 7505 defines it as a domain's way of saying, explicitly and permanently, 'this domain accepts no mail.' A sender that sees a null MX does not fall back to the A record; it stops and returns a permanent failure right away. It's the correct setting for a domain you only use for a website and never for email. But if you actually want to receive mail and a null MX is still published — left over from a host's default zone, or copied from a template — every message bounces immediately. Replace it with a real MX pointing at your mail server.

My MX record exists but mail still bounces. What now?

An MX record is only useful if its target resolves to an address. The single most common broken configuration is an MX that points to a hostname with no A/AAAA record, or — worse and surprisingly common — an MX pointing at a CNAME. RFC 2181 §10.3 forbids that: the MX target must be a hostname with address records, not an alias. Some sending servers tolerate a CNAME there, many don't, so you get the same intermittent delivery as having no MX at all. Check that your MX target is a real hostname that returns an A or AAAA record directly.

Views: 7

No MX Record: Email Not Delivering

No MX record means inbound mail has nowhere to land. Check MX presence, priority, the A-record fallback, and null MX in 5 steps. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Mail sent to your domain bounces with “no MX record” / “recipient domain has no mail server” / “DNS error: no mail exchanger,” or it silently never arrives. The website on the same domain works fine, which is exactly why this is confusing — DNS is up, the domain resolves, but the part of DNS that tells the world where to deliver mail is missing, wrong, or pointed at nothing.

Symptoms

Bounce messages say 550 5.1.2, “Domain not found,” “no MX record,” or “Recipient address rejected: undeliverable address.”
Some senders reach you, others don’t, with no obvious pattern.
dig MX example.com returns an empty answer section.
Mail worked yesterday, then a DNS migration or registrar change went live.
You can browse the website (A record fine) but no inbound mail lands.

What an MX Record Actually Does

An MX (Mail eXchanger) record is the one piece of DNS that answers a sending mail server’s only real question: where do I hand off mail for this domain? It has two parts — a preference number and a hostname. The preference is a priority, and lower wins: MX 10 mail1.example.com is tried before MX 20 mail2.example.com, so the smaller number is the primary and the larger ones are backups. The hostname must, in turn, resolve to an A or AAAA record so the sender knows which IP to actually connect to.

Here’s the part that trips people up. If a domain publishes no MX at all, the standard doesn’t say “give up.” RFC 5321 §5.1 says the sender SHOULD fall back to the domain’s A/AAAA record and treat it as an implicit MX at preference 0 — deliver to the web server’s IP and hope something’s listening on port 25. That fallback is why some no-MX domains still receive mail. But it’s a SHOULD, not a MUST, and a large share of modern senders have stopped implementing it. So “no MX” doesn’t fail cleanly. It fails probabilistically, depending entirely on which server is sending — and intermittent mail loss is far harder to diagnose than a clean, total bounce.

Top 3 Causes

No MX record published at all. The zone has A/AAAA records for the website but nobody ever added an MX, or a migration dropped it. Senders that honor the A-record fallback get through; senders that don’t, bounce. The tell: delivery that works from some sources and fails from others, and dig MX example.com comes back empty.
MX target doesn’t resolve, or points at a CNAME. The MX record exists but its hostname has no A/AAAA record (typo, decommissioned host, missing glue), or it points to a CNAME alias — which RFC 2181 §10.3 forbids. The sender finds the MX, tries to resolve the exchange host, gets nothing usable, and gives up. The tell: dig MX shows a record, but dig A <that-hostname> is empty or returns a CNAME.
A null MX is still published, or the MX is on the wrong name. A leftover MX 0 . (RFC 7505) tells every sender “this domain takes no mail” and forces an immediate permanent bounce — common on domains a host parked or templated for you. Or the MX is published on mail.example.com when mail is addressed to @example.com; the record exists, just not at the name people actually send to.

Diagnose with DechoNet

Email Check looks up your domain’s MX records the way a sending server would, shows the preference values and target hostnames, and flags a missing MX, a null MX, or an authentication gap in one pass — so you can see immediately whether the problem is “no mail server listed” versus “listed but misconfigured.”
DNS Check lets you resolve the MX target hostname on its own. If Email Check shows an MX but mail still bounces, query the exchange host’s A/AAAA record here: an empty answer or a CNAME at that name is the smoking gun.

Resolution Checklist

Confirm the record actually exists: dig MX example.com +short. An empty result means no MX is published — that’s your answer.
If you see 0 . in the output, that’s a null MX (RFC 7505). If the domain should receive mail, delete it and publish a real MX.
Check the MX target resolves: take the hostname from the MX record and run dig A mail.example.com +short. It must return an IP directly, not a CNAME and not nothing.
Verify the MX is on the apex/zone the address uses (example.com), not on a subdomain nobody mails — the name on the left of the MX record must match the part after the @.
Sanity-check the preference numbers: lower is preferred. If a backup MX has a lower number than your primary, mail goes to the wrong server first.
After any change, allow for the MX record’s TTL to expire before retesting — old answers stay cached until then.

When to Escalate

If dig MX returns the correct record and the target resolves to the right IP but mail still bounces, the problem has moved past DNS to the mail server itself: nothing is listening on port 25, or it’s rejecting connections. Hand it to whoever runs the mail server.
If you don’t control the DNS zone (managed host, registrar default zone), and a wrong or null MX is baked into their template, you’ll need the provider to change it — a client can’t override an authoritative record it doesn’t administer.