Why does my IP have no PTR record?

Reverse DNS is set by whoever controls the IP block — your hosting provider or ISP — not automatically. Many IPs, particularly dynamic ones, have no PTR at all. For a mail server you should request one.

What is forward-confirmed reverse DNS (FCrDNS)?

It means the PTR hostname, resolved forward, points back to the original IP. Both directions agreeing is what makes the mapping trustworthy; mail servers require it.

Why can I not look up 192.168.x or 10.x addresses?

Those are private/reserved ranges. This tool only resolves public IPs — querying internal addresses through a public service is both meaningless and a security risk.

Does reverse DNS affect email deliverability?

Yes, significantly. Many receivers reject or penalise mail from IPs with missing or non-forward-confirming PTR records, so a correct rDNS is a baseline requirement for a sending server.

Can one IP have multiple PTR records?

Yes. It is unusual but valid; this tool shows every PTR name returned and forward-confirms each one independently.

Reverse DNS Lookup

Forward DNS turns a name into an address. Reverse DNS does the opposite: it turns an IP address back into a hostname, using a PTR ("pointer") record. This tool takes a public IP, performs the PTR lookup, and then does the important second step most tools skip — it forward-confirms the result.

How reverse DNS works

PTR records live in a special reverse zone. An IPv4 address like 93.184.216.34 is queried as 34.216.184.93.in-addr.arpa; IPv6 uses the ip6.arpa tree, nibble-reversed. Crucially, the PTR record is controlled by whoever runs the IP block (your hosting provider or ISP), not by the owner of the forward domain. That is why reverse and forward DNS can disagree — and why confirming them together matters.

Forward-confirmed reverse DNS (FCrDNS)

A PTR record on its own proves nothing — anyone controlling an IP can point it at any name. Forward-confirmation closes the loop: we take the hostname the PTR returns, resolve that name forward, and check the original IP is in the result. When both directions agree, the mapping is trustworthy. This FCrDNS check is exactly what mail servers run on every inbound connection.

Why it matters for security and email

Reverse DNS is central to email deliverability. Receiving mail servers routinely reject or heavily penalise connections from IPs that have no PTR record, or whose PTR fails forward-confirmation — it is a cheap, strong signal of a misconfigured or throwaway sender. For blue teams and investigators, reverse DNS on the IPs in a log turns raw addresses into readable infrastructure ("this is an AWS host", "this is a residential ISP range") and helps cluster related systems.

Note on scope and safety

This tool only accepts public, routable IP addresses. Private, loopback, link-local and reserved ranges (10.x, 192.168.x, 127.x, 169.254.x, and their IPv6 equivalents) are rejected by design — resolving internal addresses through a public service is an SSRF vector, and the answers would be meaningless anyway.

Common mistakes

Expecting a PTR to exist for every IP — many addresses (especially dynamic residential ones) simply have none.
Treating a PTR as proof of identity — without forward-confirmation it is trivially spoofable.
Assuming one IP maps to one name — a single address can carry multiple PTR records.

Reverse DNS Lookup

How reverse DNS works

Forward-confirmed reverse DNS (FCrDNS)

Why it matters for security and email

Note on scope and safety

Common mistakes

Expecting a PTR to exist for every IP — many addresses (especially dynamic residential ones) simply have none.

Treating a PTR as proof of identity — without forward-confirmation it is trivially spoofable.

Assuming one IP maps to one name — a single address can carry multiple PTR records.

Reverse DNS Lookup