Reverse DNS (rDNS, Reverse DNS) is the mechanism that lets you look up the domain name tied to an IP address. It is the opposite of ordinary DNS (name → IP). The PTR record is the main record type in reverse DNS.
Why rDNS Is Needed
- Mail servers — most MTAs (Postfix, Exim) check the PTR record. Without a PTR, messages are rejected or land in spam
- Network diagnostics — traceroute shows host names instead of IP addresses
- Server logs — a readable name is shown instead of a bare IP
- Provider trust — some services block IP addresses that have no PTR
The Difference Between A and PTR
| Record | Direction | Example |
|---|---|---|
| A record | Name → IP | mail.example.com → 192.168.1.1 |
| PTR record | IP → Name | 192.168.1.1 → mail.example.com |
Setting Up PTR on a ZevsHost VPS
- Log in to the Client Area → VPS → select the server
- The "Network" section → "Reverse DNS"
- Enter the fully qualified domain name (FQDN):
mail.example.com - Save — the PTR record updates within a few minutes
Checking the PTR Record
# Direct PTR lookup
nslookup 192.168.1.1
# Using dig
dig -x 192.168.1.1
# Expected answer:
# 1.1.168.192.in-addr.arpa. 3600 IN PTR mail.example.com.PTR for Mail Servers — Checklist
- A PTR record is configured for the mail server IP
- The PTR matches the HELO name in Postfix/Exim
- An A record for the PTR name exists and points to the same IP (forward-confirmed rDNS)
- SPF and DKIM are configured on top of that
Common PTR Errors
| Message or symptom | Cause | Fix |
|---|---|---|
| 550 5.7.1 Client host rejected: cannot find your reverse hostname | No PTR record at all is configured for the sending server's IP | Configure the PTR through the VPS panel, or ask the provider if you do not manage the IP directly |
| 450 4.7.1 Client host rejected: Reverse DNS mismatch | The PTR is set, but it resolves to a name that has no A record pointing back to the same IP (no FCrDNS) | Add an A record for the PTR name that points exactly to the mail server's IP |
| The PTR shows the hosting provider's name instead of your domain | The IP is leased from the provider, and the default PTR points to a generic name like vps123.provider.net | Change the PTR to the desired value through the VPS/dedicated server control panel |
| dig -x returns NXDOMAIN right after the change | The PTR change has not propagated yet — reverse zones (in-addr.arpa) are updated on the provider's side, not instantly | Wait 15-60 minutes and check again; PTR propagation is usually faster than for regular records |
PTR for IPv6
For IPv6 the reverse zone is called ip6.arpa instead of in-addr.arpa, and the record consists of the full address expanded into nibbles in reverse order.
# Checking the PTR for an IPv6 address
dig -x 2001:db8::1
# Expected answer (partial):
# 1.0.0...8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR mail.example.com.If the mail server sends over both IPv4 and IPv6, the PTR must be configured for both addresses separately. Having a correct PTR only for IPv4 will not prevent rejections if the same server can also send mail over an IPv6 connection.
When a PTR Will Not Help
- The IP sits in a public block previously seen sending spam — IP reputation matters more than having a PTR, and some filters will reject the mail regardless
- The domain's SPF record does not include the sending server's IP — a PTR does not replace SPF, both mechanisms are checked independently
- DKIM is not configured at all — major mail providers (Gmail, Outlook) in 2024-2025 require DKIM for bulk sending regardless of the PTR
- The PTR is set, but the server's HELO name does not match it — some strict MTAs check exactly that match, not merely whether a PTR exists
A PTR is only part of sender reputation. The full set of mail records is covered in MX and SPF setup for a domain.
PTR Record TTL and Its Practical Impact
Like any DNS record, a PTR record has a TTL — providers usually set it in the 3600-86400 second range. For mail servers this means that after a PTR change, some receiving servers will keep seeing the old value until that TTL expires, even though the record in the zone has already been updated. This differs from changing a site's A record: a PTR mistake does not just break visual display, it can cause mass message rejection for the entire duration of the stale cache.
Before migrating a mail server to a new IP, it is worth lowering the PTR record's TTL to 300-600 seconds ahead of time, if the provider allows it, to shrink the window during which messages might be rejected due to desynchronization.
Frequently asked questions
If a mail server sends over both IPv4 and IPv6, do I need separate PTR records for each address?
Yes, a PTR is tied to a specific IP address rather than to the server, so a record set for IPv4 doesn't carry over to IPv6. If the server can send mail over both protocols but the reverse record only covers IPv4, some messages will still get rejected by receiving servers when delivery happens over the IPv6 connection.
How long does it actually take for an updated PTR record to take effect?
The record in the reverse zone itself usually updates on the provider's side fairly quickly, but receiving mail servers keep seeing the old value for a while until the TTL on their cached answer expires. So right after a PTR change, some mail may still get checked against the previous value, and that alone doesn't mean the change failed.
Will a correct PTR help if the IP address previously showed up sending spam?
Not entirely — a PTR is only one piece of sender reputation, and major mail filters look first at the IP address's own history. If the address is on blocklists because of a previous owner, a correct reverse record will cut some rejections but won't override the reputation check, and some mail will land in spam or get rejected.
Does the server's PTR name have to match the site's domain?
No, that isn't required for the site — a PTR matters for the mail server and needs to match the HELO name that Postfix or Exim presents when connecting to another server. That name can differ from the site's domain: what matters is that it matches the HELO and has a matching A record pointing back to the same IP.