Mail exchanger does not resolve

Delivery fails at the sending server, which reports the problem to whoever wrote to you.

Nothing about the failure reaches your infrastructure, because no connection was ever established with it.

So the symptom is people saying they wrote and got no reply, which is indistinguishable from mail going to spam or from nobody reading the mailbox.

It is also intermittent-looking when only a lower-priority exchanger is broken, since that one is only used when the primary is unavailable.

Which means the fault frequently surfaces during an unrelated incident, on top of it.

A mail platform migration where the new exchangers are added and the old ones are not removed.

A secondary exchanger pointing at a host that was decommissioned, which nothing tests because the primary keeps working.

An MX naming a hostname in a domain that later expired or changed nameservers.

A record naming an address directly rather than a hostname, which is invalid and handled inconsistently by receivers.

In each case the record looks plausible, and the only way to know is to resolve each target.

Sending servers try exchangers in priority order, lowest number first, and fall back to the next on failure.

A broken primary with a working secondary delays mail rather than losing it, which is the system working as designed.

A broken secondary is invisible until the primary is unavailable, at which point mail stops entirely.

Identical priorities on all exchangers means the order is effectively arbitrary, which is fine for load spreading and wrong where a real preference exists.

So both the resolution and the ordering are worth confirming, and neither produces an error while it is wrong.

Resolve every published exchanger hostname and confirm each returns an address.

Remove records naming hosts that no longer exist, rather than leaving them at a low priority as a fallback — a fallback that does not resolve is not one.

Confirm each remaining exchanger is a hostname rather than an address, since an MX naming an address is invalid.

Keep at least two exchangers so a single host outage delays rather than rejects.

Re-check after any DNS or platform change, since this is a failure mode that arrives with a migration and stays.

`dig +short MX example.com` lists the exchangers with their priorities.

For each hostname returned, `dig +short A <hostname>` — an empty answer is the defect.

Check every exchanger, not only the primary. The secondary is the one that fails quietly.

Confirm each target is a hostname, not an address. An address in an MX record is invalid regardless of whether it works.

Send yourself a message from an external mailbox, which exercises the primary and tells you nothing about the rest.

`email.mx_targets` confirms every published exchanger resolves to a real address, which is this problem directly.

`email.mx.resolution` verifies each is a well-formed hostname that resolves, so an invalid record shape is distinguished from an unresolvable one.

`email.mx.present` reports whether any exchangers exist, and `email.mx.redundancy` whether at least two accept mail.

`email.mx.ptr` reports the reverse DNS name of each exchanger address, which is a separate requirement many receivers apply.

`email.usage_context` establishes whether the domain looks like one that handles mail, which decides whether any of this applies.

A domain that receives no mail can publish an explicit null exchanger, which tells sending servers to stop rather than to keep trying.

That produces an immediate, clear rejection instead of a series of retries ending in a timeout hours later.

It is the correct configuration for a domain used only for a website, and it is different from having no MX at all.

With no MX record, sending servers fall back to the address record for the domain and attempt delivery to the web server, which is rarely what anyone wants.

So the three states are distinct: exchangers that work, an explicit refusal, and no record — and only the last is accidental.