How it works
Each MX record consists of a priority and a hostname, for example 10 mx1.example.com and 20 mx2.example.com. The sending server tries the lowest number first and falls back to the next ones if that fails (RFC 5321).
The target must be a hostname with an A or AAAA record, not an IP address and not a CNAME. If there is no MX record at all, senders fall back to the domain’s A record, which usually leads nowhere.
A domain that deliberately receives no mail can say so clearly with a null MX as defined in RFC 7505 (priority 0, target a single dot); it must then be the only MX record.
Why it matters
If the MX record is missing or points to a name that no longer resolves, senders cannot deliver. They usually retry for a few days and then send a bounce, so inquiries and orders get lost, often without the client noticing.
Typical triggers are a DNS migration where the MX records were left behind, a provider switch with stale entries still in place, or a typo in the hostname. A tampered MX record can even route incoming mail to someone else’s server without anyone noticing.
How to prevent it
- Before any DNS or provider change, save the existing MX records and compare them after the move.
- Only use hostnames with A or AAAA records as targets, never an IP address or a CNAME.
- Remove the old provider’s MX records once the new one accepts mail.
- Mark domains that receive no mail with a null MX (0 .).
- Lower the TTL a few days before a planned switch so the change propagates quickly.
How DomainWarn detects it
The MX check queries the MX records directly and resolves every mail server. No MX record is critical and opens the “No MX record” incident after two runs; if not a single mail server resolves, “Mail server unresolvable” follows, and if only some do not, it is a warning. A null MX is a hint, a null MX alongside other MX records a warning. On subdomains a missing MX is only a hint.
Change detection reports a changed MX as a warning and a removed one as critical. Other checks build on the MX records: SMTP tests the mail servers on port 25, reverse DNS their PTR records, and MTA-STS whether every MX host is covered by the policy.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.