Definition
A PTR (Pointer) record, also known as reverse DNS (rDNS), maps an IP address back to a domain name — the opposite of an A record which maps a domain to an IP. When a mailbox provider receives an email, it performs a reverse DNS lookup on the sending IP address, then checks that the returned domain matches the hostname used in the HELO/EHLO command. If the PTR record is missing, misconfigured, or does not match the HELO hostname, the receiving server may reject the message or flag it as spam.
Gmail, Outlook, Yahoo, and virtually all major mailbox providers perform PTR checks on every incoming connection. For dedicated sending IPs, a valid PTR record is effectively mandatory. Shared IP pools typically handle this through the ESP's infrastructure, but dedicated IP owners must configure PTR records through their hosting provider or data centre. The PTR record must resolve to a domain that then resolves back to the original IP (forward-confirmed reverse DNS or FCrDNS), creating a verifiable chain.
The PTR record format requires the domain to be in fully qualified domain name (FQDN) form ending with a trailing dot. For example, mail.your-sending-domain.com. not your-sending-domain.com. The domain used in PTR should also appear in the SPF record and DKIM signing domain for consistency. Setting up PTR is typically done through your IP provider's control panel or by submitting a support ticket, as it requires modifying reverse DNS zone files controlled by the IP block owner.
Best Practices
Set the PTR record to a subdomain of your sending domain, such as mail-marketing.yourdomain.com, rather than the root domain. This maintains the reputation isolation benefit of subdomain strategies while satisfying reverse DNS requirements. The PTR domain should match the hostname sent in the HELO/EHLO command.
Ensure forward-confirmed reverse DNS (FCrDNS) is configured: the PTR lookup on your IP returns a domain, and an A record lookup on that domain returns the original IP. If these do not match, some receiving servers treat it as a PTR failure. Test with dig -x [your-ip] for the reverse lookup and dig A [your-domain] for the forward lookup.
Use the same organisational domain for PTR, HELO/EHLO, and your From: address domain. If your From: address is newsletter@yourdomain.com, set HELO to mail.yourdomain.com and PTR to mail.yourdomain.com. Consistency signals legitimacy to mailbox providers.
Check PTR configuration before sending any emails from a new IP. Run dig -x [IP] +short and confirm it returns the expected hostname. If it returns nothing or a generic ISP hostname (e.g., pool-123-45-67-89.example.net), submit a PTR change request to your hosting provider.
Test PTR with multiple DNS resolvers. Different mailbox providers use different resolvers, and propagation delays can cause inconsistent results. Wait 24-48 hours after PTR setup before sending significant volume to allow global DNS propagation.
Frequently Asked Questions
Related Glossary Terms
Frequently Asked Questions
No, you should use your own domain. Using a shared ESP domain ties your reverse DNS reputation to other senders on that domain. A custom PTR record with your own domain gives you independent reputation control.
Deliverability drops significantly. Gmail, Outlook, and Yahoo may reject your emails or route them directly to spam. Many receiving servers apply a negative reputation score to IPs without valid PTR records, making it very difficult to reach the inbox.
PTR records are managed by the owner of the IP address block, typically your hosting provider or data centre. Most providers offer a form in their control panel or require a support ticket. Provide the IP address and the desired hostname (FQDN format).
Shared IP pools already have PTR records configured by the ESP. You do not need to set up PTR for shared IPs. The ESP's PTR resolves to a domain they control. Your focus should be on SPF, DKIM, and DMARC for shared IP setups.
PTR record propagation typically takes 24-48 hours across the global DNS system, longer than forward DNS records because reverse DNS zones are cached differently. Verify with `dig -x [IP]` from multiple resolvers before expecting consistent behaviour.