Multi-Region PTR DNS Propagation Checker

Test PTR DNS propagation across multiple worldwide DNS servers in North America, Europe, Asia, and Oceania.

Quick select:
Countries:
Select at least one country.
Your IP: 216.73.216.246
Domain Type Primary NS Responsible Person Serial Refresh Retry Expire Minimum TTL
Name Server IP Address TTL
Domain Type TTL Record Value
Trace Result
Domain Type Record Status
Domain Type Record Status

PTR (Reverse DNS) Propagation Checker

A PTR record is the reverse of an A record: it maps an IP address back to a hostname. Reverse lookups use their own zones, in-addr.arpa for IPv4 and ip6.arpa for IPv6, with the address written in reverse order.

Enter an IP address rather than a domain name. The checker builds the reverse name, finds the name servers responsible for that reverse zone and asks them for the PTR from eight regions.

Who Controls Reverse DNS

The reverse zone belongs to whoever holds the IP block. That is normally your hosting company, cloud provider or ISP, not the company that hosts your domain's DNS. This is why you cannot set a PTR in your usual DNS panel. Look for a reverse DNS or rDNS setting in your server provider's control panel, or ask their support to set it.

Why PTR Matters for Email

Receiving mail servers look up the PTR of every IP that connects to them. Gmail and Yahoo require sending IPs to have valid forward and reverse DNS, and many other mailbox providers treat mail from an IP without a PTR as suspicious. The PTR hostname should also resolve back to the same IP through an A record. This match is called forward-confirmed reverse DNS.

Reading PTR Results

The same hostname everywhere

Reverse DNS is set and published. Next, confirm that the hostname's A record returns this same IP.

No record in every region

No PTR has been set for this address. Ask the provider that owns the IP to add one that uses a hostname under your own domain.

A generic provider hostname

Many providers set a default PTR built from the IP digits. It resolves, but spam filters often treat such names like home connections. Replace it with a clear name for your mail server.

The old hostname in some regions

The provider's reverse name servers are out of step. This normally settles within their TTL. If it does not, only the IP owner can fix it, so raise it with them.

How This Check Works

Eight Regions Across Six Continents

Every check is run from South Asia (Mumbai), Southeast Asia (Singapore), East Asia (Tokyo), the Middle East (Dubai), Europe (London), North America (N. Virginia), South America (São Paulo) and Oceania (Sydney). Each location reports on its own, so one slow or unreachable region never hides the results from the others.

Response Time and Fastest Region

Each region asks the authoritative name servers directly and times only that one exchange. Authoritative servers do not answer from a cache, so every figure is a fresh lookup from that part of the world. The Fastest Region in the summary panel is the lowest of those times in the current check.

Ticks, Crosses and the Map

A green tick means the region received an answer and shows it. A red cross means it got none; hover the marker to see why, such as NXDOMAIN, a timeout or no record of that type. The world map below the results marks each region with its outcome, so you can tell whether a problem is limited to one continent.

Global Propagation Troubleshooting & Common Fixes

After migrating to a new server or hosting provider, some global locations resolve the new IP while others return the old address. When authoritative nameservers answer with conflicting data, it usually means secondary (slave) nameservers have not received zone updates due to delayed AXFR/IXFR zone transfers, firewall restrictions, or an unchanged SOA serial number.

How to fix: Inspect your domain's SOA Record to verify that the serial number has incremented on all authoritative nameservers. If you manage your own BIND or PowerDNS cluster, force a zone notification and reload across all secondary nameservers. If using a managed cloud DNS provider, confirm that all assigned nameservers show identical zone versions.

When six or seven regions return green checkmarks with valid responses, but one region (such as São Paulo, Sydney, or Dubai) displays a red cross or connection timeout, this indicates regional packet loss, firewall geo-blocking, or routing blackholes between that region's network and your authoritative nameservers.

How to fix: Verify that your DNS provider or firewall does not geo-block specific countries or ASN IP ranges on UDP and TCP port 53. If using anycast DNS (Cloudflare, AWS Route 53, NS1), this can indicate a localized routing flap at a specific regional point of presence (PoP). Check your DNS provider's status page for regional degradation.

Seeing different IP addresses across North America, Europe, and Asia is frequently expected behaviour rather than an error. Modern Content Delivery Networks (Cloudflare, Fastly, Akamai) and cloud load balancers use latency-based routing, Geo-DNS, or Anycast BGP to deliver traffic to the nearest geographic edge node.

How to fix: If you use a CDN, WAF, or geo-routing policy, disparate IP addresses confirm that geographic traffic steering is functioning correctly. If you do not use a CDN and only own a single web server, check whether an erroneous round-robin A record was accidentally left configured in your DNS management console.

Check Another Record Type

DNS Info extension for Chrome is now available

Install