Reverse DNS lookup

How this tool works

When you open the page, the tool runs the lookup for the address you are connecting from. Enter any other IPv4 or IPv6 address to look it up instead.

Reverse DNS works through a special part of the DNS tree. For an IPv4 address the server reverses the 4 octets and appends in-addr.arpa; for IPv6 it reverses the 32 hexadecimal nibbles and appends ip6.arpa. The resulting name is queried for a PTR record, and the value of that record is the hostname. The exact name that was queried is shown in the result so you can repeat it with your own tools.

The query goes through our server's resolver first. If that resolver cannot answer, the server asks a public DNS-over-HTTPS resolver for the same PTR name, so a missing answer is far more likely to mean there is no record than a resolver problem.

When a hostname comes back, the tool does a second step: it resolves that hostname forward to its A and AAAA records and checks whether the original address is among them. The result is marked forward-confirmed when it is. This is the check mail servers call FCrDNS, and it is the difference between a name someone typed into a PTR record and a name that genuinely belongs to the address.

The tool also looks up which autonomous system announces the address and shows its number and name, because the network tells you as much about an IP as the hostname does. Private and reserved addresses such as 192.168.x.x or 10.x.x.x are recognized and not queried, since they have no meaning on the public internet.

PTR answers are cached for 10 minutes. There is no sign-up and the lookup is free; lookups of addresses other than your own are rate-limited per visitor.

How to read the result

Hostname found and forward-confirmed. The address has a PTR record and the name resolves back to the same address. This is what a well-run mail server, web server or ISP connection looks like.

Hostname found, not confirmed. The PTR record exists but the hostname points at a different address or at nothing. The name may be stale, or the owner set a PTR without a matching forward record. Mail from such an address often fails strict checks even though a PTR exists.

Hostname found, forward check unavailable. The PTR value could not be resolved at all. Treat it like an unconfirmed name.

No hostname. No PTR record is published. This is the normal state of many consumer connections and of cloud servers whose owners never set one. On its own it is not a sign of abuse, but mail sent directly from such an address will be rejected by most receivers.

Read the hostname itself for clues. Names such as 203-0-113-45.dyn.example-isp.net follow a pattern that embeds the address and marks the pool as dynamic, which usually means a residential IP handed out to subscribers. Names like mail.example.com or vps-12345.hosting.example identify a specific machine. A hostname that ends in a cloud provider's domain tells you the address is a datacenter IP regardless of what the PTR says before it.

The network line beneath the hostname shows the ASN and organization. Compare it with the hostname: an address whose PTR claims to be a bank's mail server but sits in a hosting provider's network deserves suspicion.

How to set or fix reverse DNS

Only the party that controls the address block can publish PTR records; you cannot set one from inside your own DNS zone.

For a cloud or dedicated server

1. Find the PTR setting in the provider's control panel. It is usually labeled reverse DNS, rDNS or PTR and sits next to the server's network settings or in the IP address list.
2. Enter the hostname you want, for example mail.example.com, as a fully qualified name.
3. Before saving, make sure the forward record exists: mail.example.com must already have an A (or AAAA) record pointing at this exact address, otherwise the name will not be forward-confirmed.
4. Wait for the provider to publish the record, then verify here. Some providers apply it within minutes, others on an hourly schedule.
5. For a mail server, set the hostname your mail software announces in its HELO or EHLO greeting to the same name. Receivers compare all three.

For an IPv6 address

The same steps apply, but the provider's panel may require you to delegate the reverse zone of your prefix to your own name servers rather than entering a single record. If you were given a /64 or larger, ask the provider whether they support reverse zone delegation.

For a home or office connection

ISPs generally do not customize PTR records for consumer connections. If you need a forward-confirmed hostname for outbound mail, either send through the ISP's or a third-party relay, or use a business plan with a static address, where PTR changes are usually offered.

Checking from your own computer

dig -x 203.0.113.45 on macOS or Linux, or nslookup 203.0.113.45 on Windows, performs the same PTR query against your own resolver. dig -x also works for IPv6 addresses and builds the ip6.arpa name for you.

Why reverse DNS matters

Mail delivery is the main reason anyone sets a PTR record. Receiving servers look up the sending address before accepting a message, and an address without a hostname, or with a hostname that does not resolve back, is a strong spam signal. Combined with a blacklist check and correct SPF and DKIM records, forward-confirmed reverse DNS is one of the basics of getting mail delivered.

Logging and troubleshooting is the second reason. Server logs, traceroutes and firewall reports that show hostnames instead of bare addresses are far quicker to read, which is why ISPs and transit networks name their router interfaces. The hostnames you see in a traceroute come from exactly these PTR records.

For anyone checking a proxy or VPN before using it, the PTR record is one more signal that is easy to inspect. A connection that is supposed to look like a home user but whose address resolves to a hosting provider's naming scheme will be classified as a datacenter connection by any service that bothers to look.

Reverse DNS for whole blocks and for IPv6

For a single address the provider enters the PTR record for you. For a whole block, providers often delegate the reverse zone to the customer's own name servers, so that the customer manages PTR records for every address in the block like any other zone. An IPv4 /24 maps to one reverse zone of the form 113.0.203.in-addr.arpa. Smaller blocks, such as a /29, cannot be delegated directly because the reverse tree is organized by octet; providers handle them with a classless delegation that uses CNAME records pointing into a zone the customer controls. If your block's PTR records are missing or wrong and you believe you control them, check whether the delegation from the provider actually exists by querying the NS records of the reverse zone with the DNS lookup.

IPv6 reverse zones are built from the 32 hexadecimal nibbles of the address, reversed, under ip6.arpa; a /64 maps to a zone with 16 nibble labels, and a /48 to one with 12. Delegation works the same way as for IPv4 but is simpler, because every common prefix length falls on a nibble boundary. Most providers delegate the reverse zone of an IPv6 prefix on request rather than entering individual records.

Limits of this tool

• A missing PTR record is reported as no hostname. The tool cannot tell whether the block owner chose not to publish one or whether the reverse zone is simply broken.
• Forward confirmation checks A and AAAA records of the PTR hostname only. A hostname that is a CNAME alias is followed by the resolver, but unusual configurations may show as unconfirmed.
• A PTR record can contain any text the block owner chooses. The hostname is a claim, and only the forward-confirmed flag and the network information make it a verified claim.
• The tool returns the first PTR record. A small number of addresses publish several; the others are not listed.
• Answers are cached for 10 minutes, so a PTR change made moments ago may not show immediately.
• Private, loopback and reserved addresses are not looked up.
• Reverse DNS reveals nothing about the person using an address; it identifies at most the machine or the pool the address belongs to. For location and network type, use the IP lookup.