Reverse DNS Action Brief
{{ alignmentFigure }}
{{ summaryLine }}
{{ overallVerdict.label }} {{ rows.length }} IP{{ rows.length === 1 ? '' : 's' }} {{ publicIssueCount }} public issue{{ publicIssueCount === 1 ? '' : 's' }} {{ expectedMismatchCount }} expected-host mismatch{{ expectedMismatchCount === 1 ? '' : 'es' }} {{ canonicalIssueCount }} alias/hostname warning{{ canonicalIssueCount === 1 ? '' : 's' }} {{ resolverDriftBadge }} {{ resolverSummaryBadge }}
Last run: {{ lastRunLocal }}
Examples: 203.0.113.10, 2001:db8::10, mail.example.com, or postmaster@mail.example.com.
Auto tries Cloudflare, Google, then Quad9; fixed choices keep reruns comparable.
Enter mail.example.com, example.com for suffix, or =mail.example.com for exact only.
Enable for mail reputation, allow-listing, or identity evidence.
{{ fcrdnsBool ? 'On' : 'Off' }}
Use when a multi-PTR address cannot contain any stale or weak name.
{{ require_all_ptr_matchBool ? 'On' : 'Off' }}
Enable for single-name reverse zones or mail relay audits.
{{ strict_ptrBool ? 'On' : 'Off' }}
Use for RFC-style PTR hygiene before treating the name as evidence.
{{ enforce_canonical_ptrBool ? 'On' : 'Off' }}
Adds a Resolver Drift tab when public recursive views disagree.
{{ compare_resolversBool ? 'On' : 'Off' }}
Use 0 for no cap, or a whole-number ceiling for expanded host checks.
IPs
Choose 1 to 16 parallel checks; lower it for cautious public-resolver runs.
workers
Use 0 for no extra timeout, or milliseconds in 100 ms steps.
ms
Category Field Value Detail Copy
{{ row.category }} {{ row.field }} {{ row.value }} {{ row.value }} {{ row.detail }}
# IP Verdict PTR evidence FCrDNS Expected Scope Reason Notes Copy
{{ idx + 1 }}
{{ row.ip }}
{{ row.reverseName }}
 {{ row.status }}
{{ row.ptrCount }} PTR{{ row.ptrCount === 1 ? '' : 's' }}
{{ row.ptrDisplay }}
{{ formatTtl(row.ptrTtl) }} TTL · {{ row.reverseQueryMs }} ms
{{ fcrdnsLabel(row.fcrdns) }} {{ row.expectedLabel }} {{ row.scopeLabel }} {{ row.primaryReasonLabel }} {{ row.note }}
Path IP Host / answer Status Evidence Note Copy
{{ row.path }} {{ row.ip }} {{ row.host }} {{ row.status }} {{ row.evidence }} {{ row.note }}
# IP Consensus Cloudflare Google Quad9 Notes Copy
{{ idx + 1 }}
{{ row.ip }}
{{ row.reverseName }}
 {{ row.consensus }} {{ row.cloudflareDisplay }} {{ row.googleDisplay }} {{ row.quad9Display }} {{ row.note }}
# Check Status Notes Copy
{{ idx + 1 }} {{ c.label }} {{ c.status }} {{ c.note || '-' }}
No PTR health mix data is available for this run. 

  




        

    

                

                

                    

                        

                            Tags: DNS, Diagnostics, Networking, Security
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                    

                

                

                    

                                                    

                                
                            

                                                    

                                
                            

                                                    

                                
                            

                                                    

                                
                            

                                            

                

            

        
                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    
    
Reverse DNS maps an IP address back to a hostname with a PTR record. That matters when you are checking mail identity, troubleshooting a reverse-zone change, confirming that a public address has a stable name, or trying to explain why one resolver sees a clean answer while another still does not.

    
This page accepts a literal IPv4 or IPv6 address, a hostname, a URL, or an email-style host reference. If you start with a hostname, it extracts the host part, resolves the visible A and AAAA answers, and then audits each returned IP separately. That makes the result far more useful for dual-stack services, pools of outbound mail relays, and any hostname that can hide more than one reverse-DNS outcome.


    

      
        
        
          
            
          
        
        
          
          Input
          IP, host, URL,
          or email host

          
          Host expansion
          A and AAAA

          
          Reverse name
          in-addr.arpa
          or ip6.arpa

          
          PTR answers
          chosen resolver

          
          Forward check
          A and AAAA
          round-trip

          
          Policy layer
          expected host,
          alias, strict PTR

          
          Resolver drift
          Cloudflare,
          Google, Quad9

          
          Results
          brief, paths,
          checks, exports

          
          
          
          
          
          
          
        
      
      
A hostname can fan out to several addresses, so the audit keeps each IP separate instead of collapsing everything into one verdict.

    


    
Each evaluated IP goes through the same chain: build the reverse lookup name, ask the selected public DNS-over-HTTPS resolver for PTR answers, optionally resolve those PTR hostnames forward again, and then apply policy checks such as expected-host matching, single-PTR warnings, alias detection, and cross-resolver comparison. The output is split into an Action Brief, per-IP results, lookup paths, optional resolver drift, roll-up checks, and structured exports.

    
The report and exports are assembled in your browser, but the DNS lookups themselves are still sent to third-party resolvers. If you enable resolver comparison, PTR queries are repeated through Cloudflare, Google Public DNS, and Quad9. If you use Use my IP, the page asks api.ipify.org for your current public address. A clean result means the reverse and forward naming relationship is consistent under the selected rules. It does not prove sender reputation, service reachability, TLS validity, or general host trust.

  






  

    
Technical Details

    
IPv4 reverse DNS lives under in-addr.arpa. IPv6 reverse DNS lives under ip6.arpa and uses the fully expanded address as reversed hexadecimal nibbles. When the input is not already an IP literal, the page first extracts a host value from the pasted text, strips URL and mailbox decoration, normalizes the name to ASCII, and resolves the visible A and AAAA answers before any reverse lookup begins.

    
Forward-confirmed reverse DNS, often shortened to FCrDNS, is a stronger test than PTR existence alone. The page resolves each PTR hostname back to A and AAAA records and checks whether the original IP appears in that forward set. By default, one matching PTR hostname is enough to satisfy the round-trip check. The stricter every-PTR option changes that rule so every returned PTR hostname must resolve back to the same IP.


    

      
        
          PTRhosts
          =
          PTR
          
            (
            reverse
            (
            IP
            )
            )
          
        
      
      
        
          FCrDNSany
          =
          PASS iff
          
          ∃
          h
          ∈
          PTRhosts
          
          such that
          
          IP
          ∈
          
            A
            (
            h
            )
            ∪
            AAAA
            (
            h
            )
          
        
      
      
        
          FCrDNSall
          =
          PASS iff
          
          ∀
          h
          ∈
          PTRhosts
          ,
          
          IP
          ∈
          
            A
            (
            h
            )
            ∪
            AAAA
            (
            h
            )
          
        
      
    


    

      

        
        
          

            Setting
            What it checks
            Why you would turn it on
          

        
        
          

            Forward-confirmed reverse DNS
            Requires at least one PTR hostname to resolve back to the original IP.
            Useful when you care about a believable naming round-trip, not just the existence of a PTR record.
          

          

            Require every PTR host to round-trip
            Turns the default any-match rule into an all-match rule.
            Useful when every published reverse name must be safe to present as identity evidence.
          

          

            Strict single PTR
            Warns when an IP has anything other than exactly one PTR hostname.
            Useful when you want one stable reverse name rather than a wider PTR set.
          

          

            Expected PTR host or suffix
            Checks each PTR hostname against an exact host or a suffix rule. Prefix the value with = for exact-match only.
            Useful when you already know the reverse name you intended to publish.
          

          

            Warn when PTR target is an alias
            Looks for CNAME answers on PTR hostnames and flags them as canonical-host warnings.
            Useful when you want PTR records to point straight at a real host name rather than an alias chain.
          

          

            Compare reverse answers across resolvers
            Runs extra PTR lookups through Cloudflare, Google Public DNS, and Quad9, then labels the result as AGREE, PARTIAL, or DIFF.
            Useful after recent DNS changes or when different users report different reverse-lookup answers.
          

        
      

    


    
The hostname warnings go beyond a simple PTR yes or no. Returned PTR targets are normalized to ASCII and checked for empty labels, labels longer than 63 characters, a name longer than 253 characters, leading or trailing hyphens, characters outside letters, digits, and hyphens, and an all-numeric final label. Those warnings do not automatically mean the reverse zone is broken, but they do tell you the published hostname is weak evidence for policy, logging, or mail identity work.


    

      

        
        
          

            Observed condition
            Status
            Primary reason
          

        
        
          

            No PTR answer on a public IP
            FAIL
            Missing public PTR
          

          

            No PTR answer on a private, loopback, link-local, documentation, or other non-public IP
            WARN
            Scoped IP without PTR
          

          

            PTR exists but the hostname returns no forward A or AAAA answers
            FAIL
            PTR host has no A/AAAA
          

          

            Forward answers exist, but none include the original IP
            FAIL
            Forward mismatch
          

          

            Only some PTR hostnames round-trip when every PTR host is required to match
            FAIL
            Not every PTR host round-trips
          

          

            More than one PTR hostname is returned while strict single PTR is enabled
            WARN
            Multiple PTR hostnames
          

          

            The PTR hostname misses the expected host rule, points at an alias, or uses a weak hostname format
            WARN
            Unexpected PTR hostname, PTR points at alias, or PTR hostname warning
          

        
      

    


    
Scale controls matter when a hostname resolves widely. Max IPs limits how many resolved addresses are audited, with 0 meaning no extra cap. Concurrency is bounded from 1 to 16 workers. Timeout adds an extra per-request timer, and 0 leaves that timer disabled. CSV, DOCX, and JSON exports are generated from the finished browser-side result set rather than from a separate backend pass.

  






  

    
Everyday Use & Decision Guide

    
Start with the simplest question you actually need answered. If you already know the exact IP that matters, check the literal address first. If you are investigating a host that may publish several A or AAAA records, use the hostname so the page can keep each IP on its own row. That separation is often the difference between finding the bad address quickly and missing it inside a hostname-level summary.

    
Keep forward confirmation on when the reverse name is supposed to represent a real identity. That is especially useful for mail servers, allow-list review, abuse investigations, and any workflow where a PTR record should describe the same host you would reach through a forward lookup. Turn it off only when your first question is narrower, such as "does any PTR exist at all?" The page will still show the PTR evidence, but it will label forward confirmation as intentionally skipped rather than quietly pretending the round-trip passed.


    

      

        
        
          

            Situation
            Good starting setup
            Why it helps
          

        
        
          

            Known public mail sender IP
            Literal IP, FCrDNS on, expected host rule if you know the intended name
            Shows whether the PTR exists, whether it round-trips, and whether it matches the published mail identity you expected.
          

          

            Hostname behind several IPv4 or IPv6 addresses
            Hostname input, default round-trip rule, optional Max IP cap
            Keeps one weak address from disappearing inside a hostname that mostly looks healthy.
          

          

            Fresh reverse-DNS change or mixed user reports
            Enable resolver comparison and keep an eye on TTL and latency
            Helps distinguish authoritative change timing from stale or uneven recursive-cache views.
          

          

            Internal, private, or lab address
            Check the IP, but read missing PTR as context unless your own private DNS should provide it
            Non-public ranges often do not publish public reverse DNS, so the real question may be local naming policy instead.
          

        
      

    


    
The expected-host rule is one of the most useful controls when you know what the reverse name should be. Enter mail.example.com to accept that exact host or anything under that suffix. Enter =mail.example.com when only that one exact hostname is acceptable. This is a practical way to catch PTR records that are technically present but still not pointing where you meant them to.

    
Strict single PTR is a policy choice, not a universal law. Some environments only care that one valid PTR hostname round-trips. Others want one canonical reverse name per IP because that is easier to reason about in logs, mail checks, and support handoffs. The alias warning sits in the same category. A PTR record can exist and still point at a hostname that answers with CNAME, which may be good enough for some internal work but weak evidence for cleaner public policy checks.

    
Use the scale controls deliberately. A large hostname plus resolver comparison can create many DNS requests quickly. If you only need a first-pass answer, cap the IP list, keep concurrency moderate, and add a timeout so one slow resolver does not stall the whole review. If you are trying to document a subtle issue after a recent DNS change, accept the longer run and keep the extra evidence.

  






  

    
Step-by-Step Guide

    
    
      
  1. Enter an IP, hostname, URL, or email-style host reference. Use Use my IP only when you want to audit your current public address.
    2. 
      
  2. Choose a resolver profile. Auto tries Cloudflare first, then Google Public DNS, then Quad9. A fixed resolver is better when you want a stable evidence path for repeated checks.
    3. 
      
  3. Leave forward-confirmed reverse DNS enabled if you care about round-trip identity. Turn on the every-PTR rule only when every published PTR hostname must point back to the same IP.
    4. 
      
  4. Add an expected PTR host or suffix if you know what name should appear. Prefix the value with = for exact-match only.
    5. 
      
  5. Enable strict single PTR, alias warnings, or resolver comparison only when those policy questions matter for your case.
    6. 
      
  6. Set Max IPs, Concurrency, and Timeout if the hostname may resolve broadly or if you want to limit resolver pressure.
    7. 
      
  7. Run the check and read the Action Brief first, then the IP Results table, then Lookup Paths for any row that needs explanation.
    8. 
      
  8. Use the Checks, Resolver Drift, CSV, DOCX, and JSON outputs when you need a handoff-ready record rather than a one-off answer.
    9. 
    

  






  

    
Interpreting Results

    
The Action Brief is the fastest way to understand the run. It turns the completed rows into a summary line, verdict badges, counts for public issues, expected-host mismatches, alias or hostname warnings, and a short list of follow-up suggestions. That is the triage view. The real evidence still lives in the row-by-row outputs.


    

      

        
        
          

            Surface
            What it answers
            Best use
          

        
        
          

            IP Results
            Did this specific IP pass, warn, or fail, and what was the main reason?
            Start here for the authoritative row-level verdict, PTR evidence, FCrDNS state, expected-host result, scope, and note.
          

          

            Lookup Paths
            Which PTR hostnames were returned, what forward IPs they resolved to, and whether an alias or hostname warning appeared?
            Use this when you need to explain exactly why a row failed or why only one of several PTR hostnames round-tripped.
          

          

            Resolver Drift
            Do Cloudflare, Google Public DNS, and Quad9 show the same PTR set for the same reverse name?
            Use this after recent reverse-zone changes or whenever different recursive views may explain inconsistent reports.
          

          

            Checks
            How did the full batch perform on public PTR coverage, FCrDNS, strict single PTR, expected-host alignment, resolver agreement, and scoped-address context?
            Use this as a roll-up summary for tickets, change review, or post-incident notes.
          

          

            JSON
            What exact settings, notices, rows, checks, recommendations, and resolver-drift data were generated?
            Use this when you need a machine-readable snapshot of the entire run.
          

        
      

    


    
Read row status and FCrDNS together. A row can have a PTR record and still fail because the PTR hostname has no forward A or AAAA records, or because the forward answer exists but points somewhere else. That distinction matters. "PTR host has no A/AAAA" usually means the named host itself is incomplete. "Forward mismatch" means the host resolves, but not back to the IP you started with.

    
The Expected and Scope columns help prevent overreading. MISS under Expected means the PTR is present but not aligned to the hostname rule you provided. A non-public scope label means the address belongs to a private, loopback, link-local, documentation, carrier-NAT, multicast, or reserved range, so missing public reverse DNS should be read more cautiously. The page still shows the absence. It simply does not treat every non-public address like a broken public sender.

    
Resolver drift is not automatic proof that one resolver is wrong. AGREE means the visible PTR sets match. PARTIAL means at least one resolver returned no PTR answers while another did, or all of them were empty. DIFF means the visible PTR answer sets actually differ. That usually points to cache age, recent changes, or inconsistent authoritative data and is a good reason to verify the authoritative reverse zone directly.

    
The Checks tab does not run a second audit. It summarizes the rows you already have. That means a PASS there is only as trustworthy as the underlying row evidence and resolver view. A clean batch is useful, but it still does not prove the host is reputable, that mail will be accepted everywhere, or that the service itself is healthy.

  






  

    
Worked Examples


    
A public mail IP with clean naming

    
Check a known sending IP with forward confirmation enabled and an expected host such as =mail.example.com. A strong result is one PTR hostname, a PASS on FCrDNS, MATCH on the expected host rule, and no alias warning. That is the clean reverse-name pattern many mail operators want before they start debugging delivery elsewhere.


    
A hostname that hides mixed quality across several addresses

    
Enter a hostname that resolves to several IPv4 and IPv6 answers. One row may show a clean PTR and round-trip match, while another shows no PTR at all or a forward mismatch. Keeping the results split by IP is what turns a vague hostname complaint into a concrete address-level fix list.


    
A recent reverse-zone change with stale recursive views

    
Enable resolver comparison after updating PTR records. Cloudflare and Google Public DNS might already show the new hostname while Quad9 still returns the older answer set, producing a DIFF or PARTIAL drift result. In that situation, the real next step is not another blind DNS edit. It is to verify the authoritative reverse zone and wait for recursive caches to converge.


    
A private or lab address during internal troubleshooting

    
Check a private IPv4 address or an IPv6 link-local address during a lab review. The row may warn about missing PTR, but the scope label reminds you that public reverse DNS is often absent for these ranges. If your organization runs private reverse zones, that warning still matters. If not, it is a context note rather than evidence that a public-facing DNS zone is broken.

  






  

    
FAQ:


    

      Does this page query authoritative nameservers directly?
      
No. It queries the selected public recursive DNS-over-HTTPS resolver, and the resolver-comparison view repeats the PTR lookup through the built-in public resolver set.

    


    

      Why can a row pass when more than one PTR hostname is returned?
      
Because the default round-trip rule only needs one PTR hostname to resolve back to the original IP. Turn on Require every PTR host to round-trip if that is too loose for your case, and turn on Strict single PTR if you want exactly one PTR hostname.

    


    

      What does the leading = mean in the expected host field?
      
It forces an exact hostname match. Without the leading equals sign, the field accepts the exact hostname or any PTR hostname under that suffix.

    


    

      Why is a PTR target flagged as an alias?
      
Because the PTR hostname answered with CNAME data instead of behaving as a canonical host name with its own direct address records. That can still resolve, but it is weaker naming evidence and is specifically discouraged in long-standing DNS operational guidance.

    


    

      What data leaves the browser during a check?
      
The entered host or IP, the reverse lookup name built from it, and any follow-up PTR hostnames are sent to the selected public resolver. If you enable resolver comparison, the PTR lookup is also sent to Cloudflare, Google Public DNS, and Quad9. The optional Use my IP button sends a request to api.ipify.org to learn your public address.

    

  






  

    
Glossary:

    

      
PTR record

      
A DNS record used for reverse lookup, mapping an IP address back to a hostname.


      
Reverse zone

      
The DNS namespace used for reverse lookups, such as in-addr.arpa for IPv4 and ip6.arpa for IPv6.


      
Forward-confirmed reverse DNS

      
A check that confirms a PTR hostname also resolves forward to the same original IP address.


      
Canonical host

      
A hostname that carries its own direct address records rather than pointing elsewhere through CNAME.


      
Resolver drift

      
A difference in visible PTR answers across public recursive resolvers, usually caused by cache age, transport issues, or inconsistent authoritative data.


      
Scoped address

      
A private, loopback, link-local, documentation, carrier-NAT, multicast, reserved, or other non-public address whose public reverse-DNS expectations are different from a public IP.

    

  






  

    
References: