Every time you type a website address into your browser, the Domain Name System (DNS) translates that human-readable domain into an IP address so your device knows where to connect. A reverse DNS lookup does the opposite. Instead of finding the IP address for a domain name, it finds the hostname associated with a specific IP address.
While reverse DNS is less visible than standard DNS lookups, it plays an important role behind the scenes. System administrators, network engineers, DevOps teams, developers, and security professionals use it to identify servers, troubleshoot network issues, analyze logs, investigate suspicious traffic, and verify the legitimacy of email servers. Although most internet users never notice reverse DNS working, many critical services rely on it every day.
This guide explains what reverse DNS lookup is, how it works, how to perform and configure it, and the different scenarios where it provides value. You'll also learn why reverse DNS matters for email deliverability, network diagnostics, security investigations, and IP address management, as well as the limitations you should understand before relying on it.
TL;DR: A reverse DNS lookup (rDNS) resolves an IP address to its hostname, the opposite of normal DNS. It works through PTR records stored in dedicated namespaces, in-addr.arpa for IPv4 and ip6.arpa for IPv6, with the address reversed before the zone is appended. You can check any IP with dig, host or nslookup. Setting one up differs from other DNS records: PTR records belong to the IP, not the domain, so they are configured by whoever controls the IP block, usually your hosting provider, cloud provider or ISP. Dedicated IPs normally allow a custom hostname; shared IPs are set by the provider. Best practice is forward-confirmed reverse DNS (FCrDNS), where the PTR hostname resolves back to the same IP. For email this is now a requirement: since February 2024 Google requires valid forward and reverse DNS, rejecting mail from IPs with no PTR record via a 550 5.7.25 error. The trap to check is IPv6, since a valid IVP4 PTR with no matching ip6.arpa record causes Gmail rejections while other providers accept the same mail.
What is a reverse DNS lookup?
A reverse DNS lookup (rDNS) resolves an IP address to its associated hostname. It is the opposite of a traditional DNS lookup, which translates a domain name into an IP address. For example, a forward DNS lookup answers the question: "What IP address does example.com use?" On the other hand, a reverse DNS lookup answers the opposite question: "What hostname is associated with 192.0.2.1?"
While both processes use DNS, they rely on different record types. Forward DNS uses A records for IPv4 and AAAA records for IPv6, while reverse DNS uses PTR (Pointer) records to map IP addresses back to hostnames.
Reverse DNS is recommended as a best practice but is not required for every internet-connected system. Many IP addresses, especially residential and dynamically assigned ones, do not have PTR records configured. A website will still work without reverse DNS because browsers rely on forward DNS to locate servers.
However, reverse DNS becomes important when systems need to identify where traffic is coming from or verify the legitimacy of a server. Common uses include email authentication, server logging, network troubleshooting, security investigations, analytics, and IP address management.
How does reverse DNS work?
At a high level, reverse DNS works by searching for a PTR record that maps an IP address to a hostname. Instead of asking DNS for the address of a domain, the query asks DNS which hostname owns a particular IP address.
Unlike forward DNS, reverse lookups do not search the standard domain namespace. Instead, they query special DNS zones reserved specifically for reverse mapping.
PTR records and the .arpa zones
The foundation of every reverse DNS lookup is the PTR (Pointer) record. A PTR record maps an IP address to a hostname, allowing DNS resolvers to translate numerical addresses into readable names.
Reverse DNS uses dedicated namespaces for this purpose: in-addr.arpa for IPv4 and ip6.arpa for IPv6. Unlike forward DNS, which organizes records by domain names, these zones organize records by IP addresses.
For IPv4, the address is reversed before adding in-addr.arpa. For example, the IP address 192.0.2.1 becomes 1.2.0.192.in-addr.arpa. This reversed structure matches DNS's hierarchical design, allowing authority over different parts of an IP range to be delegated to the organizations that control them.
IPv6 follows the same principle but uses ip6.arpa and reverses the address one hexadecimal digit (or nibble) at a time. For example, 2001:db8::567:89ab is expanded into its full form and converted into a long reversed hexadecimal sequence ending in .ip6.arpa.
Although IPv6 reverse DNS names are much longer than IPv4 ones, the lookup process remains the same: DNS queries the corresponding PTR record and returns the hostname if one exists.
How the query resolves through delegation
Like forward DNS, reverse DNS relies on a distributed system of authoritative nameservers. No single server stores every PTR record on the internet. Instead, responsibility is delegated through multiple levels of the DNS hierarchy.
When a resolver performs a reverse DNS lookup for an address such as 192.0.2.1, the request begins at the DNS root servers and moves through the .arpa namespace before reaching the organization responsible for that IP block. That organization's authoritative nameserver then returns the PTR record containing the hostname.
The lookup path can be summarized as:
DNS Root
↓
.arpa
↓
in-addr.arpa
↓
IP block owner’s authoritative nameserver
↓
PTR record → mail.example.com
Each level of the reverse DNS namespace can delegate authority using NS (Name Server) records, allowing internet registries, cloud providers, hosting companies, and enterprises to manage PTR records only for the IP ranges they control.
This delegation model allows reverse DNS to scale globally while keeping responsibility for IP address information with the organizations that own those addresses.
How to perform a reverse DNS lookup
Once you understand how reverse DNS works, the next step is learning how to query it. The good news is that performing a reverse DNS lookup is straightforward. All you need is the IP address you want to investigate.
Whether you're troubleshooting a server, identifying the owner of an IP address, or verifying that an email server has a properly configured PTR record, the lookup process is the same. You can either use built-in command-line tools or an online reverse DNS lookup tool.
Using the command line
Most operating systems include DNS utilities that can perform a reverse lookup in seconds. These tools query the DNS infrastructure for the IP address's PTR record and return the associated hostname if one exists.
On macOS and Linux, the easiest option is the dig command with the -x flag: dig -x 8.8.8.8. If you only want the hostname without the additional DNS response details, add the +short option: dig -x 8.8.8.8 +short. For the same lookup, you can also use the host command: host 8.8.8.8. On Windows, use nslookup with the IP address: nslookup 8.8.8.8.
All three tools perform the same lookup, but they display results differently. dig is commonly preferred by network administrators because it provides detailed DNS information while allowing concise output with +short.
If an IP address does not have a PTR record, the lookup will return no hostname. For example: dig -x 203.0.113.25 +short may return no output, while host may show: Host 25.113.0.203.in-addr.arpa not found: 3(NXDOMAIN)
An NXDOMAIN response means that no reverse DNS record exists for that address. This is common for many residential, dynamic, and temporary cloud IP addresses and does not necessarily indicate a problem. It simply means reverse DNS has not been configured.
Using online lookup tools
If you don't have access to a terminal or simply want a quicker option, numerous web-based reverse DNS lookup tools can perform the same query.
Most online tools require only a single piece of information: the IP address. After submitting it, the service queries the appropriate PTR record and displays the associated hostname if one exists. Some tools also provide additional information, such as the authoritative nameserver, the autonomous system (AS), or the organization that owns the IP block.
Online tools are especially useful when you're investigating unfamiliar IP addresses or working from a device where command-line utilities are unavailable. However, for routine administration and troubleshooting, built-in tools such as dig, host, and nslookup remain the fastest and most reliable option.
How to set up reverse DNS (PTR records)
Performing a reverse DNS lookup is relatively simple. Configuring reverse DNS is a little different because, unlike most DNS records, you usually cannot create PTR records through your domain registrar or standard DNS hosting provider.
Instead, reverse DNS is managed by whoever controls the IP address block. Understanding who owns that responsibility is the key to setting up PTR records correctly.
Who controls your PTR record?
A common misconception is that reverse DNS is managed alongside your domain's A, CNAME, or MX records. In reality, PTR records belong to the IP address, not the domain name.
That means the organization that owns or manages the IP block is responsible for the reverse DNS zone. Depending on your infrastructure, this is typically your hosting provider, cloud provider, internet service provider (ISP), or data center.
For example, if you run a virtual machine on a cloud platform, you'll usually configure reverse DNS through the provider's networking or IP management settings rather than through your DNS registrar. Likewise, if your organization leases dedicated servers from a hosting provider, you'll often submit a PTR request through the provider's customer portal or support team.
Whether you can customize the PTR record also depends on the type of IP address you're using. With a dedicated IP address, providers generally allow you to configure a custom PTR record that points to your preferred hostname, such as mail.example.com. This is especially important for outbound email servers, where a meaningful hostname helps establish legitimacy with receiving mail systems.
With a shared IP address, however, the provider usually controls the PTR record because multiple customers use the same IP. In these environments, the reverse DNS entry may be generic or shared across many users, leaving little opportunity for customization.
Creating the PTR record and reverse zone
Setting up reverse DNS requires two components: a reverse zone and a PTR record. The reverse zone must be created and delegated to the authoritative nameservers responsible for the IP range, using in-addr.arpa for IPv4 or ip6.arpa for IPv6.
Once the zone exists, a PTR record maps the IP address to the chosen hostname, for example 1 IN PTR mail.example.com. Note that the trailing dot matters: without it, the hostname is treated as relative to the reverse zone and the record will not resolve correctly. Most administrators do not edit reverse DNS zone files directly. Instead, hosting and cloud providers typically provide an interface where users can assign a hostname to an IP address, and the provider manages the PTR record.
After configuration, changes may take time to propagate due to DNS caching. It is also best practice for the hostname to resolve back to the same IP address through an A or AAAA record, creating forward-confirmed reverse DNS (FCrDNS), which is especially important for email servers.
What is reverse DNS used for?
Reverse DNS often works quietly in the background, which makes it easy to overlook. In practice, however, it supports a wide range of operational tasks across networking, security, infrastructure management, and email systems.
While a reverse DNS lookup alone rarely provides a complete picture, it often supplies valuable context that helps administrators make faster, more informed decisions. The table below summarizes the most common use cases before we explore each in more detail.
Email deliverability and anti-spam
One of the most common uses of reverse DNS for email is helping receiving mail servers evaluate whether an incoming message is legitimate. Many mail servers perform a reverse DNS lookup on the sending IP address and check whether it has a valid PTR record pointing to a meaningful hostname.
For the major providers, this is now a stated requirement rather than a soft signal. Since February 2024, Google's sender guidelines have required all senders to ensure that sending domains or IPs have valid forward and reverse DNS records. Gmail enforces this at the SMTP level, rejecting mail from IPs without a valid PTR record with a 550 5.7.25 error and stating in the bounce text that it does not accept messages from IPs with missing PTR records. Beyond those provider policies, a missing or generic PTR record also weighs on sender reputation more broadly, because properly configured mail servers are expected to have identifiable reverse DNS.
A related concept is Forward-Confirmed Reverse DNS (FCrDNS). This occurs when the PTR hostname also resolves back to the same IP address through a forward DNS lookup:
203.0.113.25
↓ PTR
mail.example.com
↓ A
203.0.113.25
This forward-and-reverse match provides stronger evidence that the sender controls its DNS configuration. Some mail servers also compare the PTR hostname with the SMTP HELO/EHLO hostname as part of their filtering decisions.
Reverse DNS is only one part of email authentication. SPF, DKIM, and DMARC provide additional verification layers that work together to establish sender legitimacy. Tools that monitor sender health, including Allegrow, track authentication and reputation signals continuously, checking SPF, DKIM, and DMARC every hour so configuration drift is caught while it is still a quick fix.
For organizations sending from a dedicated IP address, configuring a matching PTR record is a necessary step rather than an optional improvement. Senders using shared IPs depend on their provider's reverse DNS setup, which is worth confirming directly rather than assuming it is correct.
One failure pattern is worth calling out because it is easy to miss. If your server has a valid IPv4 PTR record but also sends over IPv6 without a matching ip6.arpa PTR, receiving servers that prefer IPv6 will perform the reverse lookup against the IPv6 address and find nothing. Gmail commonly connects over IPv6 where it is available, so the result is rejections from Gmail while other providers accept the same mail, and an IPv4 lookup that looks correct when you test it. If your infrastructure has IPv6 enabled for outbound mail, configure PTR records for both address families or disable IPv6 sending.
Server and network logging
Log files become significantly easier to interpret when they contain meaningful hostnames instead of long lists of numerical IP addresses.
Operating systems, monitoring platforms, and log analysis tools commonly perform reverse DNS lookups to translate IP addresses into hostnames. Most web servers leave this disabled during logging, since running a DNS lookup on every request adds latency, so the translation is usually applied later when logs are reviewed rather than as each entry is written. Either way, the result is the same for whoever reads the log: an entry such as mail.example.com or db-west.internal.example.com immediately provides more context than 192.0.2.1 on its own.
This additional context helps administrators understand which systems are communicating, identify recurring traffic patterns, and investigate operational issues more efficiently. In large environments containing thousands of servers, meaningful hostnames also reduce the time required to audit logs and diagnose incidents.
For email senders, this cuts both ways. The hostname you publish in your own PTR record is what appears in the logs of every server you send to, including the receiving mail servers deciding whether to trust you.
Network troubleshooting and diagnostics
When network problems occur, identifying the system behind an IP address is often one of the first troubleshooting steps.
Reverse DNS can quickly reveal whether an address belongs to a mail server, a database server, a cloud instance, or another known system. Engineers frequently combine reverse DNS with tools such as ping, traceroute, and mtr to understand network paths and isolate connectivity issues.
For example, if several systems report failed connections to an unfamiliar IP address, a reverse DNS lookup may immediately indicate that the address belongs to a cloud provider, a content delivery network (CDN), or an internal corporate server. This context can significantly narrow the scope of an investigation before deeper packet analysis becomes necessary.
The same technique helps when diagnosing email delivery problems. A domain's MX record frequently points at a secure email gateway rather than the mailbox provider itself, and where the MX hostname is generic, resolving it and running a reverse lookup on the resulting IP will usually reveal which gateway sits in front. That distinction explains why some corporate domains behave unpredictably during delivery testing.
Security and threat investigation
Security teams also rely on reverse DNS during incident response and threat hunting. When firewalls, intrusion detection systems, or endpoint security tools detect suspicious traffic, analysts often begin by examining the IP address involved. A reverse DNS lookup may reveal that the address belongs to a residential ISP, a cloud hosting platform, a university, or a known business network.
That information helps analysts assess whether the activity appears expected or unusual. For example, inbound traffic from a public cloud provider may warrant closer investigation if no cloud-based services are expected to communicate with the environment.
However, it's important not to overestimate what reverse DNS can prove. A PTR record indicates who configured the reverse DNS entry, not necessarily who currently controls the system or whether it is trustworthy. Attackers can compromise servers with legitimate hostnames, while many harmless systems have no PTR record at all. Reverse DNS should therefore be treated as one investigative signal among many rather than definitive proof of legitimacy.
The reverse of this matters if you are the sender. A generic or provider-default PTR record gives analysts and filtering systems nothing to work with, which is part of why a meaningful hostname that matches your sending domain is worth configuring properly.
Analytics and visitor identification
Reverse DNS can also provide additional context about website visitors and network traffic. Some analytics platforms perform reverse DNS lookups to determine whether an IP address belongs to a commercial ISP, a corporation, a university, or a cloud provider. In B2B environments, this information may help organizations understand which companies are visiting their websites or accessing specific applications.
The results, however, should be interpreted carefully. Many organizations use internet providers or cloud platforms whose PTR records reveal only the service provider rather than the customer using the address. As a result, reverse DNS can sometimes identify the network owner without identifying the actual organization behind the traffic.
Senders hit the same limitation when interpreting the IP data attached to email engagement, where the recorded address often belongs to a proxy or a corporate gateway rather than the individual recipient.
IP address management
For organizations managing hundreds or thousands of IP addresses, reverse DNS contributes to better operational hygiene.
Maintaining accurate PTR records allows network teams to verify that hostnames match their assigned IP addresses, making inventories easier to audit and reducing the likelihood of configuration errors. This becomes particularly valuable during infrastructure migrations, data center consolidations, and cloud deployments where IP assignments change frequently.
Many enterprises incorporate reverse DNS validation into their broader IP address management (IPAM) processes to ensure DNS records remain synchronized with network documentation. Keeping forward and reverse DNS aligned reduces confusion for administrators while making troubleshooting, monitoring, and security investigations considerably more efficient.
This matters for teams sending mail across several IPs or subdomains. A single missing PTR record affects only the mail leaving that one address, which makes it easy to miss until deliverability drops for part of your volume and nobody can work out why.
Reverse DNS limitations and common issues
Despite its usefulness, reverse DNS has important limitations that every administrator should understand. A successful reverse DNS lookup provides valuable context, but it should never be interpreted as definitive proof of identity or trustworthiness.
One of the most common misconceptions is that every IP address should have a PTR record. In reality, not every IP address has a PTR record. Many residential connections, temporary cloud instances, and dynamically assigned addresses have no reverse DNS configured, which is normal and does not affect everyday internet usage.
Dynamic IPs can also make reverse DNS less reliable. Providers may assign generic or outdated PTR records that reveal little useful information and may no longer match the current user of the address.
Reverse DNS is also not a security guarantee. A PTR record only shows that someone with control over the IP block configured the hostname; it does not confirm that the system is legitimate or safe.
Finally, reverse DNS does not affect browsing speed. Websites rely on forward DNS to connect users to servers, while reverse DNS only runs when specifically requested by services such as email systems, logging tools, and security platforms.
Conclusion
A reverse DNS lookup resolves an IP address to its associated hostname using PTR records stored in the in-addr.arpa (IPv4) and ip6.arpa (IPv6) namespaces. You can check reverse DNS using tools such as dig, host, or nslookup, while setting it up requires configuring a PTR record through whoever controls the IP address block, such as a hosting provider, cloud provider, or ISP.
Although reverse DNS is not required for normal web browsing, it plays an important role in situations where identifying and validating systems matters. From email deliverability and server logging to network troubleshooting, security investigations, analytics, and IP management, rDNS provides valuable context that a raw IP address cannot.
For email servers in particular, a properly configured reverse DNS record is a baseline requirement at the major mailbox providers, and it supports broader authentication practices such as SPF, DKIM, and DMARC. It is one part of a wider sender reputation picture, but unlike many reputation factors it is a concrete configuration item that can be checked and fixed directly.
FAQs
What is a PTR record?
A PTR record is the DNS record type used for reverse DNS. It maps an IP address to a hostname, allowing DNS resolvers to identify the domain associated with that address.
How do I perform a reverse DNS lookup?
You can perform a reverse DNS lookup using command-line tools. On macOS and Linux, use dig -x <IP> or host <IP>. On Windows, use nslookup <IP>. You can also use an online reverse DNS lookup tool by entering the IP address you want to check.
What is the difference between forward and reverse DNS?
Forward DNS converts a domain name into an IP address, such as finding the server behind example.com. Reverse DNS does the opposite by converting an IP address back into a hostname.
How do I set up reverse DNS?
Reverse DNS is configured by adding a PTR record through the organization that controls the IP address block, such as your hosting provider, cloud provider, or ISP. It is not usually managed through your domain registrar. If you use a dedicated IP, you can typically configure a custom PTR record.
Does reverse DNS work with IPv6?
Yes, IPv6 reverse DNS works through the ip6.arpa namespace and uses a nibble-reversed format, where each hexadecimal digit of the address is reversed before the lookup.
What is FCrDNS (forward-confirmed reverse DNS)?
Forward-confirmed reverse DNS (FCrDNS) occurs when a hostname returned by a PTR record also resolves back to the same IP address through forward DNS. This creates a stronger consistency check and is commonly used by mail servers evaluating sender legitimacy.
Why is reverse DNS important for email?
Receiving mail servers use reverse DNS to evaluate whether a sending server appears legitimate, and for the major providers it is a requirement rather than a preference. Google has required valid forward and reverse DNS records from all senders since February 2024, and Gmail rejects mail from IPs without a valid PTR record. A missing or generic PTR record also contributes to spam filtering more generally. Reverse DNS works alongside other email authentication methods such as SPF, DKIM, and DMARC.
Does reverse DNS affect browsing speed?
No, reverse DNS does not affect normal browsing speed because browsers rely on forward DNS lookups to find websites. Reverse DNS only runs when a system specifically requests it, such as during email checks, logging, troubleshooting, or security analysis.
.jpg)