Forward DNS vs Reverse DNS
Standard DNS lookups — called forward lookups — translate a hostname into an IP address. You query example.com and receive 93.184.216.34. This is the direction that browsers, applications, and virtually all internet traffic use to initiate connections.
Reverse DNS (rDNS) runs in the opposite direction: given an IP address, return the associated hostname. Instead of asking "what is the IP for mail.example.com?", reverse DNS asks "what is the hostname for 93.184.216.34?". The answer is a PTR (pointer) record — a DNS record type specifically designed for this purpose.
Reverse DNS is not used to establish connections — you cannot browse to an IP address and have reverse DNS redirect you to the site. Its value lies in identification and verification: knowing that a given IP address belongs to a named, accountable host is essential for email filtering, security logging, and network diagnostics.
How PTR Records Work
PTR records live in a special section of the DNS namespace called in-addr.arpa. To look up the hostname for the IP address 1.2.3.4, a DNS resolver constructs the query 4.3.2.1.in-addr.arpa — the octets of the IP address reversed, with .in-addr.arpa appended.
The reversal is necessary because the DNS hierarchy delegates authority from left to right (most general to most specific), but IPv4 addresses are written with the most general octet on the left. By reversing the address, the hierarchy aligns correctly: IANA delegates in-addr.arpa to regional internet registries (RIRs), which sub-delegate to ISPs and hosting providers, who can further delegate to their customers. This mirrors how forward DNS delegates from the root to TLD to registrar to domain owner.
The PTR record itself is simple: it contains a single hostname value — a fully qualified domain name (FQDN) ending in a dot, such as mail.example.com. — that is the canonical name for that IP address.
Who Controls PTR Records
This is the detail that confuses most people: PTR records are controlled by whoever owns the IP address block, not by whoever owns the domain name. IP address blocks are allocated by IANA to regional internet registries (ARIN, RIPE, APNIC, etc.), which allocate them to ISPs and hosting providers, which assign individual addresses to customers.
When you rent a server from a hosting provider, the provider owns the IP address. To set a PTR record for that IP, you must either use a portal the provider offers (common for VPS and dedicated server providers), submit a support request, or have the reverse DNS zone delegated to your own nameservers (available from providers that support SWIP delegation for large IP allocations).
For a home internet connection, your ISP controls the PTR records for your dynamic IP address. Most ISPs set generic PTR records like pool-96-229-12-34.nwrknj.fios.verizon.net. Residential customers generally cannot customize these.
IPv6 Reverse DNS
IPv6 uses the same PTR record mechanism but with a different special zone: ip6.arpa instead of in-addr.arpa. The format is more complex — each hexadecimal digit of the IPv6 address is written as a separate label in reverse order (nibble format).
For the IPv6 address 2001:0db8:85a3:0000:0000:8a2e:0370:7334, the reverse lookup query is constructed by removing colons, reversing all 32 hex digits, and appending .ip6.arpa: 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. The dig -x command handles this construction automatically.
IPv6 reverse DNS is particularly important for mail servers, as spam filters apply the same PTR checks regardless of whether the sending IP is IPv4 or IPv6. Many administrators correctly configure IPv4 PTR records but neglect their IPv6 PTR records, causing delivery failures for mail sent over IPv6.
Why Reverse DNS Matters for Email
Email deliverability is the primary reason most server administrators care about reverse DNS. When your mail server delivers a message, it connects to the recipient's mail server and announces itself with an SMTP EHLO command — for example, EHLO mail.example.com. The receiving server checks the PTR record of the connecting IP address to see if it matches the EHLO hostname.
If the IP has no PTR record, or the PTR record returns a generic hostname that does not match mail.example.com, the receiving server flags the message as suspicious. Gmail, Outlook, Yahoo, and most enterprise mail systems either reject messages outright or assign them a high spam score when PTR validation fails. This is one of the most common causes of email ending up in spam folders for new mail servers.
Forward-Confirmed Reverse DNS (FCrDNS) takes this a step further: the PTR record must resolve to a hostname, and that hostname's A record must resolve back to the original IP. A PTR record that points to a hostname that points to a different IP fails FCrDNS validation — a common mistake when a domain's A record is updated without also updating the PTR record at the hosting provider.
Reverse DNS in Security and Logging
Security information and event management (SIEM) systems, intrusion detection systems, and firewall logs all benefit from reverse DNS. Log entries that contain raw IP addresses are difficult to analyze at scale — a hostname like scanner.shodan.io is immediately recognizable, while its IP address is not. Reverse DNS enrichment is a standard step in log processing pipelines that converts IP addresses to hostnames for faster triage and pattern recognition.
Network diagnostic tools including traceroute and mtr perform reverse DNS lookups on each hop IP address to display router hostnames in their output. A traceroute hop showing ae-1-3.bar1.NewYork1.Level3.net is far more informative than a bare IP address. When reverse DNS is missing for intermediate hops, diagnostic tools display the raw IP, making it harder to identify which network segment a packet is traversing.
How to Perform a Reverse DNS Lookup
Three command-line tools support reverse DNS lookups natively. All three accept the IP address in normal dotted-decimal format and construct the in-addr.arpa query automatically.
Using dig: dig -x 8.8.8.8 — the -x flag signals a reverse lookup. Look for the PTR record in the ANSWER section. To query a specific DNS server, append @resolver-ip: dig -x 8.8.8.8 @1.1.1.1.
Using nslookup: nslookup 8.8.8.8 — nslookup automatically performs a reverse lookup when given an IP address. The output shows the PTR hostname under "name".
Using host: host 8.8.8.8 — the most concise output, returning a single line like 8.8.8.8.in-addr.arpa domain name pointer dns.google.
Forward DNS vs Reverse DNS
| Attribute | Forward DNS | Reverse DNS |
|---|---|---|
| Direction | Hostname → IP address | IP address → Hostname |
| Record type | A (IPv4), AAAA (IPv6) | PTR |
| Zone | example.com | in-addr.arpa (IPv4), ip6.arpa (IPv6) |
| Who controls it | Domain owner | IP address block owner (ISP / hosting provider) |
| Typical TTL | 300–3600 seconds | 3600–86400 seconds |
| Primary use case | Connecting to websites and services by name | Email deliverability, security logging, diagnostics |
Frequently Asked Questions
Why does my mail server need a PTR record?
Mail servers use PTR records as one of many signals to evaluate whether an incoming message is legitimate. When your mail server sends an email, the receiving mail server checks the PTR record of the connecting IP address. If no PTR record exists, or if the PTR record does not match the hostname your mail server announced in its SMTP EHLO greeting, the receiving server may reject the message or score it as likely spam. Major providers like Gmail, Outlook, and Yahoo apply PTR checks as a baseline spam-filtering measure.
How do I set up a PTR record for my server?
PTR records are controlled by whoever owns the IP address block — usually your hosting provider or ISP, not you. To set a PTR record, log into your hosting provider's control panel and look for a "Reverse DNS" or "PTR record" setting, which is typically found in the network or IP management section. Enter the fully qualified domain name you want the IP to resolve to. If your provider does not offer a self-service PTR option, open a support ticket requesting the PTR record be set. The hostname you choose must have a forward A record pointing back to the same IP.
Can I set my own reverse DNS record?
You can only set a reverse DNS record if you control the IP address block — or if your provider has delegated the reverse DNS zone to you. For dedicated servers or colocation, providers often delegate the reverse zone so you can manage PTR records yourself in your own DNS server. For shared hosting or standard cloud VMs, you typically set PTR records through a portal field rather than managing the zone directly. For home internet connections, your ISP controls the reverse DNS and most do not allow customers to customize it.
What is in-addr.arpa?
in-addr.arpa is the special DNS zone used for IPv4 reverse lookups. When you perform a reverse DNS lookup for an IP address, your DNS resolver constructs a query by reversing the octets of the IP address and appending .in-addr.arpa. For example, to look up the hostname for 192.0.2.1, the resolver queries 1.2.0.192.in-addr.arpa for a PTR record. The IP address is reversed because DNS delegates authority from left to right (most general to most specific), but IP addresses are written most general on the left — reversing the octets aligns IP addresses with the DNS hierarchy.
How do I look up reverse DNS for an IP address?
There are several command-line tools for reverse DNS lookups. Using dig: run dig -x 1.2.3.4 and look for the PTR record in the ANSWER section. Using nslookup: run nslookup 1.2.3.4 and the output will show the hostname if a PTR record exists. Using the host command: run host 1.2.3.4 for a concise single-line result. All three tools construct the in-addr.arpa query automatically — you just provide the IP address in its normal dotted-decimal form.
What is FCrDNS and why does it matter for email?
FCrDNS stands for Forward-Confirmed Reverse DNS. It means that the PTR record for an IP address resolves to a hostname, and that hostname's A record resolves back to the same IP address — forming a confirmed circle. Email security systems use FCrDNS validation to verify that the sending mail server's IP and hostname are consistently configured. If the PTR resolves to mail.example.com but mail.example.com's A record points to a different IP, the forward confirmation fails, which is a strong spam signal. Proper FCrDNS requires both the PTR record and the forward A record to be correctly configured and consistent.