Mail server address has no reverse DNS (PTR) record
What this check looks for
One of the addresses your mail server uses has no name attached to it. Many large mail providers reject or heavily filter mail from an address with no reverse DNS.
Why it matters
Receivers use reverse DNS as a first, cheap test of whether a sender is a real mail server. An address with none looks like a compromised home router, and messages are rejected at connection time — before any content filtering, and often with no bounce the sender understands.
When the check passes, your report says: “Every sending address has a reverse DNS name”.
What it costs your score
When this check fails it removes 20 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
- high
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 20 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
Ask the provider that owns ‹address› to publish a PTR record pointing at ‹mx host›.
Without it, receivers that require reverse DNS reject your mail at the SMTP connection.
Identify who owns the address:
whois ‹address›names the organisation the block is allocated to. It is usually your hosting provider, cloud platform or ISP — not your DNS host.Open a reverse-DNS (rDNS or PTR) request with that provider. Most cloud platforms expose it as a field on the instance or elastic-IP page; smaller hosts take it as a support ticket.
Ask for the PTR to be set to
‹mx host›— the same name your MX record points at.Make sure
‹mx host›has a forward A or AAAA record pointing back at ‹address›, so the name confirms in both directions.
How to confirm it worked
dig +short -x ‹address› — expect ‹mx host›.
dig +short ‹mx host› — expect ‹address› back, which completes the full circle.
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
No PTR record exists at ‹address›'s reverse name for the mail server ‹mx host› of ‹domain› (lookup result: ‹lookup result›). RFC 1912 §2.1 requires every internet-reachable address to have a matching PTR record. The reverse zone is delegated to the organisation that holds the address block, so the record is created by them, not in this domain's DNS.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.