Reverse DNS (PTR) Explained: What It Reveals About an IP and Why Mail Servers Check It
How PTR records work, who controls them, what generic hostnames signal to spam filters, how forward-confirmed reverse DNS works, and how to fix a missing PTR for a mail server.
By yandong2023 · Editorial review 2026-08-14
Forward DNS turns names into addresses; reverse DNS goes back
Ordinary DNS answers “what is the address of example.com?”. Reverse DNS answers the opposite question: “what name belongs to 192.0.2.10?”. The answer is a PTR record stored under a special domain—in-addr.arpa for IPv4 and ip6.arpa for IPv6—where the address is written backwards. To find the name for 192.0.2.10, a resolver looks up 10.2.0.192.in-addr.arpa.
You can try it in seconds: dig -x 8.8.8.8 +short returns dns.google, and dig -x 1.1.1.1 +short returns one.one.one.one. TrustIP runs the same lookup for every address and shows the result in the “Reverse DNS” row.
Who controls a PTR record
This is the part people most often get wrong. A PTR record is controlled by whoever holds the address block—your ISP, your cloud provider or your hosting company—not by whoever owns the domain name in the record. Owning example.com does not let you publish a PTR for your server’s IP; you have to set it through the provider that assigned the address.
That is also why PTR records carry information. A provider decides how to name its addresses, so names follow its conventions: cloud addresses often look like ec2-198-51-100-7.compute-1.amazonaws.com, home broadband addresses often embed the IP and words such as dynamic, dsl, pool or cable, and well-run servers use a name under their own domain.
Why mail servers care so much
Receiving mail servers use reverse DNS as a cheap first filter. A sending IP with no PTR at all, or with a generic name that looks like home broadband, is statistically much more likely to be a compromised device than a real mail server. Many receivers reject or heavily penalize such connections before even looking at the message.
Large mailbox providers state this explicitly. Google’s email sender guidelines require that sending domains or IPs have valid forward and reverse DNS records. Missing or mismatched reverse DNS is one of the most common reasons a newly built mail server sees its first messages bounce or land in spam.
Forward-confirmed reverse DNS (FCrDNS)
Because anyone who controls an address block can put any name in a PTR record—including a name under a domain they do not own—a PTR alone proves little. Receivers therefore check that the name points back: they look up the PTR for the IP, then look up the A or AAAA record of that name, and confirm the original IP is among the results. When both directions agree, the setup is called forward-confirmed reverse DNS.
- dig -x 203.0.113.25 +short → mail.example.com
- dig mail.example.com A +short → 203.0.113.25 (must include the same IP)
- Use the same name in your SMTP HELO/EHLO greeting for the cleanest result.
How to fix a missing or generic PTR
- Cloud servers: most providers let you set reverse DNS for a static or elastic IP in the console or through support; some require you to first create the matching forward record and to request that outbound port 25 be unblocked.
- Business broadband: ask the ISP to delegate or set the PTR for your static IP. Residential dynamic addresses usually cannot get a custom PTR and should not send mail directly—relay through your provider or a mail service instead.
- After the change, wait for the old record’s TTL to expire and re-check both directions.
- Do not expect a PTR to fix everything: SPF, DKIM and DMARC are separate requirements, and a blocklist listing must be addressed with the list operator.
What a PTR cannot tell you
A PTR is a label chosen by the address holder. It can be missing on perfectly legitimate servers, and a well-formed name does not prove that the server is well behaved. Treat it as one piece of network identity alongside the ASN, the organization and the address type, and never as a verdict about the person using the address.
References and source material
These sources are provided so readers can verify the technical background. Inclusion does not imply endorsement of TrustIP.