What is reverse DNS, and what does your PTR record say?

Reverse DNS runs name-lookups backwards: instead of asking "what address is example.com?", it asks "what name belongs to this address?" — answered by a PTR record that the network's owner controls. For most home connections the answer is an auto-generated label leaking nothing personal; for anyone running a mail server it's a deliverability requirement; and for anyone reading logs it's the difference between a bare number and a hint about who's knocking. Here's the whole picture, starting with yours.

Maintained by the ipconfig.io team · Reviewed 1 July 2026

Look up yours

curl ipconfig.io/json

The hostname field is your address's reverse DNS, resolved live (empty means no PTR record exists — common and harmless). The general-purpose lookups for any IP:

dig -x 1.1.1.1 +short      # one.one.one.one
nslookup 8.8.8.8           # dns.google

How the backwards direction works

Forward DNS maps example.com → 203.0.113.42 via an A record, published by the domain's owner. Reverse DNS maps 203.0.113.42 → some-name via a PTR record under the special in-addr.arpa zone (ip6.arpa for IPv6) — published by the address block's owner, usually an ISP or hosting company.

That ownership split is the key fact: you can point any domain you own at your IP, but only your ISP can set what the IP points back to. It also means the two directions are independent — nothing forces them to agree, which is why "forward-confirmed rDNS" (PTR and A record matching) is treated as a mark of a well-run server.

Your home connection's PTR is almost certainly machine-made — 203-0-113-42.dyn.example-isp.net style — encoding the address and the ISP's pool naming scheme. It reveals roughly what the ASN fields already do (which network, roughly what kind), and nothing about you personally.

Where it actually matters

• Email delivery — the big one. Receiving mail servers routinely check the connecting IP's PTR; missing or generic-residential rDNS is a classic spam signal, and self-hosted mail on an IP without a proper matching PTR will bounce or land in spam. This is why mail hosting on residential connections is nearly impossible — your ISP won't set a custom PTR (and behind CGNAT, the address isn't even yours to name).
• Logs and traceroutes. rDNS is what turns 142.250.64.78 into something readable in a traceroute hop or an access log — including ours: the residential-vs-datacenter flavor of a PTR name is a weak but useful classification signal.
• A weak trust signal. Some services treat no-PTR or pool-style PTR connections with more suspicion. Weak because it's trivially controllable by whoever owns the block — a signal, never proof.

For VPS and cloud users, the practical note: most providers let you set a custom PTR in their control panel (often gated on a matching forward record). If you send mail from that box, do it before anything else.

Frequently asked questions

What is reverse DNS? The IP-to-name direction of DNS, answered by PTR records that the address block's owner publishes.

How do I look it up?dig -x <ip> +short, nslookup <ip>, or the hostname field of curl ipconfig.io/json for your own address.

Why is mine a random-looking code? ISPs auto-generate PTR names for customer pools. It encodes the address, not your identity — and only the ISP can change it.

Where does it matter? Mail deliverability above all, plus readable logs/traceroutes and a weak network-type signal.

Next steps

• What is an ASN, and how to find yours — the other identity your address carries.
• What is CGNAT? — when the address (and its PTR) belongs to a shared pool.
• Get your public IP in code — reading the hostname field programmatically.