Reverse DNS lookup: PTR record and forward-confirm check
A reverse DNS lookup turns an IP address into a hostname by reading its PTR record. For email that is half the check: the hostname must also resolve back to the same IP, called forward-confirmed reverse DNS. Enter an IP and this tool does both lookups and says whether it passes the check Gmail and Yahoo apply.
You can paste a whole Received header line; the first IP in it is used.
Sample result
203.0.113.25 maps to mail.acme.example, and that name points back to it.
- IP address
- 203.0.113.25
- PTR
- mail.acme.example
- Resolves back
- 203.0.113.25
What this means for you
Matching reverse DNS is something many inboxes expect from a server that sends mail.
- PTR hostname for any public IP
- Forward-confirm check on each hostname
- Flags generic, auto-generated PTR names
- Nothing is sent to the IP itself
- PTR
- FCrDNS
- Sending IP
By SimpleVerifier Team · Last updated
How do I do a reverse DNS lookup?
- Enter the IP address of the server that sends your mail. You can paste a whole Received header line from a message; the first IP in it is used.
- Press Look up PTR. The tool queries the PTR record, then looks up the A or AAAA record of every hostname it returns.
- Pass means a PTR hostname resolves back to the same IP. If it doesn't, the result says which half is missing.
- To change a PTR record, ask whoever controls the IP range, usually your hosting or cloud provider; it can't be set in your domain's DNS.
Example
- You enter
- The IP
203.0.113.25, or a Received header line containing it. - You get
- The PTR record is
mail.acme.example, and that name resolves back to203.0.113.25, so it is forward-confirmed and the PTR name isn't a generic auto-generated one. - Limits
- One IP per lookup and 10 lookups a minute per connection.
How does a reverse DNS lookup work?
It asks DNS for the PTR record of the IP address, stored in a special reverse zone. The IPv4 address 209.85.220.41 is looked up as 41.220.85.209.in-addr.arpa, with the octets reversed, as set out in RFC 1035. IPv6 addresses use ip6.arpa with every hex digit reversed (RFC 3596). The answer is a PTR record naming a hostname. The tool shows the exact name it queried so you can repeat it with dig -x.
Reverse zones are delegated to whoever holds the IP block, not to whoever owns a domain. That is why you can't add a PTR record in Cloudflare or your registrar for a server you rent: the hosting provider controls the zone, and most offer a setting or a support request to change it.
How do I do a reverse DNS lookup in Windows, Linux or Mac?
Use nslookup followed by the IP on any of them: nslookup 209.85.220.41 in Windows Command Prompt, macOS Terminal or a Linux shell prints the PTR hostname. In PowerShell, Resolve-DnsName 209.85.220.41 -Type PTR does the same. On Linux and macOS, dig -x 209.85.220.41 +short gives just the hostname, and host 209.85.220.41 is a shorter alternative.
Those commands do only the first half. For the forward check, look up the hostname they return, for example dig +short mail-sor-f41.google.com, and confirm the same IP comes back. The lookup above runs both steps and compares them for you.
Why do mail servers need forward-confirmed reverse DNS?
Because Gmail and Yahoo require it on sending IPs, and many other receivers check it. Google's Email sender guidelines require every sender to have valid forward and reverse DNS on sending IPs, and Google lists the SMTP errors 4.7.23 and 5.7.25 for an IP with no PTR record or a PTR that doesn't resolve back. Yahoo's Sender Requirements also require valid reverse DNS. Receivers have checked it for years because spam-sending machines on home connections rarely have it.
Forward-confirmed means both directions agree: the IP's PTR names a hostname, and that hostname's A record (or AAAA for IPv6) includes the same IP. A PTR on its own isn't enough, because anyone who controls an IP block can point its PTR at any name, including yours. The forward lookup proves the hostname's owner agrees.
The hostname itself matters less than the match, but a generic provider name such as 203-0-113-5.static.example.net can count against you with some receivers; Yahoo asks for "meaningful, non-generic" PTR records. A name on your own domain, such as mail.yourcompany.com, with matching records in both directions, is the clean setup. More detail is in reverse DNS (PTR) records for email.
Do I need to check reverse DNS if I send through a platform?
Usually not. If your mail goes out through Google Workspace, Microsoft 365 or an email platform, the sending IPs belong to them and they manage reverse DNS. You only need to check this yourself when you run your own mail server or rent dedicated IPs. To find the IP that actually sent a message, open its headers and look at the first Received line added by the receiving server, or paste the headers into our email header analyzer. To check the rest of a domain's setup, use the bulk sender checker.
Is this the same as running nslookup or dig?
| This tool | nslookup or dig | |
|---|---|---|
| PTR lookup | Yes | Yes |
| Forward-confirm check | Automatic, for every PTR hostname | A second command, compared by hand |
| Paste a Received header | First IP extracted for you | Type the IP yourself |
| Which resolver answers | Ours, from outside your network | Your own network's resolver |
By hand: dig -x 203.0.113.5 +short, then dig +short on the hostname it returns. Running both from inside and outside your network rules out an internal DNS server giving a different answer.
Who uses this tool, and for what?
- IT admins
- Confirm a new mail server's PTR and A records match before it sends a single message, and after any IP change or migration.
- Cold emailers
- If you send from your own VPS or dedicated IPs rather than Google Workspace, check each IP's reverse DNS before warm-up starts, then run it through the IP blacklist check.
- Agencies
- When a client's mail bounces with
5.7.25, take the sending IP from the bounce or the headers and show them exactly which half of the check fails. - SaaS teams
- Check the IPs your app's own mail servers use for password resets and receipts, which often sit on cloud ranges with generic or missing PTR records.
What can’t this tool tell you?
- It shows reverse DNS as it is now. There is no PTR history, and a change you just made may still be cached for the record's TTL.
- It checks one IP at a time. To find which IP to check, use a message's headers.
- A pass means the records match, not that the IP is trusted. A clean PTR on a blocklisted IP still gets mail refused.
- It can't change anything. PTR records are set by whoever holds the IP block, usually your hosting provider.
Common questions
- What is a reverse DNS lookup?
- It finds the hostname for an IP address by querying the IP's PTR record, the reverse of a normal lookup that finds the address for a hostname. For 209.85.220.41 the query goes to 41.220.85.209.in-addr.arpa, and the answer is a hostname such as mail-sor-f41.google.com.
- What is the difference between forward and reverse DNS lookup?
- A forward lookup turns a hostname into an IP address using A or AAAA records. A reverse lookup turns an IP address into a hostname using a PTR record. Mail servers check both, and want them to agree.
- What is reverse DNS lookup used for?
- Mostly to judge mail servers: receivers check that a connecting IP has a PTR record that resolves back to it before accepting mail. It is also used to put readable names on IPs in server logs and network tools such as traceroute.
- What is a reverse lookup zone?
- The DNS zone that holds PTR records for a block of IP addresses, named under in-addr.arpa for IPv4 or ip6.arpa for IPv6. Public reverse zones are delegated to whoever holds the IP block; on a private network, such as Active Directory, an admin creates them on the internal DNS server.
- What is forward-confirmed reverse DNS?
- An IP whose PTR record names a hostname, where that hostname also resolves back to the same IP. Gmail and Yahoo require it on sending IPs, because a PTR alone can be set to any name by whoever controls the IP block, while the forward lookup has to be set by the hostname's owner.
- Why does a reverse DNS lookup fail?
- Usually because the IP's owner never published a PTR record, which is common for home broadband and freshly rented servers. The other failure is a PTR whose hostname doesn't resolve back to the IP. Both are fixed by the IP's provider and your own DNS, not by the receiving server.
- How do I set up a PTR record for my mail server?
- Ask the provider that owns the IP address, usually your hosting or cloud company. Reverse DNS is controlled by the IP block's owner, not in your domain's DNS. Set the PTR to a hostname on your domain, such as mail.yourcompany.com, then add an A record for that hostname pointing at the IP so the two match.
- Do I need a PTR record if I use Google Workspace or an email platform?
- No. When you send through Google Workspace, Microsoft 365 or an email service provider, the sending IPs and their reverse DNS are theirs to manage. You need to set it yourself only when you run your own mail server or have dedicated IPs.
- Can I look up an IPv6 address?
- Yes. IPv6 reverse DNS uses the ip6.arpa zone, with every hex digit of the fully expanded address reversed, and the forward check uses AAAA records instead of A records. Enter the IPv6 address as you would normally write it.
Sources
Authentication and capacity are half of deliverability.
The other half is who you send to. Every hard bounce counts against the domain and inboxes you are sending from, and nothing in DNS can tell you which addresses on your list are dead.
- Bulk verification with real SMTP mailbox checks
- Hard bounces removed before a send, not discovered after
- Catch-all, disposable and role detection on every row
One plan, cancel anytime, no contract. Sign in with Google and your first 100 email checks are free, no card. The free tools stay free either way.