Reverse DNS Lookup

Find the hostname an IP address maps back to. Enter an IPv4 or IPv6 address and this tool builds the reverse pointer name and queries its PTR record live, showing the hostname the address resolves to. You can also paste a domain — it resolves the address first, then does the reverse lookup. Reverse DNS is what mail servers check to decide whether to trust a sender, so a correct PTR matters for deliverability.

How to use the Reverse DNS Lookup

Enter an IP address (IPv4 like 8.8.8.8 or IPv6 like 2606:4700:4700::1111) and press Reverse lookup. The tool reports:

• The reverse zone name it constructed (under in-addr.arpa for IPv4 or ip6.arpa for IPv6).
• The PTR record — the hostname the IP maps back to — with its TTL, or a clear note if none exists.

You can also enter a hostname: the tool resolves its A record first, then reverse-looks-up that IP, showing the full name → IP → PTR path. Reverse DNS for an IP is controlled by whoever owns the IP block, not by the domain owner.

What reverse DNS and PTR records are

Normal (forward) DNS turns a name into an IP address with an A or AAAA record. Reverse DNS goes the other way: it turns an IP address back into a name, using a PTR (pointer) record. It answers the question "which hostname claims this IP?".

The mechanism is a clever reuse of ordinary DNS. The IP is rewritten as a name in a special reverse zone:

• IPv4 — the four octets are reversed and placed under in-addr.arpa. So 8.8.4.4 becomes 4.4.8.8.in-addr.arpa, and a PTR there names the host.
• IPv6 — each of the 32 hex nibbles is reversed and placed under ip6.arpa, producing a long but mechanical name.

The crucial point about reverse DNS is who controls it. PTR records live in the reverse zone for an IP block, and that zone is delegated to whoever owns the IP range — your hosting provider, cloud platform or ISP — not to the owner of the domain that points at the IP. So you cannot set your own PTR by editing your domain's DNS; you request it from your provider (most clouds expose a "reverse DNS" or "PTR" setting per IP).

Reverse DNS matters most for email. Receiving mail servers routinely look up the PTR of a connecting server's IP and check that it both exists and matches the server's forward hostname — a test called forward-confirmed reverse DNS (FCrDNS). A missing or generic PTR (like the default ip-203-0-113-5.example-isp.net) is a strong spam signal and a common reason legitimate mail lands in junk or is rejected outright. Reverse DNS is also used in server logs and traceroutes to put human-readable names against raw addresses.

Common use cases

• Email deliverability — confirm a sending IP has a PTR that matches its forward hostname (FCrDNS).
• Identifying an IP — see what hostname an address in your logs or firewall belongs to.
• Verifying a new mail server — check the PTR your host set after you requested reverse DNS.
• Investigating traffic — put a name to an IP hitting your server or appearing in an abuse report.
• Debugging deliverability complaints — find a missing or generic PTR that is hurting your sender reputation.

Forward-confirmed reverse DNS (FCrDNS)

For mail, a PTR on its own is not enough — it has to agree with the forward record. FCrDNS passes when:

• The mail server connects from an IP, say 203.0.113.5.
• Its PTR resolves that IP to a hostname, say mail.example.com.
• The A record of that hostname resolves back to the same 203.0.113.5.

When all three line up, the IP is "forward-confirmed" and receivers treat it as far more trustworthy. To check this, reverse-look-up your mail server's IP here to get the PTR hostname, then run that hostname through the A Record Lookup and confirm it returns the original IP. If the PTR is missing, generic, or points at a name whose A record does not match, ask your hosting provider to set the correct reverse DNS for the IP. Pair this with healthy SPF, DKIM and DMARC for the best inbox placement.