Two MX hosts share the same preference value
Updated
What this check looks for
Two of your mail servers are given the same priority, so senders spread mail across both. That is the standard way to share the load between equivalent servers, and it is noted here so you can confirm both really are equivalent.
Why it matters
Equal preference is what the mail standard prescribes for load sharing, and most hosted providers publish their servers that way. It only goes wrong when one of the two is a backup that is not configured to handle live mail — then roughly half of your inbound messages take the wrong path.
When the check passes, your report says: “Each mail server has its own preference value”.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the 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
- info
- Default confidence
- confirmed
- Status when triggered
- info
- Deduction
- 0 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
Confirm the hosts at the same preference are equivalent; give a backup a higher number.
Equal preference means the load is shared, which is right for two live servers and wrong for a backup that is not ready for live mail.
Decide whether the hosts are genuinely equivalent — a hosted provider's documented pair is.
If one is a backup, raise its preference number — larger numbers are tried later.
How to confirm it worked
dig +short MX ‹domain› — confirm the preference values reflect your intent
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 ‹duplicate targets› at preference ‹preference›. RFC 5321 §5.1 requires a sender to randomise the order of hosts at equal preference "to spread the load across multiple mail exchangers", so this is the configuration the standard describes for an active-active pair, and it is reported for information: it deducts nothing. It is wrong only for a primary/backup arrangement, where the backup should carry a larger preference number so that it is tried later.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.