Reverse DNS lookup: check the PTR record for any IP

A regular DNS lookup turns a name into an address: you ask for dns.google and get back 8.8.8.8. Reverse DNS (rDNS) runs the same question backwards. You start with the IP and ask which name it goes by.

The answer lives in a PTR record (short for pointer). DNS can only look up names, so the IP gets rewritten into one. For IPv4 the four numbers are reversed and put under in-addr.arpa, so 8.8.8.8 becomes 8.8.8.8.in-addr.arpa and 209.85.220.41 becomes 41.220.85.209.in-addr.arpa. For IPv6 every hex digit of the full address is reversed and dotted under ip6.arpa, which is why IPv6 PTR names run to 32 labels. The tool above shows the exact name it queried.

A PTR on its own proves very little, because whoever controls an IP can point its PTR at any name they like. So receivers do a second step called forward-confirmed reverse DNS (FCrDNS): look up the A or AAAA record of the PTR hostname and check that it lists the original IP. That only works if the IP owner and the hostname's owner agree, which is what makes it a useful trust signal.

Every operating system can do a reverse lookup without a website. On macOS and Linux, dig has a shortcut that builds the in-addr.arpa name for you:

The first command is the reverse lookup and the second is the forward confirmation. If both line up, FCrDNS passes. On Windows, or anywhere dig is missing, a reverse nslookup works the same way when you give it an IP:

To query the PTR record type directly, use dig PTR 41.220.85.209.in-addr.arpa. If you get NXDOMAIN or an empty answer, there is no PTR for that address.

When a mail server connects to Gmail or Outlook, the first thing the receiver knows is the connecting IP. Before it reads a single header, it looks up that IP's PTR and checks whether the name resolves back. Google's email sender guidelines list it as a requirement for all senders: "Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records." Microsoft, Yahoo, and most corporate spam filters behave the same way.

What a failing check looks like in practice: no PTR at all usually means a temporary deferral or an outright 550 rejection. A PTR that doesn't resolve back gets treated about the same. A PTR that looks like a home connection (something like 203-0-113-7.dyn.example-isp.net) passes FCrDNS but still gets scored like a residential IP, which is where botnets send from.

For cold email this is rarely the problem, because you send through Google or Microsoft mailboxes whose IPs are set up correctly. The records you do control are SPF, DKIM, and DMARC on each sending domain, which our email deliverability checker tests. The full picture, from authentication to warmup and volume, is in our guide to email deliverability for cold email, and the mailbox and domain providers we use are compared in cold email infrastructure.

This trips up a lot of people. Your domain's DNS host (Cloudflare, GoDaddy, Route 53 for your domain, whoever holds your A and MX records) can't create a PTR for your server's IP. The reverse zone for an IP belongs to whoever was allocated that IP block, so the PTR has to be set by them:

Pick a hostname you control, such as mail.yourcompany.com, give it an A or AAAA record pointing at the IP, then ask for the PTR to match. That hostname should also be what your server says in its SMTP greeting (HELO or EHLO).

If you send from Google Workspace or Microsoft 365, you don't set or check reverse DNS. Mail leaves from Google's or Microsoft's IPs, and their PTRs and forward records are already in place (try 209.85.220.41 above, a Google outbound IP). The same goes for SendGrid, Mailgun, Postmark, Amazon SES, and the other ESPs on their shared pools, and for sequencers like Instantly or Smartlead, which send through the mailboxes you connect. Reverse DNS becomes your job only when you run Postfix or Exchange on your own server, or pay for a dedicated IP.