Two MX hosts share the same preference value
What this check looks for
Two of your mail servers are given the same priority, so senders will spread mail across both at random. That is only correct if both really are equivalent.
Why it matters
If one of the two is a backup that is not configured to handle live mail, 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
When this check fails it removes 3 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
- low
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 3 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
Give a backup mail server a higher preference number than the primary.
Equal preference means random selection, which sends live mail to a host that may not be ready for it.
Decide whether the two hosts are genuinely equivalent.
If not, raise the backup's 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 says hosts at equal preference are tried in an unspecified order, which senders generally implement as random selection for load spreading. This is correct for a true active-active pair and wrong for a primary/backup arrangement.
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
- 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
- Every mail server resolves to the same address
- Domain publishes a null MX (receives no mail)
- Only one mail server host is published