Run a lookup
How it works
Paste the addresses
IPv4 or IPv6, one per line. The reversed arpa name is built for you.
Query PTR over DoH
The lookup runs from your browser against public resolvers.
Read the hostname
The name the address resolves back to. An empty result means no reverse DNS is configured at all.
Confirm it matches forward
The hostname should resolve back to the same IP. A PTR that points at a name which does not return is treated as no PTR at all.
Why this is not optional for a sending server
Reverse DNS is one of the first things a receiving mail server checks, and it happens during the connection, before your message content or your authentication records are looked at. A connection from an address with no PTR record is a strong spam signal on its own, and several large receivers reject it outright with a message about the connecting host not having valid reverse DNS. No amount of correct SPF, DKIM and DMARC compensates, because the connection is refused before any of that is evaluated.
This only applies to infrastructure you control. If you send through Google Workspace, Microsoft 365 or an ESP, they own the connecting IPs and their reverse DNS is already correct. The moment you put a VPS or a self-hosted relay into the path, it becomes yours to configure, and it is set at the provider who allocated the address — not in your domain's DNS panel, which is where people usually look first.
Forward-confirmed reverse DNS
Setting a PTR record is half the job. Receivers routinely check that the name it returns resolves back to the same address — a full circle known as forward-confirmed reverse DNS. A PTR pointing at mail.yourdomain.com with no corresponding A record at that name is treated as no PTR at all, and quietly fails the same checks. The convention is to make the PTR match the hostname your server announces in its HELO or EHLO greeting, and to make that name resolve to the sending address.
The IPv6 half nobody configures
A server with an IPv6 address will often prefer it for outbound connections. If reverse DNS was configured for IPv4 only, mail leaving over IPv6 hits receivers with no PTR while the IPv4 path stays clean. The symptom is maddening: identical messages from the same server, some delivered, some rejected, with no pattern visible from your side. If a host has an AAAA record and sends mail, it needs an IPv6 PTR as well — check both here.
Frequently asked questions
Where do I set a PTR record?
With whoever allocated the IP address — your VPS provider, cloud platform or ISP. It is not set in your domain's DNS. Most providers expose it as a reverse DNS or rDNS field in the console for that instance or IP, and some require a support request.
Do I need a PTR record if I send through Google Workspace?
No. Google owns the connecting addresses and their reverse DNS is already correct. It becomes your responsibility as soon as you send from your own server or relay.
What should the PTR record point to?
A hostname you control that resolves back to the same IP, and ideally the same name your server uses in its HELO greeting. Consistency across those three is what receivers check.
Why does my PTR lookup return nothing?
Either no reverse DNS has been set for the address, or the delegation for that range has not been configured by the provider. For addresses inside a larger block, the provider has to delegate the reverse zone before your entries take effect.
Can one IP have several PTR records?
Technically yes, and it is a bad idea. Receivers may pick any of them, so checks that depend on the hostname become unpredictable. Keep it to one.
Does a missing PTR affect anything other than mail?
Rarely. Web traffic does not care. It is specifically SMTP where reverse DNS is treated as a baseline signal of a legitimately operated server.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.