Guides /DNS
DNS

Reverse DNS Lookup: What It Is and When It Matters for Email

December 6, 20256 min readHostBible Team

A standard (forward) DNS lookup resolves a domain name to an IP address. Reverse DNS does the opposite: given an IP address, it returns the hostname associated with that IP. It's primarily used for email authentication, server identification in logs, and network diagnostics. For anyone running a mail server on a VPS or dedicated server, reverse DNS is not optional, it's a requirement for reliable email delivery.

How Reverse DNS Works Technically

Reverse DNS uses a special zone in the DNS namespace called in-addr.arpa (for IPv4) and ip6.arpa (for IPv6). To look up the hostname for the IPv4 address 198.51.100.42, the resolver queries 42.100.51.198.in-addr.arpa. Notice the IP octets are reversed, this is how the in-addr.arpa hierarchy mirrors the IP allocation hierarchy.

PTR records (Pointer records) are the DNS record type used for reverse lookups. A PTR record maps an IP address (in its reversed arpa notation) to a hostname. They are the reverse counterpart of A records: where an A record says "this hostname resolves to this IP," a PTR record says "this IP resolves to this hostname."

Why It Matters for Email

When your mail server sends an email, the receiving mail server often performs a reverse DNS lookup on the IP address of the connecting server. It then does a forward lookup on the returned hostname to confirm it resolves back to the same IP. This double-check, IP resolves to hostname, hostname resolves back to same IP, is called Forward-Confirmed Reverse DNS (FCrDNS) or a "PTR check".

Mail servers use this check as a basic legitimacy signal. Servers with no PTR record, or a PTR that doesn't match the forward record, are more likely to be spam sources (spammers typically operate on IP ranges without proper PTR configuration). As a result, missing or mismatched reverse DNS is a common cause of legitimate emails being marked as spam or rejected outright.

Major receiving systems that perform PTR checks include Microsoft 365, Gmail (for SMTP delivery from external servers), and most enterprise mail gateways. The exact weight given to PTR checks varies, but a missing PTR for a mail server sending IP is an unnecessary deliverability risk.

Who Controls PTR Records

This is the key operational point: PTR records are controlled by whoever owns the IP address block, not by the domain owner. Unlike A, MX, or TXT records which you manage in your domain's DNS zone, PTR records live in the reverse zone managed by your hosting provider or ISP.

You cannot add a PTR record for your server's IP through your domain registrar or DNS zone. You need to request it from the entity that allocated the IP, your hosting provider.

  • Dedicated servers and VPS: most providers allow you to set a custom PTR record through the control panel or by contacting support. Set it to your mail server's fully qualified domain name (e.g. mail.yourdomain.com).
  • Shared hosting: the PTR record points to the host's server hostname, which is normal. Shared hosting uses the provider's outbound mail infrastructure with its own PTR configuration, not the individual customer's IP.

What the PTR Record Should Be

The PTR record for your mail server's sending IP should match the hostname your mail server announces in its EHLO/HELO command during SMTP. This is typically your mail server's fully qualified hostname. The forward A record for that hostname should resolve back to the same IP.

Example of a correctly configured PTR chain:

# PTR record (set by hosting provider):
42.100.51.198.in-addr.arpa   PTR   mail.yourdomain.com
# Forward A record (in your DNS zone):
mail.yourdomain.com   A   198.51.100.42

The IP resolves to mail.yourdomain.com, and mail.yourdomain.com resolves back to the same IP. This is forward-confirmed.

How to Check a PTR Record

Check the reverse DNS for an IP using dig:

dig -x 198.51.100.42 +short

Or using nslookup on Windows:

nslookup 198.51.100.42

The response should show a PTR record resolving to your mail server's hostname. If it returns nothing, a generic ISP hostname (like static.198.51.100.42.example-isp.net), or an unrelated hostname, you need to request the PTR record be updated by your hosting provider.

To verify the forward-confirmed check (that the hostname resolves back to the same IP):

# First get the PTR hostname
dig -x 198.51.100.42 +short
# Then confirm it resolves back to the same IP
dig mail.yourdomain.com A +short

IPv6 Reverse DNS

IPv6 uses the ip6.arpa zone rather than in-addr.arpa. The IPv6 address is reversed nibble by nibble (each hex character) with dots between each character. For example, the IPv6 address 2001:db8::1 requires a PTR at 1.0.0.0...8.b.d.0.1.0.0.2.ip6.arpa. Most hosting providers handle this automatically when you request a PTR record, you provide the IPv6 address and desired hostname, they configure the reverse zone.

PTR Records Beyond Email

Reverse DNS appears in several other contexts:

  • Server logs: web server access logs can resolve visitor IPs to hostnames using reverse DNS. Useful for identifying traffic sources.
  • Network diagnostics: traceroute output uses PTR records to show hostnames for each hop in the network path.
  • Security tools: intrusion detection and SIEM systems use reverse DNS to add context to IP addresses seen in logs.
  • Abuse identification: hosting providers and network operators use PTR records when investigating abuse reports.

Professional email that actually lands in inboxes

HostBible's email infrastructure is configured with correct PTR records, SPF, DKIM, and DMARC. Business email hosting with full deliverability from day one.

View Professional Email