Reverse DNS (PTR) Checker

Introduction:

Reverse host records connect a numeric network address back to a hostname, giving other systems a human friendly label for where that address is supposed to live. A reverse name lookup for email deliverability is often used to spot misconfigurations that can trigger filtering or confusing log entries. When everything lines up, the address and name tell a consistent story.

You provide either a single numeric address or a hostname, and the checker returns the reverse name it finds, plus a simple status and a reason you can act on. If you start with a hostname, it first looks up the addresses behind it, then validates each one. That makes it handy for services that sit behind multiple addresses.

Imagine you are bringing up a new mail server on a hosted address and messages are landing in spam. You can confirm that the address points to mail.example.com, and that the same name points back to that address. If those two directions disagree, receivers may treat the sender as suspicious or simply misfile it.

A clean result only proves that records are internally consistent at the moment you query them, not that the host is trustworthy or even reachable. Changes can take time to propagate, so run the check again after updates and avoid pasting sensitive internal names.

Technical Details:

Reverse Domain Name System (DNS) lookups use the PTR (pointer) record to map an Internet Protocol (IP) address to a hostname. That mapping is commonly checked for mail servers, logging, and security controls because it helps confirm that a name and address pair is consistent.

Beyond checking that a PTR answer exists, the tool can perform forward-confirmed reverse DNS (FCrDNS). In that mode, each PTR hostname is resolved back to A (IPv4 address) and AAAA (IPv6 address) records, and at least one of those answers must include the original IP.

The per-address result is summarized as PASS, WARN, or FAIL, along with a machine-friendly reason string and a human note. A separate Scoped flag highlights private, link-local, or carrier-scoped ranges where public reverse records often do not exist.

What is measured and how it is interpreted

The check focuses on three observable facts and one context signal. First, whether a PTR record exists for the IP. Second, how many distinct PTR hostnames are returned. Third, when FCrDNS is enabled, whether any returned PTR hostname resolves forward to the same IP. Finally, whether the IP falls into a private or scoped range where missing reverse records are expected.

In practice, a passing result means the reverse hostname exists and the forward records agree with it when forward confirmation is enabled. A warning usually indicates a policy preference rather than a hard break, such as multiple PTR hostnames when strict mode is enabled, or running without forward confirmation. A failing result indicates a missing reverse record, an invalid reverse lookup name, or a forward mismatch when forward confirmation is required.

Core processing pipeline

1. Clean the input and extract a hostname or literal address.
2. If a hostname, resolve it to A and AAAA addresses.
3. Apply the Max IPs cap if one is set.
4. For each address, build its reverse zone name.
5. Look up PTR answers with the selected resolver.
6. If forward confirmation is enabled, resolve each PTR name back to A and AAAA.
7. Mark PASS, WARN, or FAIL, and record a reason and note.

Symbols and units

Result bands

A Scoped value of Yes should be read as context, since public reverse records are often absent for those ranges.

Validation and bounds from the implementation

Input and output formats

Networking and storage behavior

The checker performs DNS lookups from the browser using DNS-over-HTTPS requests to a selected public resolver provider. The request uses a JSON response format and includes a per-request abort timer when a nonzero timeout is configured. In Auto mode, the tool tries Cloudflare first and only falls back to Google when the first request fails at the network level.

No local or session storage is used by the provided code, and all results are held in memory for the current page view.

Performance and determinism

For each IP, the check performs one PTR lookup and, when forward confirmation is enabled, up to two forward lookups per PTR hostname. With N IPs and M PTR hostnames per IP, the worst-case query count is approximately N × (1 + 2M), plus up to two initial lookups when the input is a hostname.

Results are deterministic for identical DNS responses, but DNS caching, resolver policy, and propagation delays can make repeated runs differ across time and networks.

Security considerations

• Hostnames and reverse-zone names are sent to the selected resolver provider as part of the lookup.
• The input parser strips common wrappers like mailto:, URLs, paths, ports, and email local parts.
• A passing FCrDNS result does not prove that a host is safe, only that records align.
• High concurrency can trigger resolver throttling, leading to timeouts and false negatives.
• Use caution when checking targets you do not control, especially in restricted environments.

Assumptions and limitations

• PTR validity indicates consistency, not ownership, authorization, or service health.
• FCrDNS passes if any PTR hostname maps back to the original IP, not necessarily all of them.
• Strict single PTR mode treats multiple PTR hostnames as a warning rather than an automatic failure.
• When forward confirmation is disabled, the per-row status can be WARN even if PTR is missing.
• Heads-up Auto resolver fallback occurs only on network failure, not on DNS errors like NXDOMAIN.
• Private and scoped detection covers common ranges but does not enumerate every reserved block.
• IPv6 parsing is permissive and may accept unusual text forms that resolvers reject.
• Timeout 0 disables the extra abort timer, and the browser still applies its own limits.
• Max IPs caps hostname expansion, which can hide issues on skipped addresses.
• Forward lookups collect unique strings from answers, and non-address answers do not contribute to a match.

Edge cases and error sources

• Hostnames with a trailing dot are normalized by removing the final dot.
• Inputs that are full URLs are parsed and reduced to their hostname component.
• Email style inputs are reduced to the domain after the last @.
• IPv6 zone identifiers like %eth0 are ignored when building the reverse name.
• Compressed IPv6 forms using :: are expanded before nibble reversal.
• PTR answers may contain quoted segments, which are dequoted and concatenated.
• Multiple PTR answers are deduplicated, so ordering can change across runs.
• Resolvers can return empty Answer arrays with nonzero status, which appears the same as no records.
• Resolver throttling can surface as timeouts that mimic missing PTR or forward records.
• Internationalized hostnames are coerced toward ASCII when URL parsing succeeds.
• Heads-up A resolver view can differ from authoritative servers due to caching and filtering.
• Browsers without AbortController support ignore the extra timeout setting.

Scientific and standards backing

Reverse name lookups and PTR records are part of the IETF DNS specifications, including the definitions of A, AAAA, and PTR record types. DNS-over-HTTPS is also defined in an IETF specification that describes how DNS messages can be carried over HTTPS. For IPv4 and IPv6 reverse mapping, the in-addr.arpa and ip6.arpa zones describe how addresses are mapped into reverse query names.

Privacy and compliance

This page sends lookup queries to the selected resolver provider and does not include any server-side storage in the provided code. Avoid entering confidential internal hostnames if resolver logging is a concern.

Step-by-Step Guide:

Use reverse name checks to confirm that an address, its reverse hostname, and its forward records agree.

1. Enter a IP or hostname you want to verify.
2. If you are checking mail delivery, keep Forward-confirmed rDNS enabled.
3. Enable Strict single PTR when you expect exactly one reverse hostname.
4. When a hostname expands to many addresses, tune Max IPs to control coverage.
5. Adjust Concurrency and Timeout if lookups are slow or throttled.
6. Review the per-address rows, then read the aggregated checks for a quick summary.

• Start with Auto resolver, then switch providers if results are inconsistent.
• If you see a scoped warning, verify the address is meant to be publicly routable.
• After updating records, recheck from more than one network to account for caching.

Pro tip: when investigating intermittent issues, save the JSON report from a good run and compare it with a later failure.

Features:

• Accepts IPv4, IPv6, and hostnames, and can extract hostnames from URLs and email style inputs.
• Resolves hostnames to A and AAAA records before checking PTR for each resulting IP.
• Optional FCrDNS validation verifies that the reverse hostname resolves forward to the original IP.
• Strict single PTR mode highlights IPs with multiple reverse hostnames.
• Flags private, link-local, and carrier-scoped addresses where public reverse records are unlikely.
• Exports results as CSV, DOCX, or JSON for sharing and ticketing.

FAQ:

Troubleshooting:

• No A/AAAA records found: verify the hostname spelling and that public address records exist.
• Missing PTR: request reverse DNS setup from your hosting or transit provider.
• PTR hostnames did not resolve: ensure the PTR target has matching A or AAAA records.
• Forward mismatch: update the forward records, the PTR record, or both to align.
• Limited analysis notice: increase Max IPs or set it to 0 to check all returned addresses.
• Timeouts or slow checks: increase timeout, lower concurrency, or try the other resolver provider.

Advanced Tips:

• Tip Use strict single PTR only when your policy truly requires one reverse name per IP.
• Tip Treat scoped addresses as expected warnings when testing from private networks.
• Tip For multi-IP hostnames, set Max IPs to 0 during audits to avoid missing outliers.
• Tip Lower concurrency first when you suspect resolver throttling or rate limits.
• Tip Compare results across resolvers when debugging propagation or split-horizon configurations.
• Tip Save JSON outputs from known-good states to create a baseline for future regressions.

Glossary:

Reverse DNS (rDNS)

Looking up a hostname from an IP address using DNS.

PTR record

DNS record type that maps an IP address to a hostname.

FCrDNS

Forward-confirmed rDNS where forward records include the original IP.

A record

DNS record type that maps a hostname to an IPv4 address.

AAAA record

DNS record type that maps a hostname to an IPv6 address.

Scoped address

Private, link-local, or carrier-scoped IP range.

in-addr.arpa

Reverse mapping zone used for IPv4 addresses.

ip6.arpa

Reverse mapping zone used for IPv6 addresses.