How to check ptr record

Run nslookup 98.88.64.13 8.8.8.8, which asks for the PTR record at 13.64.88.98.in-addr.arpa. Then resolve the name it returns and confirm the address comes back. Reverse DNS is delegated with the address block, so the answer is set by whoever owns the address, not by the domain owner.

Why check this

Run this before the first production mail leaves a new host, and again after any move that changes the sending address: a new region, a new NAT gateway, a lift onto a different cloud account. The failure it prevents is a rejection at connection time, before any of your SPF or DKIM work is read. A receiver that requires a PTR closes the session with a 5xx, and the application logs a delivery error with no mention of DNS.

The check is also the fastest way to find out who actually controls the address you are sending from. A PTR that names your hosting provider and not your domain means the record is theirs to set, and no edit in your own zone will change it.

Prerequisites

• The sending address. For a mail server this is the address the SMTP connection comes from, which can differ from the address the MX name resolves to.
• nslookup. Passing a bare address performs the reverse lookup. The explicit form is -type=PTR against the in-addr.arpa name.
• RFC 1035 section 3.5 for how an address is written as a name: the four octets reversed, then in-addr.arpa.

Steps

1. 1

   Step 1.

   Read the reverse name of one address, both ways round.

   nslookup 98.88.64.13 8.8.8.8
   

   Server:  dns.google
   Address:  8.8.8.8
   
   Name:    ec2-98-88-64-13.compute-1.amazonaws.com
   Address:  98.88.64.13

   The explicit form nslookup -type=PTR 13.64.88.98.in-addr.arpa 8.8.8.8 returns the same record and shows the name the query really used: the octets in reverse order under in-addr.arpa.

2. 2

   Step 2.

   Run the round trip from a domain, not from an address. Save this as rdns.js and run node rdns.js github.com, then node rdns.js httpbin.org.

   const { Resolver } = require('node:dns');
   const r = new Resolver();
   r.setServers(['8.8.8.8']);
   const name = process.argv[2];
   const p = (fn, arg) => new Promise((d) => r[fn](arg, (e, v) => d(e ? e.code : v)));
   (async () => {
     const addrs = await p('resolve4', name);
     if (typeof addrs === 'string') return console.log(`${name}  A ${addrs}`);
     for (const ip of addrs) {
       const ptr = await p('reverse', ip);
       if (typeof ptr === 'string') { console.log(`${ip.padEnd(16)} PTR ${ptr}`); continue; }
       const back = await p('resolve4', ptr[0]);
       console.log(
         `${ip.padEnd(16)} PTR ${ptr[0]}\n` +
         `${''.padEnd(16)}     A(${ptr[0]}) = ${typeof back === 'string' ? back : back.join(',')}\n` +
         `${''.padEnd(16)}     forward-confirmed: ${Array.isArray(back) && back.includes(ip)}   names the domain: ${ptr[0].endsWith(name)}`
       );
     }
   })();
   

   140.82.121.3     PTR lb-140-82-121-3-fra.github.com
                      A(lb-140-82-121-3-fra.github.com) = 140.82.121.3
                      forward-confirmed: true   names the domain: true
   
   18.235.200.183   PTR ec2-18-235-200-183.compute-1.amazonaws.com
                      A(ec2-18-235-200-183.compute-1.amazonaws.com) = 18.235.200.183
                      forward-confirmed: true   names the domain: false
   98.88.64.13      PTR ec2-98-88-64-13.compute-1.amazonaws.com
                      A(ec2-98-88-64-13.compute-1.amazonaws.com) = 98.88.64.13
                      forward-confirmed: true   names the domain: false
   …

   Both hosts pass the round trip that starts at the address. Only the first passes the round trip that starts at the domain. github.com resolves to an address whose PTR is a github.com name. httpbin.org resolves to addresses whose PTR is a generic EC2 name that says nothing about the domain. That second shape is ordinary for shared infrastructure and disqualifying for a mail sender.

3. 3

   Step 3.

   Read an address that has no PTR at all.

   nslookup 172.66.147.243 8.8.8.8
   

   *** dns.google can't find 172.66.147.243: Non-existent domain
   Server:  dns.google
   Address:  8.8.8.8

   This is one of the addresses example.com resolves to. Non-existent domain here means the in-addr.arpa name does not exist, not that the address is unreachable. A web host in this state is fine. A mail sender in this state is rejected by receivers that require a PTR.

4. 4

   Step 4.

   Find out who controls the record by reading the delegation of the reverse zone.

   nslookup -type=NS 64.88.98.in-addr.arpa 8.8.8.8
   

   Non-authoritative answer:
   Server:  dns.google
   Address:  8.8.8.8
   
   64.88.98.in-addr.arpa	nameserver = ns4-24-us-east-1.ec2-rdns.amazonaws.com
   64.88.98.in-addr.arpa	nameserver = ns1-24-us-east-1.ec2-rdns.amazonaws.com
   64.88.98.in-addr.arpa	nameserver = ns3-24-us-east-1.ec2-rdns.amazonaws.com
   64.88.98.in-addr.arpa	nameserver = ns2-24-us-east-1.ec2-rdns.amazonaws.com
   
   121.82.140.in-addr.arpa	nameserver = dns4.p06.nsone.net
   121.82.140.in-addr.arpa	nameserver = dns2.p06.nsone.net
   121.82.140.in-addr.arpa	nameserver = dns1.p06.nsone.net
   121.82.140.in-addr.arpa	nameserver = dns3.p06.nsone.net

   The second block is the same query for 121.82.140.in-addr.arpa, the range behind github.com. One reverse zone is served by the cloud vendor, the other by the address holder's own DNS provider. That difference is the whole story of who can change the PTR.

How to read the result

| What you see | What it means | What to do | | --- | --- | --- | | A name that ends in your domain | The PTR names the sender, and forward confirmation passes | Nothing | | A generic provider name such as ec2-…compute-1.amazonaws.com | The address block is the provider's and the PTR is theirs | Ask the provider to set it, or send through a host that has one | | Non-existent domain on a reverse query | No PTR exists for the address | Required before production mail. Harmless for a web host | | forward-confirmed: false | The PTR name resolves somewhere else | Fix whichever of the two records is wrong. Receivers discard the pair | | The reverse zone is delegated to a cloud vendor | You cannot edit this record in your own zone | Use the vendor's console or support path | | A PTR that names the host but not the HELO name | The receiver's check compares the HELO name too | Align the HELO name, the PTR and the forward record |

Common mistakes

What to check next

• How to check mx records: the inbound side of the same setup, and the targets that need addresses.
• How to check SPF record: the other sender check, evaluated after the connection is accepted.
• How to check a record of domain: the forward half of every round trip on this page.
• How to check ns record: delegation read the same way, for a forward zone.
• How to check dns records: the full inventory when more than the PTR moved.

FAQ

How to check reverse dns?

Pass the address to nslookup with a resolver after it: nslookup 8.8.8.8 8.8.8.8. On PowerShell, Resolve-DnsName 8.8.8.8 -Type PTR. On Linux, host 8.8.8.8. All three build the same in-addr.arpa name and ask for a PTR.

How to check ptr record nslookup style, with the type spelled out?

nslookup -type=PTR 13.64.88.98.in-addr.arpa 8.8.8.8. Reverse the four octets of the address and append in-addr.arpa. For IPv6 the name is built from the 32 nibbles in reverse under ip6.arpa.

How to check reverse dns for mail server?

Check the address the SMTP connection originates from, then run both round trips from step 2. The record should resolve back to the same address and should name a host under your own domain, matching the name the server gives in its HELO.

Can one address have two PTR records?

It can, and receivers disagree on how to read that. Some take the first, some try each, some treat several as a misconfiguration. Publish one PTR per address.

Why does the PTR show my hosting provider?

Because the address block is theirs. Step 4 reads the delegation of the reverse zone and shows it pointing at the provider's nameservers. Only the holder of that block can change the record.

Verified