DNS Records & Concepts
What is a PTR record?
A PTR record, Pointer record, is a DNS record that maps an IP address to a domain name. It is the reverse of an A record: where 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 what makes PTR records the foundation of reverse DNS lookups, the process of finding the domain name associated with a known IP address.
The practical applications of PTR records are specific and important. Email servers use PTR records to verify that the IP address a message is sent from has a legitimate domain name associated with it, a basic check that filters out much spam and helps legitimate email reach the inbox. Network administrators use PTR records for logging, monitoring, and troubleshooting, displaying domain names rather than raw IP addresses in network logs makes them far more readable. Security tools use reverse DNS to identify the operators of IP addresses during incident response and threat analysis.
PTR records are configured differently from other DNS records. While A records, CNAME records, and MX records are configured in the zone managed by the domain owner, PTR records are configured in special reverse DNS zones managed by whoever controls the IP address block, typically an internet service provider, cloud provider, or hosting company. Domain owners cannot configure PTR records unilaterally, they must request them from whoever controls the IP addresses they use.
How a PTR record works
Reverse DNS uses a special domain structure to make IP address lookups work within the standard DNS infrastructure. Rather than creating an entirely separate system for reverse lookups the DNS designers reused the existing zone hierarchy with a special reserved domain, in-addr.arpa for IPv4 and ip6.arpa for IPv6.
To look up the domain name for the IPv4 address 93.184.216.34 a DNS resolver constructs a special query name by reversing the octets of the IP address and appending in-addr.arpa:
The resolver queries DNS for a PTR record at this name. The authoritative nameserver for the 93.in-addr.arpa zone, which is managed by whoever controls the 93.x.x.x IP block, returns the PTR record containing the domain name associated with that IP address.
The IP address octets are reversed in the query name because DNS delegation flows from left to right, from most general to most specific. The in-addr.arpa zone contains delegations for the first octet blocks. Each first-octet zone contains delegations for second-octet blocks. And so on down to individual IP addresses. Reversing the octets puts the most general part, the first octet, at the left, matching the direction DNS delegation flows.
For IPv6 the same principle applies but with individual hexadecimal digits reversed and ip6.arpa appended. The IPv6 address 2001:db8::1 becomes 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa: each hexadecimal digit reversed and separated by dots.
PTR records and email deliverability
Email deliverability is the most important practical application of PTR records for most domain and server administrators. Mail servers check PTR records as part of their spam filtering and sender verification process, and the results directly affect whether legitimate email reaches the inbox or is rejected.
The forward-confirmed reverse DNS check: the most common email-related PTR check is forward-confirmed reverse DNS, also called FCrDNS. When a receiving mail server gets an incoming email connection it performs two lookups. First it looks up the PTR record for the connecting server’s IP address to get the associated hostname. Then it looks up the A record for that hostname to get its IP address. If the A record IP address matches the connecting IP address the PTR record is forward-confirmed, the domain claims to be hosted at that IP and the IP address claims to be associated with that domain.
A successful FCrDNS check does not guarantee the email is legitimate but it establishes a basic level of accountability, the sender controls both the domain name and the IP address, creating a traceable identity. Failing the FCrDNS check is a significant negative signal, many mail servers reject or heavily filter email from IP addresses with no PTR record or with a PTR record that does not forward-confirm.
Impact on spam scores: missing PTR records, generic PTR records assigned by ISPs, like 93-184-216-34.isp.example.net: and PTR records that do not forward-confirm all increase spam scores in email filtering systems. SpamAssassin and similar tools assign points for these conditions that can push otherwise clean email over the rejection threshold.
Major provider requirements: Google, Microsoft, and other major email providers have published guidance or requirements around PTR records for sending servers. Google’s Postmaster Tools documentation notes that sending servers should have valid PTR records. Microsoft’s email deliverability guidance makes similar recommendations. Meeting these requirements is increasingly important for bulk email senders and transactional email services.
Who controls PTR records
Unlike most DNS records that domain owners configure in their own DNS zones PTR records are controlled by whoever manages the IP address block, not by whoever manages the domain name. This is the fundamental difference that makes PTR records more complex to configure than other record types.
ISP-managed IP blocks: for small businesses and individuals with IP addresses assigned by an internet service provider the ISP controls the reverse DNS zone. To set a PTR record the domain owner must contact the ISP and request that the PTR record be configured. Most ISPs provide a process for this, a support request, a control panel option, or an API, but it requires actively asking rather than being able to configure it directly.
Dedicated IP address blocks: larger organisations that have obtained their own IP address blocks from a regional internet registry, ARIN, RIPE, APNIC, control their own reverse DNS zones and can configure PTR records directly.
Cloud providers: major cloud providers including AWS, Google Cloud, Azure, and DigitalOcean allow customers to configure PTR records for IP addresses allocated to their instances. AWS allows PTR records to be set through the EC2 console for Elastic IP addresses. DigitalOcean sets PTR records based on the hostname configured for a droplet. The process varies by provider but is generally available through the provider’s management interface.
Cloudflare and CDN providers: domains proxied through Cloudflare have their traffic served from Cloudflare’s IP addresses rather than the origin server’s IP addresses. PTR records for Cloudflare’s IP addresses point to Cloudflare’s infrastructure rather than to the customer’s domain. This is expected behaviour for proxied domains, the PTR record reflects the CDN infrastructure, not the ultimate destination.
PTR records and redirect management
PTR records have an indirect relationship with redirect management. They do not affect how HTTP redirects function, a PTR record has no influence on 301 redirects, 302 redirects, or any other redirect type. However they interact with redirect infrastructure in several ways worth understanding.
Email functionality on redirect domains: many domains connected to redirect management infrastructure also send transactional email, confirmation messages, notification emails, system alerts. If the email is sent from the same IP address as the redirect infrastructure the PTR record for that IP address affects email deliverability. Redirect management platforms using shared IP infrastructure typically have PTR records pointing to the platform’s own infrastructure rather than to individual customer domains, which may be sufficient for basic email but suboptimal for high-volume sending.
Redirect infrastructure identification: when network administrators or security tools perform reverse DNS lookups on the IP addresses of redirect management infrastructure they see the PTR records configured for those addresses. Well-managed redirect platforms configure meaningful PTR records for their infrastructure IP addresses, making the platform identifiable rather than appearing as an anonymous IP address.
Post-migration email configuration: when migrating a domain from one hosting provider to another as part of a redirect management setup the email sending IP addresses may change. If the old hosting provider’s IP addresses had correctly configured PTR records but the new infrastructure does not email deliverability may decline after the migration. Verifying PTR records for email sending infrastructure should be part of any migration checklist.
PTR records in IPv6
PTR records for IPv6 addresses follow the same conceptual approach as IPv4 but with a more complex format due to IPv6’s longer address structure.
An IPv6 address like 2001:0db8:0000:0000:0000:0000:0000:0001 is fully expanded to all 32 hexadecimal digits, reversed digit by digit, and separated by dots with ip6.arpa appended:
This PTR record lookup returns the domain name associated with that IPv6 address.
IPv6 PTR records are managed in the same way as IPv4, by whoever controls the IP address block. Cloud providers and ISPs that have deployed IPv6 typically offer the same PTR record configuration options for IPv6 addresses as they do for IPv4.
As IPv6 adoption grows configuring PTR records for IPv6 addresses becomes increasingly important for email deliverability from IPv6-capable mail servers. A server that sends email from an IPv6 address without a PTR record may face deliverability issues from mail servers that check for reverse DNS on IPv6 connections.
Checking PTR records
PTR records are checked using the same DNS tools as other record types but with the reversed IP address format.
dig command, IPv4: on Linux and macOS:
The -x flag automatically constructs the reversed query name in in-addr.arpa format. Returns the PTR record for the specified IP address.
Without the -x shorthand the equivalent explicit query is:
dig command, IPv6: the -x flag works for IPv6 as well:
nslookup: on Windows and other platforms:
nslookup automatically performs a reverse lookup when given an IP address rather than a domain name.
Online reverse DNS tools: web-based tools perform reverse DNS lookups and show PTR records alongside other network information about an IP address. MXToolbox and similar email deliverability tools provide reverse DNS checks alongside other email-related DNS checks.
Forward-confirming the PTR record: after checking the PTR record perform the forward confirmation manually to verify the FCrDNS check passes. Look up the PTR record to get the hostname, then look up the A record for that hostname, then verify the A record IP address matches the original IP address:
If both lookups return matching values the FCrDNS check passes.
Common PTR record issues
No PTR record configured: the most common PTR issue. An IP address with no PTR record fails reverse DNS lookups and increases spam scores for email sent from that address. Mail servers that require PTR records reject or heavily filter email from unresolvable IP addresses. Contact the IP address provider to configure a PTR record.
Generic ISP-assigned PTR record: ISPs often assign default PTR records to IP addresses in their blocks, typically formatted as the IP address itself in reverse or as a generic hostname like 93-184-216-34.isp.example.net. These generic records fail FCrDNS checks and are treated as a negative signal by spam filters. Requesting a custom PTR record from the ISP, pointing to the mail server’s actual hostname, improves deliverability.
PTR record not forward-confirmed: the PTR record returns a hostname but the hostname’s A record does not point back to the same IP address. The FCrDNS check fails. Common causes include a PTR record updated when the A record was not or vice versa. Both records must be updated together, the PTR record updated to the new hostname and the hostname’s A record updated to point to the IP address.
Multiple PTR records for one IP: while technically possible having multiple PTR records for a single IP address can confuse mail servers that expect a single unambiguous reverse DNS result. Most implementations use a single PTR record per IP address.
PTR record propagation delay: PTR records are subject to the same DNS propagation delays as other DNS records. After requesting a PTR record update from an ISP or cloud provider there may be a delay before the change is visible to all resolvers. Testing from multiple geographic locations using online tools confirms whether propagation is complete.