A reverse DNS lookup takes an IP address and returns the hostname registered to it. Forward DNS turns unspam.email into an IP address; reverse DNS does the opposite, using a PTR record published by whoever owns the IP block.
It matters most for email. Receiving mail servers check whether your sending IP has a reverse DNS record before they decide what to do with your message, and a missing record is treated as a strong signal of a misconfigured or disposable sender. Across the sending IPs we test, 99% have valid reverse DNS, so the 1% without it stand out immediately.
This guide covers what reverse DNS is, how to run a lookup from the command line or a browser, and how to create the PTR record itself.
What is reverse DNS?
Reverse DNS is the lookup that determines the hostname associated with a given IP address. Forward DNS does the reverse, retrieving an IP address from a hostname.
DNS itself is the Domain Name System, the phonebook of the Internet, and it works in both directions because both humans and machines need to read it. Forward lookups are the ones you use every day without noticing. Reverse lookups are the ones mail servers use to decide whether to trust you.
Not every IP address has a reverse entry, because DNS keeps working without one. For years that made reverse DNS a recommendation rather than a requirement. For mail that is no longer true: starting in November 2026, Spamhaus is gradually rolling out a requirement that every sending IP has a valid HELO name, a PTR record and a matching A record.
Press play to load this video from YouTube (Google). See our cookie policy.
How does reverse DNS work?
A resolver reverses the IP address, appends the reverse-zone suffix, and asks DNS for the PTR record at that name. The steps are:
- The resolver writes the IPv4 address backwards and appends
.in-addr.arpa, so203.0.113.25becomes25.113.0.203.in-addr.arpa. An IPv6 address is written out in full, reversed one hex digit at a time and given.ip6.arpainstead. - It asks DNS for the PTR record at that name. The answer comes from the nameservers of whoever controls the reverse zone, which is normally the owner of the IP block, not the owner of the domain.
- If a PTR record exists, its value is the hostname. If none exists, the answer is empty and the address has no reverse name.
A lookup that returns nothing is not an error. It means no PTR record is published for that address, which is common on consumer broadband and on shared hosting, and which is exactly the state receiving mail servers treat as suspicious.
Let us consider some good reasons why reverse DNS is important.
The basic principle of reverse DNS lookup
Why reverse DNS matters for the mail you send
Reverse DNS is one of the cheapest trust signals a sender can publish, and one of the few that is checked before your content is ever examined. Three things depend on it.
Mail acceptance
Similar to SPF, DKIM, and DMARC, reverse DNS is used to separate legitimate senders from throwaway infrastructure. Mail servers look up the sending IP, and many reject or heavily penalise a connection when no PTR record comes back, on the reasoning that a serious sender controls its own IP block and a spammer usually does not. The strictest receivers also require forward-confirmed reverse DNS, where the hostname in the PTR record resolves back to the same IP.
Reverse DNS is only one signal they weigh, though: the IP's standing on blocklists matters just as much, and across the sending IPs we test 6% turn up on an IP blacklist. If you want to see exactly which IP a message was sent from and how the receiving server judged it, run a suspect message through our email header analyzer.
Spam filtering and abuse tracing
Reverse DNS lies at the core of several long-standing anti-spam techniques. A receiving server that can resolve a connecting IP to mail.yourcompany.com treats it very differently from one that resolves to nothing, or to a generic ISP hostname like host-92-14-233-8.dynamic.example.net. The same lookup is what lets abuse desks and security teams identify the operator behind an IP that is sending malicious email, probing a firewall, or attempting to break into a system.
Readable logs and diagnostics
Server logs, traceroutes and monitoring tools resolve IPs to hostnames so a human can read them. Without reverse DNS your traffic appears in everyone else's logs as a bare number, which makes your own troubleshooting slower and makes you look anonymous to anyone investigating an incident.
What reverse DNS does not do. It does not tell you who visited your website, which pages they read, how long they stayed, or what device they used. That information comes from web analytics, and the company-level attribution some vendors sell on top of it comes from commercial IP-to-organisation databases, not from a PTR record. A reverse lookup returns one hostname and nothing else.
Reverse DNS is optional for the protocol and mandatory in practice
Reverse DNS is not required for DNS to function, which is exactly why so many senders skip it and why skipping it is expensive. The IETF expects every address to be resolvable, but a missing PTR record breaks nothing technically, so nothing forces the issue until your mail starts bouncing.
The deal is that mail servers and ISPs verify reverse DNS setup when deciding what to do with email from your server. They check whether the IP address of the sending server has a reverse DNS record. Most servers consider it fraud if there is no record and reject emails from this source without any ado. This is now an established norm: across the sending IPs we test, 99% have valid reverse DNS, so the 1% that lack it stand out immediately to receiving servers.
Suppose you run email marketing campaigns and constantly reach your subscribers through this channel. In that case, the absence of a reverse DNS setup may become a real roadblock since your emails will be rejected without any valid reason. Therefore, it is highly recommended to set up reverse DNS for your domain to ensure a high deliverability rate for your email.
In addition, with reverse DNS in place, you contribute to the community and address common security issues. The basic setup may help other units to identify potential threats and fight cybercrime more efficiently, thereby creating a safe and transparent ecosystem for you and your customers.
Spamhaus requires FCrDNS and a matching HELO from November 2026
Spamhaus now publishes Sender Guidelines that turn reverse DNS from a convention into a stated requirement. The page says that, starting in November 2026, Spamhaus is gradually rolling out a requirement for every sending IP to have a valid HELO, a reverse DNS (PTR) record and a matching A record. It lists these checks among the minimum requirements every sender must meet "to avoid being listed".
What the minimum requirements ask of each sending IP, as of 7 November 2026:
| Requirement | What Spamhaus asks for |
|---|---|
| PTR record | A reverse DNS entry for every sending IP that points to a fully qualified domain name |
| Forward confirmation | That hostname resolves back to the same IP, which is forward-confirmed reverse DNS (FCrDNS) |
| HELO/EHLO name | A hostname that resolves to the sending IP and stays the same across connections |
| No placeholder names | Placeholders such as localhost, hosting-provider defaults and names that change between connections count as signs of misconfiguration or compromise |
| IPv6 | Sending from an allocation of /64 or larger, with valid reverse DNS |
Spamhaus also recommends branded reverse DNS on your own domain rather than a generic hosting name, and its guidelines for ESPs and large senders put the whole rule in one line: the HELO, the PTR and the A record should all use the same hostname.
The page names the consequence as well. A placeholder, default or changing HELO name can result in a listing, and failing these infrastructure basics can get an IP listed on the Spamhaus CSS or XBL zones. Our guide to Spamhaus delisting covers what each of those lists means for removal, and our breakdown of the Spamhaus Sender Guidelines covers the rest of the page, from bounce rates to authentication.
In practice one hostname does all three jobs. If your server sends from 187.133.11.219 as mail.example.com, the PTR for 187.133.11.219 returns mail.example.com, the A record for mail.example.com returns 187.133.11.219, and the server greets every receiver with EHLO mail.example.com. The setup steps below produce exactly that state.
How to perform reverse DNS lookup?
There are two ways to run a reverse DNS lookup: a single command on your own machine, or a web-based tool if you would rather not touch a terminal.
The first way implies the utilization of the command line. Since most operating systems (Linux, macOS, and of course Windows) can send requests to the Domain Name System to get a hostname based on an IP address, you can easily use some help of your PC or notebook.
For instance, Windows users can use such commands as “ping” or “nslookup.” The sample query looks like this:
ping -a w.x.y.z
or
nslookup 7.7.7.7
If a PTR record is published, these commands return its hostname.
On macOS and Linux, you can use the “dig” command followed by the “-x” flag and IP address, like this
dig -x 7.7.7.7
If the command line scares you, a browser-based lookup gives you the same answer.
Three tools that run a reverse DNS lookup in a browser
Unspam, MxToolBox and WhatIsMyIP all resolve an IP to its hostname without a terminal, and all three are free for this check.
- Unspam IP blacklist checker. Enter a sending IP and, above the blocklist results, it shows the PTR hostname and whether that hostname resolves back to the same address, so you see forward confirmation and not just a name. Pair it with an MX record lookup to see which servers receive your domain’s email, which are often not the ones that send it.
- MxToolBox. MxToolBox is another multitasking diagnostic service. Although most of its tools come with a fee, the reverse DNS lookup is available free of charge. Just enter the IP address either in an IPv4 or IPv6 format and enjoy the results.
- WhatIsMyIP. Runs both forward and reverse lookups from the same box. Enter the IP address and it returns the PTR hostname.
How to set up reverse DNS in seven steps
Setting up reverse DNS means getting a PTR record published for your sending IP, giving the hostname it names an A record that points back to the same IP, and using that hostname as your HELO name. On most cloud servers and VPS plans the provider publishes the PTR for you, from its control panel or through a support ticket, so steps 2 to 4 apply only when a block of addresses is delegated to you to run yourself. You need a dedicated IP address for any of this: on shared hosting the PTR record belongs to your provider and you cannot change it.
Step 1: Gather Necessary Information
The first thing to do in order to set up reverse DNS is to figure out who your hosting provider is and whether you have access to DNS.
In the majority of cases, your hosting provider or ISP owns your IP block. However, if this is not the case, you can determine who the owner is by using free third-party services like IP WHOIS Lookup.
Step 2: Define Reverse DNS Zone Name
After you define the owner of the IP block, you need to contact it and request a zone for your mail server’s IP address.
You may notice that this zone ends in “in-addr.arpa” and features an IP block with the octets reversed. This is an official syntax that you need to use to create your own reverse DNS zone.
The format is straightforward: it starts with an IP address with octets reversed and ends with “.in-addr.arpa”.
Follow this simple 5-step routine to define your reverse DNS zone name:
- Take the first address of your block, not the address of your mail server.
- If it is a full /24 block, omit the last octet. If it is a classless block, keep all four octets and set the netmask aside.
- Reverse the order of the remaining octets.
- Add ‘in-addr.arpa’ to the end.
- If it is a classless block, add the netmask back to the first label. RFC 2317 writes it with a slash and suggests a hyphen as the safer character, so use whichever form your block owner asks for.
Consider the example to get a complete understanding of the procedure.
For example, your mail server is 187.133.11.219 and it sits in the block 187.133.11.192/27, the 32 addresses from .192 to .223. It is a classless block, so start from its first address and set aside the netmask, aka “/27”.
So, now you have 187.133.11.192
After that, reverse the order of the octets: 192.11.133.187
Then, add “.in-addr.arpa”: 192.11.133.187.in-addr.arpa
Finally, bring back the netmask using the hyphen: 192-27.11.133.187.in-addr.arpa
The PTR record for your server then lives at 219.192-27.11.133.187.in-addr.arpa, and the block owner points the standard name 219.11.133.187.in-addr.arpa at it with a CNAME record, which is the arrangement RFC 2317 describes.
Step 3: Request Reverse DNS Delegation
Ask your ISP to delegate reverse DNS to your DNS provider. For this, you need to provide your ISP with the nameservers for your domain.
The nameserver for your domain could be found via a free tool called Dig Web Interface Tool.
If a hosting provider or ISP cannot delegate the reverse DNS, it will probably do everything by itself. Therefore, you can leave the reverse DNS setup to the supporting team and skip the next steps.
Step 4: Create Reverse DNS Zone
Log into your hosting provider and find the DNS Menu in the control panel.
Click on it and select “Manage DNS.” It may be called something similar.
Click “Add domains.”
Enter the reverse DNS zone name that we have defined in step 2.
Step 5: Create PTR Record
After you have created the zone, create one PTR record in it for each sending IP. Open the corresponding tab. Depending on your provider, it may be called a “PTR record” or something alike.
Enter the last octet of the IP address into the “name” field, for example 219 for 187.133.11.219.
Enter a fully qualified hostname as the value, such as mail.example.com: not the bare domain and not your provider’s generic name. Pick a hostname in a domain you control, because the next step needs an A record for it.
Step 6: Point the hostname back at the IP and use it as your HELO
A PTR record is only half of the check. In your domain’s normal DNS zone, publish an A record (and an AAAA record for an IPv6 sender) so that mail.example.com resolves to the same sending IP. That is what makes the reverse DNS forward-confirmed. Then set the HELO or EHLO hostname of your mail server to exactly that name. If you send from several IPs, give each one its own hostname, and never let the name change between connections.
Step 7: Confirm the record, do not just wait
Propagation is governed by the TTL on the zone, so a new PTR record is usually visible within minutes to a few hours rather than the two days the old advice suggests. Allow up to 24 hours before assuming something is wrong, and re-run the lookup to confirm rather than waiting blind.
Confirm both directions, not only the PTR:
dig -x 187.133.11.219 +short
dig A mail.example.com +short
The first should return mail.example.com. and the second 187.133.11.219. Then send yourself a test message and read the Received header your mailbox added: the name right after from is the HELO your server announced, and it should be the same hostname.
DNS Record for Unspam.email
One hostname in three places is the whole job
Reverse DNS costs one PTR record, one A record and one line of mail server configuration, and it buys you the benefit of the doubt from every receiving mail server, which is why 99% of the sending IPs we test already have it.
Find out who owns your IP block, ask them to delegate the reverse zone, publish a PTR record that points at a hostname you control, give that hostname an A record that resolves back to the same IP, and make it the name your server uses in HELO. That is the state Spamhaus’s November 2026 rollout checks for. Then run a free spam test to see how the receiving side now reads your mail, and check the email headers of a real message to confirm the PTR is being returned.
