Reverse DNS / PTR Lookup

What reverse DNS is for

"Forward" DNS converts a name to an IP (myipcat.com → 104.21.51.82). Reverse DNS does the opposite — given an IP, it returns the hostname (if one is set). Reverse DNS uses PTR records published in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones.

Where PTR records actually matter

• Email deliverability — receiving mail servers reject (or score as spam) email from sending IPs without matching PTR/forward records. If you run your own mail server, set up PTR or your mail goes nowhere.
• Log analysis — server logs are full of IPs. PTR lookups make them human-readable: 52.85.132.45 becomes server-52-85-132-45.bos2.cloudfront.net.
• SSH brute-force detection — sketchy login attempts often come from IPs with weird or missing PTR records.
• IP reputation — many reputation services use PTR records as a signal.

Who controls the PTR record?

The PTR record is controlled by whoever owns the IP block — typically your ISP or hosting provider, not you. To get a custom PTR (e.g. mail.example.com), you submit a request to your provider. Some self-service providers (AWS, OVH, Hetzner, Vultr) let you set it via their dashboard.

Why reverse DNS matters more than people think

Reverse DNS is what turns an IP address back into a hostname. If A records go from name to IP, PTR records go the other direction — from IP back to name. The concept sounds simple until you realize how much of the internet's infrastructure depends on it working correctly.

Email delivery is the biggest example. Gmail, Outlook, Yahoo, and every other major mail provider check the reverse DNS of the connecting SMTP server before accepting mail. If the IP has no PTR record, or the PTR record doesn't match the HELO name, or the forward-confirmed reverse DNS check fails (looking up the PTR name and seeing if it resolves back to the same IP), the receiving server treats the incoming mail with suspicion. Legitimate mail servers pass these checks. Random compromised residential IPs sending spam almost never do.

Log analysis is another. When you're reviewing web server logs and you see a hundred thousand requests from IP 192.0.2.4, running the reverse DNS often tells you it's a Google crawler, a security scanner, or a specific customer's proxy — much more useful than the raw IP alone.

How reverse DNS actually works

The DNS system stores forward and reverse lookups in different zones. Forward lookups (name to IP) live in whichever zone owns the name. Reverse lookups (IP to name) live in special zones under in-addr.arpa (for IPv4) or ip6.arpa (for IPv6). The zones are delegated based on IP allocation, so the owner of an IP block has authority over the reverse DNS for their block.

To look up the PTR for 192.0.2.4, you query 4.2.0.192.in-addr.arpa for a PTR record. The octets are reversed because DNS delegation goes right-to-left in the name hierarchy — the top-level zone in-addr.arpa delegates to the /8 owner, then to the /16 owner, and so on. The IP itself is written in reverse to match this delegation pattern.

For IPv6, the process is similar but the address is expanded to its full form and each hex nibble becomes its own label. So 2001:db8::1 becomes 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. Verbose, but it's DNS being DNS.

Why some IPs don't have PTR records

Residential ISPs

Most residential ISPs publish generic PTR records for their entire customer address space, encoding the IP octets into the hostname. Comcast might publish something like c-73-11-42-88.hsd1.vt.comcast.net for the IP 73.11.42.88. That's not a name the customer chose — it's Comcast's naming template applied to every IP in the block. It's still a valid PTR record and satisfies checks that just require some reverse DNS to exist.

Cloud providers

AWS, Azure, and GCP customers can set custom PTR records for their public IPs, but most don't bother. The default PTR looks something like ec2-18-236-42-88.us-west-2.compute.amazonaws.com. This tells you the region and that it's an EC2 instance, which is useful for triage but not particularly professional-looking for a business.

Setting a custom PTR record on cloud IPs usually requires opening a support ticket, and there are restrictions — the reverse DNS name has to actually resolve back to the same IP, and there are anti-abuse checks. This is intentional to prevent malicious actors from claiming reverse DNS to trusted-looking names.

Small business connections

Business ISPs typically let customers set custom PTR records for their IP allocations. This is one of the small but important benefits of business internet service versus consumer. Being able to have your mail server's IP reverse-resolve to mail.example.com instead of some generic ISP template is genuinely useful for email deliverability.

When I use reverse DNS lookups in real work

Debugging email deliverability

A customer's outgoing email is landing in junk. First thing I check: what does the sending IP's PTR record say? If it's missing entirely, that alone can explain the delivery problems. If it's a generic ISP hostname or a cloud provider default, that's a weaker signal but still not great. If it's a proper mail-server-looking hostname that resolves back to the same IP, we can rule out reverse DNS as the issue and look at SPF, DKIM, and DMARC instead.

The Email Health Check tool bundles the reverse DNS check with SPF, DKIM, DMARC, and MX verification in one shot. But when I'm specifically investigating "what does the reverse DNS look like right now," this tool is faster.

Log analysis

When I'm reviewing a large log file with a lot of unfamiliar IPs, reverse DNS gives me useful context. googlebot.com in the reverse DNS is Google's crawler. *.bing.com is Microsoft's Bingbot. *.baidu.com is Baidu. *.yandex.com is Yandex. These are all legitimate crawlers and knowing that saves me from mistakenly blocking them.

On the other side, if I see a lot of traffic from IPs with no reverse DNS or with hostnames that look like residential ISP templates in countries the site doesn't do business with, that's often either bot traffic or a compromised network. The reverse DNS gives me a quick way to categorize.

Auditing a network

When I take on a new customer network, one of the things I check is whether their public IPs have appropriate reverse DNS. Their mail server IP should have a proper PTR record. Their web server IPs might or might not — depends on the site's purpose. Their VPN gateway probably should. Missing PTR records on important servers is a small but real security and deliverability issue.

Confirming that a claimed IP is actually the right one

Sometimes a vendor says "our servers are at 203.0.113.42, please allow this in your firewall." A quick reverse DNS check confirms that IP resolves to something in the vendor's expected domain — or reveals that it doesn't, which is worth asking about before punching a firewall hole.

Forward-confirmed reverse DNS

An extra layer of trust: reverse DNS says the IP is claimed by a certain name, but does the name actually resolve back to the same IP? Doing both lookups and confirming they match is called forward-confirmed reverse DNS (FCrDNS), and it's what makes reverse DNS actually trustworthy.

The check goes: (1) look up the PTR for the IP; (2) look up the A record for the resulting name; (3) confirm the A record's IP matches the original IP. If all three match, you have FCrDNS. If any step fails — no PTR, PTR points to a name that doesn't exist, or the name resolves to a different IP — the reverse DNS is essentially not trustworthy.

Mail servers require FCrDNS from senders. Web servers that log reverse DNS usually record the raw PTR without checking, because per-request FCrDNS is expensive. Log analysis tools that need trust in reverse DNS names should verify FCrDNS before treating the name as authoritative.

Common findings when I look up reverse DNS

Cloud instance defaults

AWS: ec2-A-B-C-D.region.compute.amazonaws.com. Tells you it's EC2 and the region.

GCP: A.B.C.D.bc.googleusercontent.com. Tells you it's Google Cloud.

Azure: hostname patterns vary but often include "cloudapp.azure.com".

DigitalOcean, Vultr, Linode: various patterns including the provider name.

These are default hostnames that tell you the hosting provider but nothing about the specific customer or purpose.

ISP customer templates

Comcast: c-A-B-C-D.hsd1.STATE.comcast.net. The octets are encoded and the state code hints at rough geography.

AT&T: A-B-C-D-static.ip.att.net for static assignments; various patterns for dynamic.

Verizon FiOS: hostnames under fios.verizon.net.

Cable providers generally: hostnames encoding the IP under the provider's residential subdomain.

Corporate mail servers

Well-configured business mail servers have PTR records like mail.example.com that forward-resolve back to the mail server IP. This is the reverse DNS signature that mail providers reward with better deliverability.

No PTR record

Either the IP block owner hasn't configured reverse DNS at all, or the specific IP isn't covered. Common for small business IPs where the ISP set up the reverse DNS delegation but the customer didn't fill in the records.

Related tools

If you're chasing an email deliverability problem, the Email Health Check combines reverse DNS with SPF, DKIM, DMARC, and MX record verification. If you want to know which network owns an IP more broadly (not just the reverse DNS but the ASN and geographic location), the IP Lookup tool gives you that.

If you're specifically investigating whether an IP is on any email blacklists, the DNSBL Blacklist Check queries six major DNSBLs in parallel and reports which ones list the IP.

Privacy

Reverse DNS lookups go through Cloudflare's public DNS-over-HTTPS resolver. The lookup traffic is encrypted between your browser and Cloudflare. Cloudflare's public resolver does not log query content beyond its aggregate statistics. Nothing about the lookup is retained on the myipcat.com side beyond standard analytics.