Reverse DNS does not confirm forward (no full-circle match)
What this check looks for
Your mail server's address has a name attached, but that name does not resolve back to the same address. Receivers that check both directions treat this as an unverified sender.
Why it matters
Anyone can point a name at any address in reverse. Only the forward record proves the name's owner agrees, which is why receivers check both. A half-configured pair is treated much like having no reverse DNS at all.
When the check passes, your report says: “Reverse DNS resolves back to the same address, full circle”.
What it costs your score
When this check fails it removes 12 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
- medium
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 12 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
Make the PTR name resolve forward to the same address.
A reverse name that does not confirm forward gives receivers no evidence the sender is who it claims.
Decide which hostname the mail server should be known by — normally
‹mx host›.In your own DNS, publish an A record (or AAAA for IPv6) for that hostname pointing at ‹address›.
Ask the provider that owns ‹address› to set the PTR to that same hostname if it does not already match.
If the PTR points at a name you do not control, that is the provider's default name; ask for it to be changed rather than adding a forward record you cannot manage.
How to confirm it worked
dig +short -x ‹address› — note the name returned.
dig +short <that name> — expect ‹address›.
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 lookup of ‹address› returned ‹ptr names›, but resolving those names forward produced ‹forward addresses› rather than ‹address›. RFC 8601 §2.7.4 defines this full-circle check as the iprev authentication method, and large receivers evaluate it on every connection.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.