Reverse DNS name does not match the mail server's own hostname
What this check looks for
The name in your mail server's reverse DNS is different from the name your MX record points at. This is legal and common, but a matching pair is what receivers expect to see.
Why it matters
When the reverse name, the MX name and the name the server greets with all agree, a receiver has three independent confirmations of the same identity. When they disagree, the sender looks like shared or borrowed infrastructure, which some filters weight against.
When the check passes, your report says: “Reverse DNS matches the mail server's own hostname”.
What it costs your score
When this check fails it removes 4 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.rdns family ceiling of 25 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
- 4 points
- Family cap
- email-transport.rdns · 25
- Category
- Email transport
- Module
- Email rdns
- Fix owned by
- ip provider
- In the ruleset since
- 2026.09
How to fix it
Where you control the naming, make the reverse name, the MX target and the SMTP greeting agree.
Three names that agree confirm one identity; three that differ confirm nothing.
If the mail server is yours, ask the address's owner to set the PTR to
‹mx host›.If the mail is hosted — Microsoft 365, Google Workspace, a shared host — the reverse name belongs to the provider and will name their infrastructure. That is expected, and nothing needs changing.
Set the server's SMTP greeting (its HELO/EHLO name) to the same hostname as well.
How to confirm it worked
dig +short -x ‹address› and dig +short MX ‹domain› — compare the names.
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
The reverse name for ‹address› is ‹ptr names›, while the MX record for ‹domain› points at ‹mx host›. Neither RFC 5321 nor RFC 1912 requires them to be equal, and shared hosting legitimately breaks the match, so this is a warning rather than a failure.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.