Reverse DNS turns an IP address back into a hostname. For email it is one of the first checks a receiving server runs: before it even reads your message, it looks up the PTR record for the connecting IP and checks whether the name looks like a real mail server.
A missing or generic PTR record marks the connection as suspicious. Gmail rejects it outright, and many business gateways do the same. This checker shows you what receivers see.
What the checker does
- Looks up the PTR record for the IPv4 address you enter.
- Resolves the returned hostname forward to its A records.
- Confirms whether the original IP is among them (forward-confirmed reverse DNS, or FCrDNS).
- Checks the hostname for patterns typical of residential or dynamic addresses and warns if it looks generic.
How reverse DNS works
A normal lookup goes name to IP:
mail.example.com. A 203.0.113.25
Reverse DNS goes IP to name, using the in-addr.arpa zone with the octets reversed:
25.113.0.203.in-addr.arpa. PTR mail.example.com.
The PTR record is controlled by whoever owns the IP range, usually your hosting or cloud provider. Your domain’s DNS host cannot create it for you, which surprises many people the first time.
Forward-confirmed reverse DNS
A PTR record on its own proves little, since the owner of any IP range can claim any hostname. FCrDNS closes that gap.
| Step | Lookup | Example result |
|---|---|---|
| 1. Reverse | PTR for 203.0.113.25 |
mail.example.com |
| 2. Forward | A for mail.example.com |
203.0.113.25 |
| 3. Compare | Does step 2 include the original IP? | Yes: FCrDNS passes |
If step 2 returns a different IP, or no IP, the check fails. Receivers treat that as a sign that the name was chosen without the domain owner’s agreement.
Generic versus branded hostnames
Having a PTR record is not enough if it looks like it belongs to a home connection.
| Hostname | Verdict | Why |
|---|---|---|
mail.example.com |
Good | Branded, clearly a mail server |
smtp1.out.example.com |
Good | Branded, descriptive |
o12.email.esp-provider.net |
Fine | Belongs to a known ESP’s sending pool |
ec2-203-0-113-25.compute-1.amazonaws.com |
Weak | Default cloud name, common for abusive senders |
203-0-113-25.dynamic.isp.example |
Poor | Contains the IP and “dynamic” |
host25.dsl.pool.isp.example |
Poor | Residential access range |
Spam filters look for IP octets embedded in the name and words like dynamic, dsl, cable, pool, dhcp or ppp. The checker flags these patterns. Spamhaus PBL often lists such ranges as not meant for direct mail.
Setting a PTR record at common providers
The process depends on who owns the IP, not on where your domain’s DNS is hosted.
| Provider | Where to set reverse DNS |
|---|---|
| AWS (Elastic IP) | EC2 console, Elastic IPs, “Update reverse DNS” (the A record must exist first) |
| Google Cloud | Set the PTR domain on the VM’s external IP in the network interface settings |
| Microsoft Azure | Set the reverse FQDN on the public IP resource via CLI or portal |
| DigitalOcean | Name the Droplet with the exact hostname; the PTR follows the Droplet name |
| Hetzner, OVHcloud, Linode | A reverse DNS field next to the IP in the control panel |
| Office or data centre line | Open a ticket with the ISP or colocation provider |
In every case, create the forward A record in your own DNS first. Several providers refuse to set a PTR for a hostname that does not already resolve to the IP. Changes usually take effect within minutes to a few hours, depending on the provider’s TTL.
Common problems and fixes
No PTR record. Ask your hosting or cloud provider to set one. On AWS, request it for an Elastic IP through the console. On most VPS hosts it is a field next to the IP in the control panel.
PTR set, but forward lookup fails. You created the PTR but never added the A record for that hostname in your own DNS. Add mail.example.com A 203.0.113.25.
Default provider hostname. It passes FCrDNS but looks generic. Replace it with a hostname on your own domain.
Mismatch with the SMTP greeting. Your server announces itself as server01.local in its HELO/EHLO while the PTR says mail.example.com. Set the mail server’s hostname to match the PTR.
Changed IP after migration. The new server’s IP still carries the previous tenant’s PTR. Update it before sending anything.
Do you need to manage reverse DNS?
It depends on how you send.
- Through an ESP on shared IPs: no. The provider sets PTR records for its pool.
- Through an ESP on a dedicated IP: usually the provider handles it, and some let you set a branded hostname. Worth checking before a dedicated IP warmup.
- From your own server or cloud instance: yes, always.
To find the IP your mail actually leaves from, paste a message’s headers into the header analyzer and look at the first hop outside your network. Then run that IP here and through the blacklist checker.
Where reverse DNS fits in your reputation
Reverse DNS is part of basic infrastructure hygiene alongside correct MX records, SPF, DKIM and DMARC. The sender reputation checker tests PTR and FCrDNS on every MX IP as part of its DNS health score. For the full list of records a sending domain should publish, see DNS records for email.