DNS PTR Record: Reverse Lookups Explained

A PTR (Pointer) record is the reverse of an A record. While an A record maps a domain name to an IP address, a PTR record maps an IP address back to a domain name. This reverse mapping is called a reverse DNS lookup, and it serves a different purpose than the forward lookups most people are familiar with.

PTR records are most commonly used for email authentication, network diagnostics, and security logging. If you run a mail server, having a correct PTR record is not optional. Without one, many receiving mail servers will reject your messages outright. For a broader overview of DNS record types, see DNS Record Types Explained.

How Reverse DNS Works

Forward DNS works by looking up a domain name to find an IP address. The query "what is the IP address of mail.example.com?" returns something like 93.184.216.34.

Reverse DNS works in the opposite direction. The query "what domain name is associated with 93.184.216.34?" returns something like mail.example.com.

This reverse lookup uses a special domain: in-addr.arpa for IPv4 addresses and ip6.arpa for IPv6 addresses. The IP address is reversed and appended to this special domain to form the lookup query.

For the IP address 93.184.216.34, the reverse DNS lookup queries:

34.216.184.93.in-addr.arpa.    IN    PTR    mail.example.com.

The octets of the IP address are reversed (34.216.184.93 instead of 93.184.216.34) because DNS is hierarchical from right to left. Reversing the octets means the most significant network portion is queried first, matching how DNS delegation works.

For IPv6 addresses, each hexadecimal digit is separated and reversed. The PTR lookup for 2001:0db8:85a3::8a2e:0370:7334 would query a long string of individual hex digits under ip6.arpa.

Why PTR Records Matter

Email Deliverability

This is the primary reason most people care about PTR records. When your mail server sends an email to another mail server, the receiving server often performs a reverse DNS lookup on the connecting IP address. If the PTR record does not exist or does not match the sending server's hostname, the receiving server may:

• Reject the email outright
• Flag it as spam
• Assign it a lower trust score

Major email providers including Gmail, Outlook, and Yahoo all check PTR records as part of their spam filtering. Google's email sender guidelines explicitly state that sending IPs should have valid PTR records that resolve back to the sending hostname.

The check works in both directions (called forward-confirmed reverse DNS, or FCrDNS):

1. The receiving server looks up the PTR record for the sending IP: 93.184.216.34 resolves to mail.example.com.
2. The receiving server then does a forward lookup on mail.example.com and checks that it resolves back to 93.184.216.34.
3. If both directions match, the check passes.

If either direction fails, the sending server looks suspicious. Legitimate mail servers have PTR records that match. Spammers and compromised machines often do not.

Network Diagnostics

Network administrators use reverse DNS lookups to identify servers and devices in log files. An IP address like 93.184.216.34 is not immediately meaningful, but mail.example.com tells you what the server is and who owns it.

Tools like traceroute perform reverse DNS lookups on each hop to show hostnames alongside IP addresses, making network paths easier to read and troubleshoot.

Security and Access Control

Some services use reverse DNS as part of their access control. SSH servers can be configured to verify that connecting IP addresses have valid PTR records. Web application firewalls may use reverse DNS to help identify traffic sources.

This is a weak form of verification (PTR records can be set by whoever controls the IP address space) but adds one more data point for security decisions.

Checking PTR Records

Using dig

# Reverse lookup using dig
dig -x 93.184.216.34

# Short output
dig -x 93.184.216.34 +short

The -x flag tells dig to perform a reverse lookup. It automatically constructs the in-addr.arpa query from the IP address.

Using nslookup

nslookup 93.184.216.34

Nslookup automatically detects that you have provided an IP address and performs a reverse lookup.

Using host

host 93.184.216.34

The host command also auto-detects IP addresses and returns the PTR record. For more lookup methods, see How to Check DNS Records and the dig Command Guide.

Setting Up PTR Records

Unlike most DNS records, PTR records are not managed through your domain's DNS provider. They are managed by whoever controls the IP address space, which is typically your hosting provider or ISP.

For Dedicated Servers and VPS

If you have a dedicated server or VPS with a static IP address, your hosting provider usually gives you a control panel option to set the PTR record. Look for "Reverse DNS," "rDNS," or "PTR record" in your hosting provider's dashboard.

Common hosting providers and where to find PTR settings:

• DigitalOcean: The droplet's name is automatically used as the PTR record. Rename the droplet to your mail server's hostname.
• AWS EC2: Use the "Request to Remove Email Sending Limitations" form, then set the PTR through the Elastic IP settings.
• Linode/Akamai: Under the "Network" tab for your Linode, edit the "Reverse DNS" field.
• Hetzner: In the server's network settings, click on the IP address to set the PTR record.
• Vultr: Under the server's "Settings" tab, find "Reverse DNS."

For Cloud Email Services

If you use a cloud email service (Google Workspace, Microsoft 365, Amazon SES), the PTR records for the sending IP addresses are managed by the email provider. You do not need to set them yourself. The provider ensures their sending infrastructure has valid PTR records.

For Shared Hosting

On shared hosting, you share an IP address with other websites. The PTR record for that IP is controlled by the hosting provider and typically points to a generic hostname. You cannot change it. This is one reason why shared hosting is not ideal for running your own mail server.

PTR Records and SPF/DKIM/DMARC

PTR records work alongside other email authentication mechanisms but serve a different purpose.

SPF (Sender Policy Framework) specifies which IP addresses are authorized to send email for your domain. SPF records can include a ptr mechanism, but its use is officially discouraged (RFC 7208) because it requires the receiving server to perform additional DNS lookups and can fail unpredictably.

DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify email authenticity. It operates independently of PTR records.

DMARC (Domain-based Message Authentication) ties SPF and DKIM together with a policy. It does not directly use PTR records.

PTR records complement these mechanisms. A valid PTR record is necessary but not sufficient for good email deliverability. You need all four (PTR, SPF, DKIM, DMARC) working together. For details on the email authentication trio, see SPF, DKIM, and DMARC DNS.

Common PTR Record Problems

Missing PTR record. The IP address has no PTR record at all. This is the most common issue and the most damaging for email deliverability. Contact your hosting provider to set one up.

Mismatched PTR and A record. The PTR record for 93.184.216.34 points to mail.example.com, but mail.example.com resolves to a different IP address. This fails the forward-confirmed reverse DNS check.

Generic PTR record. The PTR record points to a generic hostname assigned by the hosting provider, like 34.216.184.93.static.provider.net. This is technically valid but looks like a server that has not been properly configured, which some spam filters penalize.

PTR pointing to a non-existent domain. The PTR record references a domain that does not exist or has no A record. The forward confirmation check fails because the hostname cannot be resolved.

Multiple PTR records. While technically allowed by the DNS specification, having multiple PTR records for the same IP address can cause unpredictable behavior. Some resolvers return the first record; others return a random one. Use a single PTR record per IP address.

PTR Records for IPv6

IPv6 PTR records work the same way as IPv4 but use the ip6.arpa domain instead of in-addr.arpa. The IPv6 address is expanded to its full form, each hexadecimal digit is reversed and separated by dots.

For the IPv6 address 2001:0db8:85a3:0000:0000:8a2e:0370:7334, the PTR query is:

4.3.3.7.0.7.3.0.e.2.a.8.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.

Setting up IPv6 PTR records follows the same process as IPv4: contact your hosting provider or use their control panel to set the reverse DNS for your IPv6 address.

As IPv6 adoption grows, having PTR records for your IPv6 addresses becomes increasingly important, especially for mail servers that send over IPv6.

References

1. RFC 1035, "Domain Names - Implementation and Specification," November 1987. https://datatracker.ietf.org/doc/html/rfc1035
2. RFC 8482, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY," January 2019. https://datatracker.ietf.org/doc/html/rfc8482
3. Google, "Email sender guidelines," Google Workspace Admin Help. https://support.google.com/a/answer/81126
4. RFC 7208, "Sender Policy Framework (SPF)," April 2014. https://datatracker.ietf.org/doc/html/rfc7208