Normal DNS answers the question "what is the IP address of this name?". Reverse DNS answers the opposite: "what name belongs to this IP address?". A reverse DNS lookup rarely matters for a website, but for anyone running their own mail server it is essential. Many receiving mail servers will delay or reject messages from an IP address that has no reverse DNS, or whose reverse DNS looks like a home broadband connection.
How reverse DNS works
Reverse lookups use a record type called PTR (pointer), stored in special zones under the domain in-addr.arpa for IPv4 and ip6.arpa for IPv6. The IP address is written backwards, octet by octet, so that the hierarchy runs from general to specific just like an ordinary domain name. For the address 203.0.113.25, the PTR record lives at:
25.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.For IPv6, every hexadecimal digit (nibble) of the full address is reversed and separated by dots, which produces a very long name. You rarely type these by hand; tools and control panels build them for you.
Who controls your PTR record
This is the part that confuses most people. A PTR record is not in your domain's DNS zone. It is in the reverse zone for the IP address, and reverse zones are delegated to whoever owns the IP block: your hosting company, cloud provider or internet service provider. You cannot add a PTR record in the same control panel where you manage your A and MX records.
To set or change it you usually:
- On a cloud server or VPS: look for a "reverse DNS" or "rDNS" field next to the server's IP address in the provider's dashboard. Most major providers offer one, sometimes only after you have created a matching A record.
- On a dedicated server or colocation: raise a ticket with the hosting provider.
- On a business internet connection with a static IP: ask the ISP. Consumer connections with dynamic IPs usually cannot have a custom PTR at all.
How to do a reverse DNS lookup
From the command line:
dig -x 203.0.113.25 +short
nslookup 203.0.113.25
Resolve-DnsName 203.0.113.25dig -x builds the in-addr.arpa name for you. If the answer is empty or NXDOMAIN, there is no PTR record. Not sure what your server's public address is? Run What is my IP from the server's network, or check the hosting dashboard.
Why mail servers check reverse DNS
Large amounts of spam come from infected home computers and cheaply rented servers that nobody has configured properly. Legitimate mail servers are normally set up deliberately, by someone who also arranged a proper PTR record. Receiving servers use reverse DNS as an inexpensive signal of that care. The checks typically include:
- Does a PTR record exist at all? No PTR is a strong negative signal, and some receivers reject outright.
- Does it confirm forward? This is called forward-confirmed reverse DNS (FCrDNS): the PTR name, looked up as an A or AAAA record, should return the same IP address.
- Does it look generic? Names like
203-0-113-25.dynamic.isp.examplesuggest a residential connection and attract spam filtering. - Does it relate to the HELO name? The name your server announces in the SMTP
HELOorEHLOcommand should ideally match the PTR.
Google's published sender guidelines, for example, require that sending IP addresses have valid forward and reverse DNS. Other large mailbox providers apply similar checks.
Setting it up correctly for a mail server
Here is a consistent configuration for a server at 203.0.113.25 sending mail for example.com:
| Item | Where it is set | Value |
|---|---|---|
| A record | Your DNS zone | mail.example.com → 203.0.113.25 |
| PTR record | Hosting/IP provider | 203.0.113.25 → mail.example.com |
| HELO/EHLO name | Mail server config (e.g. myhostname in Postfix) | mail.example.com |
| SPF | Your DNS zone (TXT) | Includes ip4:203.0.113.25 or a:mail.example.com |
A few practical points:
- Create the forward A record first and confirm it with a DNS lookup; some providers will not accept a PTR until the matching A record resolves.
- Use a single PTR record per IP address. Multiple PTRs are allowed by DNS but confuse some checks.
- The PTR name does not have to be the same domain as every address you send from. One server sending mail for several domains needs only one sensible PTR, and SPF, DKIM and DMARC take care of authorising each domain.
- If your server also has an IPv6 address and sends over IPv6, it needs a PTR for that address too. Missing IPv6 reverse DNS is a common reason for rejections from receivers that check it strictly.
Do you need reverse DNS if you use a hosted email service?
If your email is handled by Google Workspace, Microsoft 365 or another hosted provider, their sending servers already have correct reverse DNS. You do not need to do anything. It matters when you run your own mail server, send from an application server directly (for example, a web app sending password resets through a local MTA), or use a dedicated IP with a transactional email service, in which case the service usually sets the PTR for you or tells you how.
Reverse DNS is also used outside email: in server logs, by some security tools, and in network diagnostics such as traceroute, where it makes hops readable. None of those are as strict as mail filtering, though.
Key takeaways
- A reverse DNS lookup maps an IP address to a name using a PTR record in the
in-addr.arpaorip6.arpazone. - PTR records are controlled by whoever owns the IP address, usually your hosting provider or ISP, not your domain's DNS host.
- Mail servers expect a PTR that exists, resolves back to the same IP, and matches the server's HELO name.
- If you use a hosted email provider, reverse DNS is already handled for you.