A reverse DNS lookup does the opposite of a normal one: instead of turning a domain into an IP address, it turns an IP address back into a hostname. The record that makes this possible is the PTR record — and if you run a mail server, it’s the reason your messages get accepted or rejected before anyone reads them.
There’s one thing to know before anything else, and it saves hours of searching: you cannot create a PTR record in your domain’s DNS settings. It doesn’t live there. PTR records are controlled by whoever owns the IP address block — your hosting provider or ISP — and that’s why you’ll never find the option in your control panel.
| To check a PTR record | dig -x 203.0.113.10 on Linux/macOS, or nslookup 203.0.113.10 on Windows |
| To set one | Ask your hosting or IP provider. You can’t do it yourself in your domain’s DNS |
| Do you need one? | Only if you send mail from your own server or a dedicated IP. Shared hosting, Gmail and ESPs handle it for you |
Table of Contents
Forward vs reverse: what actually changes
A normal DNS lookup — the forward kind — answers “what IP address is behind this name?”. It’s what happens every time you open a website, and the record that answers it is the A record (or AAAA, for IPv6).
A reverse lookup asks the opposite question: “what name belongs to this IP address?” The record that answers is the PTR record.
| Forward lookup | Reverse lookup | |
|---|---|---|
| Question | Which IP is behind this name? | Which name belongs to this IP? |
| Record type | A / AAAA | PTR |
| Who controls it | You, in your domain’s DNS | Whoever owns the IP block |
| Used for | Loading websites, sending mail | Verifying sender identity, reading logs |
That third row is where most confusion starts, and it’s worth repeating: the forward record is yours, the reverse record isn’t.
How a PTR record is actually stored
The mechanics look strange the first time you see them, and knowing why helps the lookup make sense.
DNS reads names from right to left, getting more specific as it goes — in mail.example.com, the .com is the broadest part. IP addresses work the opposite way: in 203.0.113.10, the 203 is the broadest part and it’s on the left.
To fit IP addresses into a system built for names, DNS reverses the address and appends a special domain:
IP address: 203.0.113.10
Reversed: 10.113.0.203
PTR lookup: 10.113.0.203.in-addr.arpa
For IPv6, the suffix is .ip6.arpa and each hexadecimal digit is reversed individually. You’ll rarely type these by hand — the dig -x command builds them for you — but seeing the structure explains why a “reverse zone” is organised the way it is.
How to run a reverse DNS lookup
Three ways, depending on what you have available.
On Linux or macOS, dig is the cleanest option:
dig -x 203.0.113.10
# Just the answer, without the noise
dig -x 203.0.113.10 +short
On Windows, from the Command Prompt:
nslookup 203.0.113.10
# Or explicitly asking for the record type
nslookup -type=PTR 10.113.0.203.in-addr.arpa
The plain nslookup with an IP does a reverse lookup automatically — you don’t need the second form unless you’re querying a specific server.
In PowerShell, if you prefer:
Resolve-DnsName 203.0.113.10 -Type PTR
Online, tools like MXToolbox and whatsmydns run the same query from a browser, which is useful when you want to check from outside your own network.
Reading the result: you’re looking for a hostname. If the answer comes back empty, or with an error like NXDOMAIN, no PTR record exists for that address.
Why it matters: email deliverability
This is what brings most people to the topic, and the stakes are higher than they look.
When a mail server receives a connection, one of the first things it does is a reverse lookup on the sending IP. It’s checking whether the machine claiming to be mail.yourcompany.com actually resolves to that name. A missing or mismatched PTR is a strong signal of a compromised machine or a spam bot — because legitimate mail infrastructure almost always has one.
The consequence isn’t subtle: major providers reject the message outright or apply a heavy spam penalty, often before your content is evaluated at all. And because the rejection happens at connection level, it can produce vague errors that don’t obviously point at DNS.
Since February 2024, Google and Yahoo require bulk senders to pass reverse DNS validation. It moved from “good practice” to “requirement” for anyone sending at volume.
Our guides on SPF, DKIM and DMARC cover the authentication layer that sits on top of this — but reverse DNS comes first, at the network level, before authentication is even examined.
FCrDNS: why matching in one direction isn’t enough
Having a PTR record isn’t the finish line. What receiving servers actually check is Forward-Confirmed reverse DNS (FCrDNS) — that both directions agree.
| Step | What must be true |
|---|---|
| 1. Reverse | The IP 203.0.113.10 resolves to mail.example.com |
| 2. Forward | mail.example.com resolves back to 203.0.113.10 |
| Result | Both match → FCrDNS passes. Either fails → the check fails |
This is why a generic PTR doesn’t help. Many providers assign hostnames like 203-0-113-10.static.provider.net by default. Technically a PTR exists — but it doesn’t identify your mail server, and receiving systems treat it as an unconfigured machine. What you want is the PTR pointing to your actual mail hostname, with a matching A record going back.
This is the single most common source of frustration with reverse DNS, and it’s worth being direct about: PTR records live in the reverse zone of the IP block, not in your domain’s DNS. Only the organisation that owns that block — your hosting provider, VPS provider or ISP — can create or change them.
So if you’ve been searching your control panel for where to add a PTR record, you won’t find it. The correct action is to open a ticket with your provider, telling them the IP address and the hostname it should resolve to.
When reverse DNS isn’t your problem at all
Worth stating clearly, because most people reading this don’t need to do anything:
Shared hosting. The provider manages the reverse DNS of the shared mail server. Nothing for you to configure.
Gmail, Google Workspace, Microsoft 365, Outlook. Google and Microsoft manage PTR records for their own sending infrastructure.
Marketing platforms on shared IPs — Mailchimp, Klaviyo, Brevo and similar. The platform handles it.
It becomes your responsibility in two situations: when you run your own mail server on a VPS or dedicated server, and when you use a dedicated IP with a sending service. In both, the PTR isn’t set automatically, and configuring it is a step people frequently skip.
Forward and reverse lookup zones
If you administer a Windows Server or an internal DNS, you’ll encounter these two terms — and the naming is more literal than it sounds.
A forward lookup zone holds the records that map names to addresses: A, AAAA, CNAME, MX. It’s the zone you work in most of the time.
A reverse lookup zone holds the PTR records for a range of IP addresses. It’s created separately, named after the reversed network with .in-addr.arpa appended, and it’s what allows reverse queries to be answered within that network.
On a public internet scale, reverse zones are delegated by the regional registries down to whoever holds the IP block — which is the technical reason behind the restriction described above.
Other uses beyond email
Email gets the attention, but reverse DNS does other work:
Readable logs. Server logs record IP addresses. Reverse lookups turn rows of numbers into recognisable hostnames, which makes traffic analysis considerably faster.
Network troubleshooting. Tools like traceroute resolve each hop’s IP to a hostname, letting you see the path your connection takes and where it slows down.
Security investigation. When an unfamiliar IP appears in your logs, a reverse lookup is the fastest first step in identifying whether it belongs to a known service, a cloud provider, or something worth blocking.
Verifying crawlers. Google recommends confirming that a bot claiming to be Googlebot really is — by running a reverse lookup on its IP and then a forward lookup on the result. It’s FCrDNS applied to bot verification.
Troubleshooting
| Symptom | What it means |
|---|---|
| Lookup returns nothing / NXDOMAIN | No PTR record exists. Ask your provider to create one |
| PTR returns a generic provider hostname | A record exists but doesn’t identify you. Request it point to your mail hostname |
| PTR is right, mail still flagged | Check the forward direction — the hostname needs an A record back to the same IP |
| Works on IPv4, fails on IPv6 | IPv6 needs its own PTR. If yours is missing, either add it or disable IPv6 sending |
| Changed the PTR, still seeing the old value | Reverse zones cache like any DNS. Allow for the TTL before retesting |
Reverse DNS is one of the few things you genuinely can’t configure yourself — it depends on your provider. Copahost sets the PTR for your dedicated IP to the hostname you need, and our shared hosting mail servers are configured for FCrDNS from the start. Free migration from your current host included.
See hosting plansFrequently asked questions
What is a reverse DNS lookup?
It’s a DNS query that resolves an IP address back to a hostname — the opposite of a normal lookup, which resolves a name to an address. The record that answers a reverse query is the PTR record, and it lives in the reverse zone of the IP block rather than in your domain’s DNS.
What is a PTR record?
A PTR (pointer) record maps an IP address to a hostname. It’s the reverse counterpart of an A record, which maps a hostname to an IP address. Mail servers use PTR records to check whether a sending machine is what it claims to be.
How do I run a reverse DNS lookup?
On Linux or macOS, run dig -x followed by the IP address. On Windows, nslookup with an IP address performs a reverse lookup automatically. In PowerShell, use Resolve-DnsName with -Type PTR. Online tools like MXToolbox do the same from a browser, which is useful for checking from outside your network.
Why can’t I add a PTR record in my DNS panel?
Because PTR records don’t belong to your domain — they belong to the IP address block, and only the organisation that owns that block can create them. That’s your hosting provider, VPS provider or ISP. The correct action is to request it from them, specifying the IP and the hostname it should resolve to.
Does reverse DNS affect email deliverability?
Significantly. Receiving mail servers run a reverse lookup on the connecting IP as one of their first checks. A missing or mismatched PTR is treated as a strong spam signal, and many providers reject the message before evaluating its content. Since February 2024, Google and Yahoo require bulk senders to pass reverse DNS validation.
What is FCrDNS?
Forward-Confirmed reverse DNS. It means both directions agree: the IP resolves to a hostname, and that hostname resolves back to the same IP. Having only a PTR record isn’t enough — the forward A record must match for the check to pass.
Do I need a PTR record if I use Gmail or a shared host?
No. Google, Microsoft and marketing platforms manage reverse DNS for their own sending infrastructure, and shared hosting providers manage it for the shared mail server. It becomes your responsibility when you run your own mail server or use a dedicated IP.
What’s the difference between a forward and a reverse lookup zone?
A forward lookup zone contains the records that map names to addresses — A, AAAA, CNAME, MX. A reverse lookup zone contains the PTR records for a range of IP addresses, and is named after the reversed network with .in-addr.arpa appended. Both terms come up when administering an internal or Windows Server DNS.
See also
For the basics of how name resolution works, see what DNS stands for and DNS ports. If lookups are slow rather than missing, see how to fix slow DNS lookup. And for the authentication layer that sits above reverse DNS, see what an email domain is.
To check the TXT records that carry SPF, DKIM and DMARC, see DNS TXT lookup. If you’re setting up your own mail server, the PTR record is one of the first things to get right — see what running a self-hosted email server takes.
Conclusion
Reverse DNS is unusual among DNS topics because the fix is rarely in your hands: the PTR record belongs to whoever owns the IP, and the correct move is a request to your provider rather than an edit in your panel. Knowing that alone saves the hours most people spend looking for a setting that doesn’t exist. If you send mail from your own server or a dedicated IP, it’s worth checking today — run dig -x on your sending address and confirm that the hostname it returns points back to the same IP. That round trip is what receiving servers check, and it happens before anyone reads a word of your message.
