rDNS · PTR · IP TO HOST

rDNS Check

Run a reverse DNS (rDNS) check: resolve any IPv4 or IPv6 address back to its hostname via PTR records.

~/pingie - rdns-check
ready

Provide an IPv4 or IPv6 address to look up its PTR hostname.

The toolkit

Every network tool you'll ever need.

Purpose-built utilities for ports, IPs, DNS and email. Completely free, all powered by external probes.

What is an rDNS check and how does it work?

An rDNS check resolves an IP address back to a hostname by querying a PTR record in the DNS system. This is the reverse of a normal A record lookup, which maps a hostname to an IP. When you enter an IP address, the tool constructs a special reverse lookup domain, for example 1.0.168.192.in-addr.arpa for the IPv4 address 192.168.0.1, and queries the DNS for the PTR record stored there.

For IPv6 addresses, each nibble of the expanded address is reversed and appended to .ip6.arpa . The result is the hostname (or hostnames) that the IP owner has registered. PTR records are set by whoever controls the IP address block, typically an ISP or hosting provider, not the domain owner.

Why reverse DNS matters for servers and email

Many mail servers perform a reverse DNS lookup on the connecting IP before accepting a message. If no PTR record exists, or if the hostname does not resolve back to the original IP, the message may be rejected or flagged as spam. This bidirectional check is called Forward-Confirmed Reverse DNS (FCrDNS).

Beyond email, reverse DNS helps you verify server identity, investigate unfamiliar IPs in logs, and confirm that a hosting provider has correctly configured your dedicated IP. It is also a common step when auditing network infrastructure.

  • Verify that a mail server IP has a valid PTR record before sending bulk email
  • Investigate suspicious IPs appearing in access logs or firewall alerts
  • Confirm FCrDNS alignment: the PTR hostname must resolve back to the same IP
  • Audit hosting or VPS setups where reverse DNS is configured separately from forward DNS
  • Check whether a cloud or residential IP even has a PTR record (many do not)

How to use pingie's reverse DNS lookup tool

The tool accepts any valid IPv4 or IPv6 address and returns the associated PTR record hostnames. No account or registration is needed.

  1. Open the Reverse DNS Lookup tool from the menu.
  2. Enter an IPv4 or IPv6 address in the input field.
  3. Click Lookup . The tool queries PTR records and displays the associated hostname or hostnames.

If no PTR record is found, the tool reports that result clearly. This outcome is common for cloud instances and residential connections, where ISPs do not configure reverse DNS by default.

Understanding the results of a dns reverse search

A successful lookup returns one or more hostnames mapped to the IP. A single IP can technically have multiple PTR records, though this is uncommon in practice. The hostname you see is whatever the IP owner registered in the reverse DNS zone.

To confirm FCrDNS, take the returned hostname and run a forward DNS lookup on it. If the A or AAAA record points back to the original IP, the configuration is forward-confirmed. Mail servers and some spam filters require this match. If the forward lookup returns a different IP, the PTR record exists but FCrDNS fails.

When PTR records are missing or misconfigured

Not every IP address has a PTR record. Cloud providers often assign IPs without configuring reverse DNS unless the customer requests it. Residential ISPs typically assign generic PTR records like pool-123-45-67-89.provider.net . These generic records are often treated as a negative signal by spam filters.

If you manage a mail server and your PTR record is missing or generic, contact your hosting provider or ISP and request a custom reverse DNS entry. The PTR hostname should match the HELO/EHLO domain your mail server announces. You can also check your sending IP against known blocklists using the IP Blacklist Checker to get a fuller picture of deliverability risk.

Related tools for deeper network investigation

Reverse DNS is one piece of a broader diagnostic workflow. Depending on what you are investigating, these tools complement a PTR lookup:

FAQ

An A record maps a hostname to an IP address. A PTR record does the opposite: it maps an IP address to a hostname and lives in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) DNS zone. The two records are independent. A PTR record can point to any hostname, and that hostname does not have to have an A record pointing back to the same IP, though Forward-Confirmed Reverse DNS requires that match.

PTR records are managed by whoever controls the IP address block, which is usually your ISP or hosting provider. Unlike A or MX records, you cannot set a PTR record through your domain registrar or DNS host. You must contact the provider that assigned the IP and request a custom reverse DNS entry. Most managed hosting providers offer a self-service field in their control panel for this purpose.

Many IP addresses have no PTR record at all. Cloud providers, residential ISPs, and shared hosting environments frequently skip reverse DNS configuration unless explicitly requested. The absence of a PTR record is not an error in the DNS system itself. It simply means the IP owner has not published one. For mail servers, this missing record is a problem because receiving servers often require it as a basic spam check.

FCrDNS means the PTR hostname for an IP resolves back to that same IP in a forward DNS lookup. For example, if 203.0.113.5 has a PTR record pointing to mail.example.com , and a DNS query for mail.example.com returns 203.0.113.5, the configuration is forward-confirmed. Many mail servers and spam filters treat FCrDNS as a trust signal. A PTR record that does not resolve forward, or resolves to a different IP, fails this check and can hurt email deliverability.

A standard DNS lookup takes a domain name and returns its IP address by querying A or AAAA records. A reverse DNS lookup takes an IP address and returns a hostname by querying PTR records in the in-addr.arpa or ip6.arpa zones. The two lookups are independent and use completely separate DNS zones. Having a valid A record does not automatically create a PTR record, and vice versa.

Yes. For IPv6, the tool expands the address to its full 32-nibble form, reverses the nibbles, and appends .ip6.arpa to construct the reverse lookup domain. This is the standard mechanism defined in RFC 3596. IPv6 PTR records are even less commonly configured than IPv4 ones, so a missing result for an IPv6 address is expected in many cases.

Technically yes, DNS allows multiple PTR records for a single IP. In practice this is uncommon and can cause problems with mail servers that expect exactly one PTR record. Some spam filters treat multiple PTR records as a misconfiguration. If the tool returns more than one hostname for your IP, review your reverse DNS settings with your hosting provider and consolidate them to a single, accurate record.

Reverse DNS is one layer of email authentication. A valid PTR record is a baseline requirement for many receiving mail servers. For a complete deliverability audit, you should also verify your DKIM signature with the DKIM Checker and confirm your DMARC policy is published correctly. Each of these checks addresses a different part of the email authentication chain. PTR covers the sending IP; DKIM and DMARC cover the domain identity.

Pingie does not store the IP addresses you submit for lookup beyond what is needed to process the query. For full details on data handling, see the privacy policy . The lookup itself queries public DNS infrastructure, so the PTR query passes through DNS resolvers as any normal DNS request would.

PTR records propagate according to their TTL (time to live) value, just like any other DNS record. Most providers set TTLs between 300 and 3600 seconds. After your hosting provider updates the record, resolvers around the world will cache the old value until the TTL expires. In practice, full global propagation typically takes between a few minutes and a few hours depending on the TTL and resolver caching behavior.

Sometimes yes. Many large providers configure PTR records that include their brand name or infrastructure identifiers, for example ec2-54-12-34-56.compute-1.amazonaws.com . This gives a clue about the IP owner. For more detail on who controls an IP block, use the ASN Lookup tool, which identifies the autonomous system and registered organization behind any IP address.

No. A valid PTR record is a necessary baseline for many mail servers, but it is not sufficient on its own. Receiving servers also evaluate DKIM signatures, DMARC policy, SPF alignment, sending reputation, and whether the IP appears on blocklists. A correct PTR record removes one common rejection reason. It does not override a poor sending reputation or a missing DKIM signature.