Reverse DNS maps an IP address back to a hostname. Mail servers use it as a quick plausibility check on whoever is connecting: does this IP belong to something that looks like a real mail server, or to an anonymous dynamic address? A missing or mismatched PTR record is one of the most common reasons self-hosted or newly deployed mail servers are rejected outright, often with an error that mentions "PTR" or "reverse DNS". It is also one of the simplest things to fix once you know who controls it.
What a PTR record is
A normal (forward) lookup turns mail.example.com into 203.0.113.25. A reverse lookup does the opposite using a special zone. The IP is written backwards under in-addr.arpa:
25.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.For IPv6, the address is expanded to its 32 hex digits, reversed nibble by nibble, under ip6.arpa. Nobody does this by hand; use a tool:
dig -x 203.0.113.25 +short
# mail.example.com.
dig -x 2001:db8::25 +shortYou can also run the IP लुकअप, which includes reverse DNS information for an address.
Forward-confirmed reverse DNS (FCrDNS)
Receivers do not just ask "does a PTR exist?" They run a round trip:
- Reverse-lookup the connecting IP to get a hostname.
- Forward-lookup that hostname to get IP addresses.
- Check that the original IP is among them.
If this loop closes, the IP has forward-confirmed reverse DNS. If the PTR says mail.example.com but mail.example.com resolves to a different IP (or nothing), the check fails. The ideal setup is a loop:
203.0.113.25 --PTR--> mail.example.com --A--> 203.0.113.25For servers with IPv6, each address needs its own PTR and AAAA match. A mail server that connects over IPv6 without proper rDNS is rejected by receivers who check it, which is a common surprise when a dual-stack host starts preferring IPv6. Either complete the IPv6 reverse setup or make your MTA send over IPv4 only.
Why receivers care
- Gmail states in its sender guidelines that sending IPs must have PTR records, and it rejects mail from IPs without them, with an error such as
550 5.7.25 The IP address sending this message does not have a PTR record. Many other receivers apply the check too, whether as a hard reject or as a spam signal. - Generic ISP-style names (strings containing the dashed IP such as
203-0-113-25.dyn.example.net) suggest a consumer connection or an unmanaged server, and many filters penalize that. - It gives abuse investigators a hostname to contact.
Reverse DNS does not prove who you are the way SPF and DKIM do. It is a baseline hygiene check. A missing PTR makes you look sloppy; a good one alone will not earn trust. Combine it with the authentication in the SPF, DKIM and DMARC guide.
Who controls the PTR record
This is the point that trips people up: the reverse zone belongs to whoever owns the IP block, not to you. Your domain's DNS provider cannot publish a PTR for an address you rent. You request or set it with the party that allocates the IP:
| Where your IP comes from | How to set the PTR |
|---|---|
| VPS or cloud instance | Usually a setting in the provider's control panel (often called "reverse DNS", "rDNS" or "PTR") or a support request. Cloud platforms differ, so check your provider's documentation; some require the forward A record to exist first |
| Dedicated server or colocation | Control panel or support ticket with the provider |
| Business internet line with a static IP | Ask the ISP to set it. Residential and dynamic IPs generally cannot have custom PTRs, and many receivers block them for mail anyway |
| Managed email service or SMTP relay | Handled by the provider; you do not configure it |
| Your own IP block | You or your registry sub-delegate the reverse zone and publish PTRs yourself |
If you use a hosted provider such as Google Workspace or Microsoft 365, the sending IPs and their PTRs are the provider's, so this guide applies only when you operate the mail server or relay.
Setting it up, step by step
Assume a mail server at 203.0.113.25 and the hostname mail.example.com.
- Pick the hostname. Use a name under a domain you control, such as
mail.example.com, that is dedicated to this server. Avoid your web server's name if the web and mail IPs differ. - Create the forward record:
mail.example.com. 3600 IN A 203.0.113.25- Set the PTR with the IP owner so that
203.0.113.25returnsmail.example.com. - Set the HELO/EHLO name in your mail server to the same hostname. In Postfix:
# /etc/postfix/main.cf
myhostname = mail.example.com
smtp_helo_name = mail.example.comIn Exim, set primary_hostname (and optionally helo_data for outgoing). Reload the service after editing.
- Verify the loop:
dig -x 203.0.113.25 +short # mail.example.com.
dig +short A mail.example.com # 203.0.113.25- Check IPv6 if the server has an address. Add an AAAA record and PTR, or disable IPv6 for outbound mail.
- Send a test to the ईमेल डिलीवरेबिलिटी टेस्ट and look at the
Received:and authentication lines.
Alignment of the names
Three names often appear in a single message, and it helps to know which is which:
- PTR name: what the IP resolves to (
mail.example.com) - HELO/EHLO name: what your server announces at the start of the SMTP session
- Envelope sender and From domain: your domain, used for SPF and DMARC
Best practice is for the PTR name and HELO name to be identical and resolvable. They do not have to match the From domain, so a hosting company can send for many customers from mail.hosting.example. SPF can also check the HELO name; a valid SPF record for the HELO hostname makes bounces authenticate properly.
Shared hosting, multiple domains and one IP
One IP can have only one conventionally useful PTR name, though technically several PTR records can exist, and receivers handle that inconsistently, so stick to one. Pick a neutral hostname for the server; it is not visible to recipients and does not need to match every domain you host. What matters is that it is consistent and resolves back.
Common problems
| Symptom | Cause | Fix |
|---|---|---|
5.7.25 or "no PTR" bounce | PTR not set | Request it from the IP owner |
PTR is generic like static-203-0-113-25.isp.example | Default ISP name | Ask for a custom value; accept that residential lines often cannot |
| PTR set, forward does not match | A record missing or pointing elsewhere | Fix the A/AAAA record |
| Works on IPv4, fails on IPv6 | No IPv6 rDNS | Add it or prefer IPv4 for outbound |
HELO says localhost or an internal name | MTA defaults | Set myhostname |
| Delivery still blocked | Blocklist or reputation issue | Check the Blacklist Checker |
If your mail server's address recently changed, remember that the old reverse entry and any listings do not follow you. A fresh IP also has no history; see warming up a new domain.
अगले कदम
- Look up your sending address with the IP लुकअप and confirm the reverse entry.
- Not sure of your outbound IP? Use What Is My IP from the server.
- Check the IP against blocklists with the Blacklist Checker.
- Review the spam diagnostic checklist for what else receivers check.
- Decode rejections with email bounce codes explained.
सामान्य प्रश्न
Do I need a PTR record if I use Google Workspace or Microsoft 365?
No. The provider's servers send your mail from their own IPs with their own reverse DNS. You only manage PTR records for IPs you operate.
Where do I add a PTR record?
With whoever owns the IP address, usually your hosting provider or ISP, not at your domain registrar or your domain's DNS host.
Does the PTR hostname have to match my domain?
Not necessarily, but it must resolve back to the same IP, and it is better to use a hostname under a domain you control than a generic provider name.
Can an IP have multiple PTR records?
It is technically allowed, but behavior varies between receivers, so use a single PTR that matches your HELO name.
Get notified when this guide updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.