Every mail server resolves to the same address
What this check looks for
You publish more than one mail server, but they all point at the same machine. If it goes down, the backup goes down with it and inbound mail is delayed or lost.
Why it matters
A backup MX that shares its address with the primary is redundancy on paper only — the outage that takes out one takes out both, and senders have nothing left to try.
When the check passes, your report says: “Mail servers sit on different addresses, so one can fail”.
What it costs your score
When this check fails it removes 8 points from your Email transport score, before the status, confidence and repeat multipliers are applied. Email transport carries a weight of 8 in the overall score.
It shares the email-transport.mx family ceiling of 30 points: however many findings that family produces, together they cannot remove more than that from Email transport. One underlying problem showing up in several places is still one problem.
- Severity
- medium
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 8 points
- Family cap
- email-transport.mx · 30
- Category
- Email transport
- Module
- Email mx
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Put the backup mail server on separate infrastructure, or use a provider that is already multi-homed.
Two names for one machine survive exactly as many failures as one name for one machine.
Confirm whether the second MX is meant to be a real backup or is a leftover from a migration — if it is a leftover, delete it, because a dead backup MX only adds delivery delay.
If it is meant to be a backup, host it on a different network, ideally with a different provider, and configure it to queue and relay to the primary.
If your mail is hosted, check the provider's documentation: most publish several MX names on separate networks and you may have entered only one of them twice.
How to confirm it worked
dig +short MX ‹domain› — then dig +short A on each target and confirm the addresses differ
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹domain› publishes ‹mx count› MX targets which between them resolve to ‹address count› distinct address(es): ‹addresses›. RFC 5321 §5.1 has senders try each MX in preference order, so the value of a second entry is entirely in its being reachable when the first is not. Addresses inside the same /24 (or the same IPv6 /48) are counted as one network here, because a rack, a switch or a route withdrawal usually takes the whole block with it.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other email mx checks
- Two MX hosts share the same preference value
- MX record points at a CNAME
- MX record points at an IP address instead of a hostname
- Mail server address has no reverse DNS name
- MX host does not resolve to an address
- No MX record — this domain cannot receive email
- Domain publishes a null MX (receives no mail)
- Only one mail server host is published