**Reverse DNS** is just shorthand for "do a PTR lookup". It is the inverse of a normal lookup. Normal lookup: hostname → IP. Reverse lookup: IP → hostname. The technical reason both directions exist is that **mail servers, intrusion detection tools, and many logging systems** want to know who is on the other end of a connection without trusting only the hostname the client claims to be.

What is FCrDNS and why do mail servers require it?

**FCrDNS** stands for **Forward-Confirmed reverse DNS**. It is a sanity check that both DNS directions agree: 1. Forward: `A(mail.example.com)` → `85.118.219.232` 2. Reverse: `PTR(85.118.219.232)` → `mail.example.com` 3. Both names match. Mail servers care because **anyone can set a PTR record** on an IP they control, but **only the legitimate owner of `example.com`** can set the matching A record. Requiring both ends to agree blocks spammers from spoofing reputable hostnames. Gmail, Outlook and Yahoo will silently reject SMTP traffic where FCrDNS fails.

Why does my mail keep going to spam if my PTR is set?

Setting **just a PTR** is not enough. The PTR target hostname must **also have a forward A or AAAA record pointing back to the same IP**. If your PTR says `mail.example.com` but `mail.example.com` has no A record (or has one pointing somewhere else), **FCrDNS fails** and Gmail / Outlook treat you as suspicious. Use this tool to confirm both sides agree, then check **SPF, DKIM and DMARC** as the next layer.

How do I set up a PTR record with my hosting provider?

PTR records are **special**: you cannot set them yourself in your normal DNS panel. They are controlled by **whoever owns the IP block** - usually your hosting provider or datacenter, not you. The process: 1. Decide the hostname you want (e.g. `mail.your-domain.com`). 2. In **your own DNS panel**, create an **A record** (IPv4) or **AAAA record** (IPv6) for that hostname pointing to your server IP. 3. **Open a ticket** with your hosting provider asking them to set the PTR for that IP to that hostname. AWS calls this "Request to remove email sending limitations". Hetzner, OVH, DigitalOcean, Linode all have a self-service form. 4. Wait 5 to 60 minutes for propagation, then re-check here.

What is `in-addr.arpa` and why is it backwards?

IPv4 PTR records live in the **`in-addr.arpa`** zone, and the IP gets **reversed** before lookup. `8.8.8.8` becomes `8.8.8.8.in-addr.arpa`. The reversal is a clever hack: DNS is hierarchical and reads **right to left** (`com` → `example` → `mail`), but IPs are usually hierarchical **left to right** (the leftmost octet is the most general). Reversing the IP lets DNS delegate `8.in-addr.arpa` to the holder of `8.0.0.0/8`, who can then delegate `8.8.in-addr.arpa` further down, and so on.

What about IPv6 PTR records?

IPv6 PTR records live in **`ip6.arpa`** and use the same reverse-and-delegate trick, but at **nibble** (4-bit) granularity. The IP is expanded to its full 32-hex-digit form, reversed digit by digit, and dots inserted between every nibble: `2606:4700:4700::1111` → `2606:4700:4700:0000:0000:0000:0000:1111` → reverse digits → `1.1.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.0.0.7.4.6.0.6.2.ip6.arpa`. Painful by hand, instant for a resolver. The tool handles all of this for you.

Why do some IPs have no PTR at all?

Most commonly: - **Residential / consumer ISP**: home IP addresses rarely get a PTR. ISPs treat them as ephemeral. - **Cheap VPS or shared hosting**: the provider only sets PTRs on request, the default is empty. - **Cloud providers**: AWS / GCP / Azure assign generic PTRs (`ec2-x-x-x-x.compute.amazonaws.com`) that **fail FCrDNS** for any custom domain you might want to use. You need to request a custom PTR explicitly. - **CDN / proxy edge nodes**: deliberately stripped because the same IP serves thousands of customers. - **The IP belongs to a non-routed block**: bogons (`10.x`, `192.168.x`, `127.x`) never have a real PTR.

What is the difference between IPv4 and IPv6 PTR records in practice?

Functionally the **same**: both map an IP to a hostname, both require FCrDNS for mail, both are controlled by whoever owns the IP block. **Practical differences**: - **IPv6 PTRs are still rarely set** by hosting providers, especially on cheap plans. If you send mail from an IPv6 address, double-check the PTR exists, otherwise the receiving server may either reject you or fall back to a missing-record penalty. - **Many MTAs prefer IPv4 for outbound SMTP** specifically because IPv6 PTR coverage is patchy. Postfix has `smtp_address_preference = ipv4` for exactly this reason. - **Setting up IPv6 PTR is identical**: ticket to your hosting provider, wait, re-verify here.

Do you store the IPs I look up?

No. Your IP query is **forwarded through Node's `dns/promises`** to a public resolver, the answer comes back, you see it, and the request ends. **We do not log queries, we do not log your IP**, we do not build profiles. The only piece of state on the server is the in-memory **rate-limit counter** (60 lookups per hour per caller IP), which resets every hour and never contains query content.

Reverse DNS (PTR) Lookup - free

Reverse DNS (PTR) lookup: confirm the hostname behind any IP

Reverse DNS is the mirror image of a normal DNS query. A normal forward lookup turns `mail.example.com` into the IP `85.118.219.232`. A reverse lookup goes the other way: you hand DNS the IP, and it returns a PTR record with the hostname.

This sounds academic until you run a mail server. Gmail, Outlook and Yahoo all check the PTR of every IP that tries to deliver SMTP traffic to them. No PTR, or a PTR that does not match the forward record, equals silent rejection or a one-way trip to the spam folder.

This tool queries the PTR through Node's `dns/promises` (the same resolver `dig` uses, no DoH proxy in between) and then verifies FCrDNS by resolving the PTR target's A and AAAA records back. You get a green check when both directions agree, a red flag when they do not, and a step-by-step fix when something is broken.

How to use it

Enter an IP: plain IPv4 (`8.8.8.8`) or IPv6 (`2606:4700:4700::1111`). No port, no CIDR prefix.
Click Check. The result usually arrives in under a second, sometimes 2 to 3 seconds for IPv6 addresses with slow upstream resolvers.
Read the PTR record at the top: this is the hostname the IP claims to be (e.g. `dns.google` for `8.8.8.8`).
Below that, see the forward A and AAAA records of that hostname. This is the round-trip check.
FCrDNS badge: green Pass means the round-trip matches, red Fail means PTR exists but forward records do not point back to your IP.
If FCrDNS fails, read the Suggested action: it tells you exactly what to ask your hosting provider to fix.
No PTR at all? Common for residential ISPs and small VPS plans. The action box explains how to request one.

When this is useful

Seven typical situations where a reverse DNS check saves your sanity:

Setting up a new mail server before you flip the DNS for production. Verify PTR matches before sending the first message, otherwise Gmail will route everything to spam from day one.
Debugging deliverability: clients complain your emails do not arrive. You check the IP your MTA uses for outbound SMTP, you discover the PTR points to the generic hosting hostname (`ec2-54-203-xxx.compute.amazonaws.com`) instead of `mail.your-domain.com`. The fix is one ticket.
Auditing a third-party SMTP relay: you pay SendGrid / Mailgun / Postmark to send for you. You spot-check the sending IP. PTR matches their public mail domain, all good.
Investigating an abuse complaint: a log line says "abuse from 185.220.101.7". You PTR it. The hostname says TOR exit node in plain English, so you know what you are dealing with.
Verifying an SSL certificate's host: some self-signed certs encode the server IP only. PTR confirms which hostname is the canonical owner.
Network forensics on inbound traffic: a request hits your server from an unknown IP. PTR shows `crawl-66-249-66-1.googlebot.com`. Now you know it is real Googlebot and not someone spoofing the user agent.
Confirming residential vs datacenter: a TLS handshake from a "browser" comes from an IP with PTR `example.linode.com`. That is not a browser, it is a script on a VPS.

Questions and answers

A PTR (pointer) record is a DNS entry that maps an IP address back to a hostname - the opposite direction of A and AAAA records. It lives in a special zone: `in-addr.arpa` for IPv4 and `ip6.arpa` for IPv6. When you "do a reverse lookup", you are really asking the DNS server: "give me the PTR record at `8.8.8.8.in-addr.arpa`". The answer (`dns.google`) is a regular DNS reply, just stored in this special tree.

Reverse DNS (PTR) lookup: confirm the hostname behind any IP

How to use it

Enter an IP: plain IPv4 (`8.8.8.8`) or IPv6 (`2606:4700:4700::1111`). No port, no CIDR prefix.

Click Check. The result usually arrives in under a second, sometimes 2 to 3 seconds for IPv6 addresses with slow upstream resolvers.

Read the PTR record at the top: this is the hostname the IP claims to be (e.g. `dns.google` for `8.8.8.8`).

Below that, see the forward A and AAAA records of that hostname. This is the round-trip check.

FCrDNS badge: green Pass means the round-trip matches, red Fail means PTR exists but forward records do not point back to your IP.

If FCrDNS fails, read the Suggested action: it tells you exactly what to ask your hosting provider to fix.

No PTR at all? Common for residential ISPs and small VPS plans. The action box explains how to request one.

When this is useful

Seven typical situations where a reverse DNS check saves your sanity:

Setting up a new mail server before you flip the DNS for production. Verify PTR matches before sending the first message, otherwise Gmail will route everything to spam from day one.
Debugging deliverability: clients complain your emails do not arrive. You check the IP your MTA uses for outbound SMTP, you discover the PTR points to the generic hosting hostname (`ec2-54-203-xxx.compute.amazonaws.com`) instead of `mail.your-domain.com`. The fix is one ticket.
Auditing a third-party SMTP relay: you pay SendGrid / Mailgun / Postmark to send for you. You spot-check the sending IP. PTR matches their public mail domain, all good.
Investigating an abuse complaint: a log line says "abuse from 185.220.101.7". You PTR it. The hostname says TOR exit node in plain English, so you know what you are dealing with.
Verifying an SSL certificate's host: some self-signed certs encode the server IP only. PTR confirms which hostname is the canonical owner.
Network forensics on inbound traffic: a request hits your server from an unknown IP. PTR shows `crawl-66-249-66-1.googlebot.com`. Now you know it is real Googlebot and not someone spoofing the user agent.
Confirming residential vs datacenter: a TLS handshake from a "browser" comes from an IP with PTR `example.linode.com`. That is not a browser, it is a script on a VPS.

Questions and answers

Reverse DNS (PTR) Lookup

Reverse DNS (PTR) lookup: confirm the hostname behind any IP

How to use it

When this is useful

Questions and answers

Related tools

DNS Lookup

What's my IP

IP Info / ASN Lookup

Email DNS Checker (SPF/DKIM/DMARC)

Reverse DNS (PTR) Lookup

Reverse DNS (PTR) lookup: confirm the hostname behind any IP

How to use it

When this is useful

Questions and answers

Related tools

DNS Lookup

What's my IP

IP Info / ASN Lookup

Email DNS Checker (SPF/DKIM/DMARC)