Reverse DNS: a beginner's guide

Reverse DNS (rDNS) is the answer to the question "what hostname is associated with this IP address?" — the opposite of regular DNS, which goes from a name to an address. The mechanism works through a special DNS record type called PTR ("pointer"), and the lookups happen in a special part of the DNS hierarchy called `in-addr.arpa` (for IPv4) or `ip6.arpa` (for IPv6). When you do a reverse lookup on `203.0.113.10`, your resolver actually queries `10.113.0.203.in-addr.arpa`, which is the IP address written backwards with `.in-addr.arpa` appended. The answer is a hostname, like `mail.example.com`. Forward DNS and reverse DNS are maintained completely separately and they are not always in agreement — which is itself a useful signal.

You should care because reverse DNS is one of the oldest spam-filter signals on the internet and is still used by every major mail server. When a mail server receives an incoming SMTP connection from an IP address, it does a reverse DNS lookup on that IP to find the hostname, then a forward DNS lookup on the hostname to make sure it points back to the same IP. If the two don't match — or if there is no PTR record at all — the connection is treated as suspicious and the mail is much more likely to be filtered as spam. This is the forward-confirmed reverse DNS (FCrDNS) check, and it has been the deliverability bedrock since the 1990s.

The five things every reverse DNS check looks at:

• Is there a PTR record at all? Many residential ISPs do not assign meaningful PTRs, which is why home connections can't run mail servers reliably.

• Does the PTR resolve to a hostname that looks legitimate? A PTR like `static-203-0-113-10.example.com` is fine; one that looks generic or random is a weaker signal.

• Does the forward lookup of the hostname return the same IP? This is the FCrDNS check. Mismatches are treated as a strong negative.

• Does the hostname match the HELO greeting in the SMTP session? Mail servers compare these and flag inconsistencies.

• Is the PTR consistent with the SPF record's `ptr` mechanism, if present? The `ptr` mechanism in SPF is largely deprecated but still exists.

Three questions a reverse DNS check answers:

• Does my mail server's IP have a PTR record, and does it forward-confirm correctly?

• For a suspicious incoming connection, what is the reverse DNS of the source IP?

• After my recent server move, did the cloud provider set up a PTR for my new IP — or do I need to ask them to?

The cost of broken reverse DNS is silently degraded email deliverability that nobody notices until customers start complaining. The fix is to make sure your hosting provider has set the PTR record correctly for any IP that sends mail. This is the kind of operational detail that distinguishes a properly run email setup from a barely-working one.

In one sentence: Find hostname from [IP (Internet Protocol address)](/guides/ip-geolocation) via PTR lookup

Performs a reverse DNS (Domain Name System) lookup (PTR record (Pointer record) query) to find the hostname(s) associated with an IP (Internet Protocol address) address. Validates forward-confirmed reverse DNS (FCrDNS) and detects hostname patterns. Essential for email deliverability validation and infrastructure reconnaissance.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Queries PTR records for the IP (Internet Protocol address) address by looking up the in-addr.arpa (IPv4 (Internet Protocol version 4)) or ip6.arpa (IPv6 (Internet Protocol version 6)) domain via Cloudflare DoH (DNS over HTTPS). Returns all associated hostnames, performs forward-confirmed reverse DNS (Domain Name System) (FCrDNS) validation by resolving each PTR hostname back to verify it matches the original IP, and classifies detected hostname patterns (e.g., mail servers, CDNs, residential ISP naming conventions).

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Reverse DNS tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

Reverse DNS (Domain Name System) is critical for email deliverability since Google and Yahoo require Forward-Confirmed Reverse DNS (FCrDNS) as of February 2024. It enables security analysts to resolve IPs in logs to meaningful hostnames, and penetration testers to discover infrastructure during reconnaissance. Missing or misconfigured PTR records are a leading cause of email delivery failures.

Picture this in real life. Imagine an email administrator. Here's the situation they're walking into: Verify that all mail server IPs have proper PTR records matching the HELO/EHLO hostname, and that FCrDNS passes. Required by Google and Yahoo since February 2024. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Reverse DNS tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Reverse DNS tool is built for you:

• Where in the world is this server actually located, and who runs the network it sits on?

• How fast does traffic move between my users and my service?

• Is the IP address I am looking at part of a residential network, a data center, or something suspicious?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Network engineers, IT admins, sales teams qualifying enterprise prospects, and product teams building geo-personalization or fraud rules. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and you can't tell where your users actually are, who runs the network they're on, or why they're seeing slow page loads. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the Reverse DNS tool belongs in your toolbox, this section is for you. Below you'll meet three real people — an email administrator, a SOC analyst, and a penetration tester — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Email Deliverability Audit

Imagine you're an email administrator. Verify that all mail server IPs have proper PTR records matching the HELO/EHLO hostname, and that FCrDNS passes. Required by Google and Yahoo since February 2024.

Why it matters: Prevent email delivery failures caused by missing or mismatched reverse DNS (Domain Name System) records.

Story 2: Security Log Enrichment

Imagine you're an SOC analyst. Enrich firewall, IDS, and server access logs with hostnames to identify patterns like scanning from cloud providers or known botnet infrastructure.

Why it matters: Transform raw IP (Internet Protocol address) logs into actionable intelligence with meaningful hostname context.

Story 3: Infrastructure Reconnaissance

Imagine you're a penetration tester. Map IP (Internet Protocol address) ranges to hostnames during authorized penetration testing to discover additional subdomains, services, and shared hosting environments.

Why it matters: Expand attack surface understanding by uncovering hidden services and infrastructure relationships.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Reverse DNS tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• When a customer reports that your site is slow specifically from their region.

• When you need to know whether traffic is coming from a residential network or a data center.

• When planning a CDN, points of presence, or geographic expansion.

• During an outage, to see exactly where in the route packets are getting lost.

If you can see yourself in even one of those bullets, the Reverse DNS tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Reverse DNS tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the Reverse DNS tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with Reverse DNS. If you're already running this check, the related ones often answer the next question that comes up:

• IP Geolocation — Get location, ASN, and org for an IP

• DNS Lookup — Query any of 22 DNS record types or ALL at once with DNSSEC validation

• ASN Lookup — Get AS number, organization, and network type

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check Reverse DNS and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

IP (Internet Protocol address) — A unique number that identifies a computer on the internet, like a phone number for a server.

PTR record (Pointer record) — A DNS entry that does the reverse of an A record: it takes an IP address and tells you the domain name attached to it.

DoH (DNS over HTTPS) — A modern way of sending DNS queries that hides them inside encrypted HTTPS traffic, so people on the same network can't see which websites you're looking up.

IPv4 (Internet Protocol version 4) — The original kind of internet address — four numbers separated by dots, like 203.0.113.10. The internet has run out of new ones, which is why IPv6 exists.

IPv6 (Internet Protocol version 6) — The newer, longer kind of internet address. Looks like 2001:0db8:85a3::8a2e:0370:7334. Designed because the world ran out of IPv4 addresses.