What Is Reverse DNS? PTR Records and Email Deliverability

Last updated: May 31, 2026

Standard DNS works in one direction. You give it a domain name like mail.example.com and it returns an IP address like 203.0.113.25. Reverse DNS does exactly the opposite. You provide an IP address, and the system returns the hostname associated with it. If you need a refresher on how forward DNS resolution works, see our guide on how DNS works.

This might sound like a niche capability, but reverse DNS touches critical infrastructure workflows every day. Mail servers perform a reverse DNS lookup on every connecting IP as one of the first inbound checks. Security analysts use reverse DNS to turn raw IPs in log files into identifiable hostnames. Network engineers running traceroute rely on it for the readable hop names.

The stakes changed in 2024 and 2025. Google, Yahoo, and Microsoft now treat missing or misconfigured reverse DNS as a hard email delivery failure for high-volume senders. This guide covers what reverse DNS is and why it matters more now than ever. It also walks through how to set it up correctly. It applies whether you manage a mail server, run any internet-facing service, or analyze network traffic.

How Reverse DNS Works

Reverse DNS maps an IP address back to a hostname through PTR (pointer) records. The records live in the in-addr.arpa domain for IPv4 and ip6.arpa for IPv6. The IP address is reversed at the octet level and appended to the namespace for the query.

The in-addr.arpa Domain

For IPv4, reverse DNS uses the in-addr.arpa domain. The IP address is reversed at the octet level and appended to this domain. For example, to look up the hostname for 8.8.8.8, the DNS resolver queries:

8.8.8.8.in-addr.arpa

The octets are reversed because DNS is hierarchical from right to left. In forward DNS, mail.example.com delegates from com to example to mail. Reversing the IP octets preserves this delegation model. The 8.0.0.0/8 block is delegated first, then 8.8.0.0/16, and so on down to the individual host record.

For IPv6, the same concept applies using the ip6.arpa domain. Each nibble (4-bit hex digit) is reversed individually. A single IPv6 address produces a 64-character domain name, which is why IPv6 reverse DNS is almost always automated.

How the Query Flows

When you initiate a reverse DNS lookup, here is what happens:

1. Your resolver reverses the IP octets and appends in-addr.arpa.
2. It queries the root DNS servers, which delegate to the appropriate Regional Internet Registry (ARIN, RIPE, APNIC, etc.).
3. The RIR’s nameservers delegate further to the nameservers of the organization that owns the IP block.
4. The authoritative nameserver for that IP range returns the PTR record containing the hostname.

If no PTR record exists at any point in this chain, the reverse DNS lookup fails. The query returns NXDOMAIN or an empty result.

Why Reverse DNS Matters

Four use cases drive reverse DNS adoption. Email deliverability is the most critical — most major mail providers reject mail from IPs without valid PTR records. Security forensics, network troubleshooting via traceroute, and compliance frameworks also depend on properly configured reverse DNS.

Email Deliverability (Now Mandatory at the MGY Trifecta)

This is the most consequential reason administrators care about reverse DNS in 2026. The three largest consumer mail providers form the “MGY trifecta” — Microsoft, Google, and Yahoo. All three now treat missing PTR records and broken FCrDNS as a hard delivery failure for high-volume senders.

Here is the timeline:

• February 2024: Google and Yahoo announce bulk sender requirements. Valid PTR + FCrDNS required for senders doing 5,000+ messages/day to Gmail or Yahoo Mail.
• April 2024: Google and Yahoo enforcement begins. Non-compliant high-volume mail is throttled or routed to spam.
• April 2, 2025: Microsoft announces parallel requirements for Outlook.com, Hotmail.com, and Live.com.
• May 5, 2025: Microsoft enforcement begins. Non-compliant messages from high-volume senders route to the Junk folder.
• Future date (TBA by Microsoft): Non-compliant messages will be rejected entirely.

Here is the logic a receiving mail server follows when an SMTP connection arrives:

1. The receiving server performs a reverse DNS lookup on the sending IP.
2. If no PTR record exists, the message is rejected or sent to spam.
3. If a PTR record returns a hostname, the server does a forward lookup. The forward lookup confirms the hostname resolves back to the same IP. This is forward-confirmed reverse DNS.
4. If FCrDNS fails, the message is rejected, throttled, or sent to spam depending on the provider’s policy.

Google’s postmaster guidelines state this explicitly. The sending IP must have a PTR record. The hostname in the PTR record must have a forward DNS that resolves back to the sending IP. Microsoft’s May 2025 documentation matches this requirement word for word.

Reverse DNS is not the only requirement. The MGY trifecta also requires SPF, DKIM, and DMARC properly configured. A DMARC policy of at least p=none is required, and one-click unsubscribe headers are required for marketing mail. Setting up these protocols requires care. See our guide on how to set up SPF and DMARC without breaking email for the safe ordering. PTR records and email authentication work together. Missing any one of them causes delivery problems.

If your IP also ends up on a DNS blacklist, the rDNS configuration matters even more. See our guide on what a DNS blacklist is and how to get off one for the delisting workflow. Many mail servers also enforce TLS on inbound connections. A valid certificate matters too. Our SSL certificates guide covers the related setup.

If you run your own mail server, you can perform a reverse DNS lookup instantly. Verify your configuration before sending a single message.

Security and Forensics

Raw IP addresses in log files are difficult to work with at scale. Reverse DNS lookup lets security analysts quickly associate addresses with organizations and hostnames. When you see 198.51.100.44 in a firewall log, a reverse IP lookup might reveal scanner-node.suspiciousvps.net. That immediately tells you something about the traffic source.

Many intrusion detection systems and SIEM platforms perform automatic reverse DNS lookups to enrich log data. This correlation helps when investigating abuse reports. Reporting to the correct responsible party requires knowing who operates the IP. A properly configured firewall can log source IPs alongside reverse DNS data, making forensic analysis much faster.

For deeper attribution, pair reverse DNS with a WHOIS or RDAP lookup on the IP. The PTR record tells you the hostname an administrator assigned. The RDAP lookup tells you the registered network operator behind that IP block. Together they form the standard first-pass investigation flow.

You can also check your public IP and its associated hostname to see what your own infrastructure reveals about itself.

Network Troubleshooting

Run traceroute or mtr against any destination. Every hop in the path can display a hostname if a PTR record exists. Compare:

5  72.14.236.216  12.4 ms
6  142.251.49.135  13.1 ms

versus:

5  lax17s55-in-f216.1e100.net (72.14.236.216)  12.4 ms
6  lax28s18-in-f135.1e100.net (142.251.49.135)  13.1 ms

The second output immediately tells you the traffic is transiting Google’s network. This context is invaluable when diagnosing routing anomalies, latency issues, or path changes. Network engineers working with subnet calculations and routing tables rely on reverse DNS to make sense of trace data. For a broader look at diagnosing connection problems, see our network connectivity troubleshooting guide.

Compliance and Auditing

Some enterprise security policies and regulatory frameworks require reverse DNS to be configured for all public-facing IP addresses. PCI DSS assessments, SOC 2 audits, and some government security baselines treat missing PTR records as a configuration deficiency. Even when not strictly mandatory, auditors view properly configured reverse DNS as a sign of operational maturity.

Automated vulnerability scanners and external attack surface management (EASM) tools also flag IPs with missing PTR records. Missing rDNS is not a vulnerability in the strict sense. It is often listed as a low-severity finding that warrants remediation as part of standard infrastructure hygiene.

How to Perform a Reverse DNS Lookup

Three paths handle reverse DNS queries. Command-line tools like dig, nslookup, and host work on any operating system. Web-based tools like NetworkCheckr’s reverse DNS lookup return results without a terminal. For automation, Python’s socket.gethostbyaddr handles bulk lookups programmatically.

Command Line Methods

Every major operating system includes tools for reverse DNS lookups. Here are the most common approaches.

Using nslookup (Windows, macOS, Linux):

$ nslookup 8.8.8.8
Server:    192.168.1.1
Address:   192.168.1.1#53

Non-authoritative answer:
8.8.8.8.in-addr.arpa    name = dns.google.

Using dig -x (macOS, Linux):

$ dig -x 8.8.8.8 +short
dns.google.

The -x flag tells dig to perform a reverse lookup. It automatically handles the octet reversal and in-addr.arpa construction. For full detail, omit +short:

$ dig -x 8.8.8.8

;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.  7103   IN      PTR     dns.google.

Using host (macOS, Linux):

$ host 8.8.8.8
8.8.8.8.in-addr.arpa domain name pointer dns.google.

Online Tools

If you need a quick check without opening a terminal, NetworkCheckr’s web-based tool returns results in one click. You can perform a reverse DNS lookup instantly from any browser.

Programmatic Lookups

For automation and scripting, Python provides a simple approach:

import socket

try:
    hostname, aliases, addresses = socket.gethostbyaddr("8.8.8.8")
    print(f"Hostname: {hostname}")
except socket.herror as e:
    print(f"Reverse DNS lookup failed: {e}")

This is useful in log processing scripts, monitoring tools, and security automation pipelines. The pattern handles bulk IP resolution at scale where command-line tools become impractical.

How to Set Up Reverse DNS

The IP address owner sets the PTR record, not the domain owner. For dedicated servers and VPS, your hosting provider controls it. For cloud providers like AWS, Azure, and Google Cloud, configure it through their platform. Residential ISPs typically will not set custom PTR records.

This is where many administrators get confused. Forward DNS records are managed through your domain registrar or DNS provider. See our DNS records explained guide for details on A, MX, TXT, and other record types. PTR records work differently. They are controlled by whoever owns the IP address block, not the domain owner.

Who Controls Your PTR Record

The authority chain for reverse DNS follows IP address allocation, not domain ownership:

• Dedicated server or colocation: Your hosting provider controls the PTR record. Submit a request through their control panel or support ticket.
• VPS provider: Most VPS providers (DigitalOcean, Vultr, Linode, Hetzner) let you set PTR records directly in their dashboard.
• Business ISP: Contact your ISP and request a PTR record for your static IP.
• Residential ISP: Most residential ISPs will not set custom PTR records. The IP typically resolves to a generic hostname like pool-203-0-113-25.res.example.net.

Cloud Provider Processes

AWS: For EC2 Elastic IPs, submit a reverse DNS request through the AWS Support Center or use the ec2:ModifyAddressAttribute API. You must first set a forward DNS A record for the desired hostname. AWS verifies the forward record before publishing the PTR.

Azure: Configure PTR records in Azure DNS by creating a reverse DNS zone for your IP range. For Azure-assigned public IPs, set the ReverseFqdn property on the Public IP resource.

Google Cloud: Set the PTR record by updating the instance’s metadata or using the gcloud compute instances add-metadata command. GCP requires the forward record to exist and match.

What the PTR Record Should Contain

Your PTR record should point to a fully qualified domain name (FQDN) you control. The FQDN must resolve back to the same IP. For a mail server, this is typically your mail hostname:

203.0.113.25  →  PTR  →  mail.example.com
mail.example.com  →  A  →  203.0.113.25

Avoid pointing PTR records to bare domains, CDN hostnames, or anything that does not resolve back to the original IP. The forward and reverse records must agree.

Forward-Confirmed Reverse DNS (FCrDNS)

FCrDNS verifies that a reverse DNS lookup and a subsequent forward DNS lookup return consistent results. The IP maps to a hostname, and the hostname maps back to the same IP. Mail providers including Google, Microsoft, and Yahoo check FCrDNS as part of spam filtering heuristics.

Forward-confirmed reverse DNS (sometimes called full-circle reverse DNS) is a two-step verification. A reverse DNS lookup runs first. A subsequent forward DNS lookup then confirms the results agree. Specifically:

1. Start with IP 203.0.113.25.
2. Reverse lookup returns mail.example.com.
3. Forward lookup of mail.example.com returns 203.0.113.25.

If both directions match, you have FCrDNS. If the forward lookup returns a different IP, or the hostname does not resolve at all, FCrDNS fails.

Why Email Providers Care About FCrDNS

A PTR record alone can contain any hostname. There is no built-in validation at the DNS level that the PTR value is legitimate. A spammer could theoretically get their hosting provider to set a PTR of mail.bigbank.com. The spammer might have no relationship to that domain at all.

FCrDNS closes this loophole. By verifying the forward record also matches, the receiving server confirms that the domain owner actually controls the IP address. This is why Google, Microsoft, and Yahoo all check FCrDNS as part of their spam filtering heuristics.

How to Verify Your FCrDNS

Run these two commands and confirm the results match:

# Step 1: Reverse lookup
$ dig -x 203.0.113.25 +short
mail.example.com.

# Step 2: Forward lookup
$ dig mail.example.com A +short
203.0.113.25

If both outputs are consistent, your FCrDNS is correctly configured. If either lookup fails or returns mismatched values, you need to update your DNS records or contact your IP provider.

Common Reverse DNS Problems

Four patterns account for most reverse DNS failures. No PTR record at all is the default for new IPs. PTR-to-forward mismatches break FCrDNS verification. Generic ISP hostnames work but signal consumer connections. Multiple IPs without individual PTR records cause selective delivery failures.

Related Tools & Resources

NetworkCheckr offers complementary tools for reverse DNS workflows. The Reverse DNS Lookup tool performs PTR queries instantly. The DNS Lookup checks forward records to verify FCrDNS. The IP Blacklist Check confirms your sending IP is not flagged for delivery problems.

• Reverse DNS Lookup — perform PTR queries for any IP address.
• DNS Lookup — check forward records to verify FCrDNS alignment.
• IP Blacklist Check — confirm your sending IP is not on a major DNSBL.
• Email Auth Checker — verify SPF, DKIM, and DMARC alongside rDNS.
• WHOIS Lookup — identify the network operator behind an IP block.
• SPF, DKIM, and DMARC Explained — the email authentication companion to rDNS.
• What Is a DNS Blacklist? — if your IP is on a blacklist, fix it before retesting rDNS.
• All NetworkCheckr Tools — the full set of free networking utilities.

Frequently Asked Questions

Six questions cover the practical edge cases. How PTR records work mechanically. Whether reverse DNS affects email delivery. Who is responsible for setting it up. How forward-confirmed reverse DNS verification works. Whether home IPs can be configured. And how to verify your own configuration.