Every mail server resolves to the same address
Updated
11% of the 527 domains we could check get a warning for this. Sample: the first 1,000 domains by rank in the Majestic Million, checked on 2026-10-12. How we measured
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 targets›, and between them they resolve to ‹mx addresses›: ‹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.