Reverse DNS (rDNS): Why It Matters for Email Deliverability
Most DNS discussion focuses on forward resolution — looking up a domain name to find its IP address — but the reverse direction, looking up an IP address to find its associated hostname, plays a specific, often overlooked role in email deliverability that catches many self-hosted mail server operators (discussed in more depth elsewhere on this blog) off guard, since it's a configuration step that lives outside the domain owner's own DNS control entirely.
What Reverse DNS Actually Is
While a standard "forward" DNS lookup answers "what IP address does this domain point to," reverse DNS answers the opposite question: "what hostname is associated with this specific IP address." This is implemented through a PTR (pointer) record, and critically, unlike virtually every other DNS record type discussed throughout this series, a PTR record for a given IP address is controlled by whoever owns that IP address block — typically the hosting or cloud provider — not by the domain owner using that IP.
Why Receiving Mail Servers Specifically Check This
Many mail servers, as part of their broader spam-filtering process, check whether an incoming connection's source IP address has a valid, properly configured PTR record, and further, whether that PTR record's hostname makes sense in relation to the domain the mail claims to be from — this check exists specifically because legitimate, well-run mail infrastructure is expected to have this reverse mapping properly configured, while a large share of spam and malicious traffic historically originated from infrastructure where this configuration step was simply never bothered with, making its absence a genuinely useful, if imperfect, spam signal.
The Specific Failure Mode for Self-Hosted Mail Server Operators
This is precisely where self-hosted mail server operators frequently encounter friction: because PTR records are controlled by the IP address's owner (the hosting or cloud provider) rather than the domain owner running the mail server, simply configuring your own domain's DNS correctly — SPF, DKIM, DMARC, all discussed elsewhere on this blog — doesn't automatically ensure the underlying server's IP address has an appropriate, matching PTR record configured at all. Many budget VPS and cloud providers assign a generic, provider-branded default hostname as the PTR record (something like server123.hostingprovider.com) rather than anything related to the domain actually being used to send mail, and this mismatch itself can contribute to reduced deliverability, independent of anything else being correctly configured on the domain owner's own side.
How to Actually Fix a Mismatched or Missing PTR Record
Unlike other DNS records covered throughout this series, fixing a PTR record requires contacting the hosting or cloud provider directly (or using their control panel's specific reverse DNS configuration option, where offered) rather than making a change through your own domain's DNS management interface — this is a genuinely important distinction, since a self-hoster who spends considerable time perfecting their own domain's SPF, DKIM, and DMARC configuration while never realizing PTR records live entirely outside that domain-level control can remain puzzled about a lingering deliverability problem whose actual cause sits in a completely different configuration location.
Why Some Cloud and VPS Providers Make This Harder Than Others
Not every hosting or cloud provider offers self-service PTR record configuration at all — some require submitting a support ticket specifically requesting the change, and a smaller number of budget providers, particularly ones whose IP ranges have been more heavily associated with lower-quality, low-cost bulk hosting, may not offer meaningful PTR customization at all, effectively limiting genuinely reliable mail server self-hosting to providers who do support this specific configuration capability.
The Forward-Reverse Confirmation Check Some Systems Perform
Some more rigorous mail filtering systems go a step further than simply checking whether a PTR record exists — they perform what's sometimes called forward-confirmed reverse DNS (FCrDNS), checking not just that a PTR record exists for the sending IP, but that the hostname it returns, when looked up again in the forward direction, actually resolves back to that same original IP address, creating a consistent, mutually-confirming loop between the two directions. A PTR record that's present but doesn't pass this additional forward-confirmation check can still trigger deliverability concerns, even though a PTR record technically exists.
Why This Matters Considerably Less If You're Not Self-Hosting Mail
For the overwhelming majority of domain owners using a commercial email provider (Google Workspace, Microsoft 365) or their hosting provider's own managed mail service rather than self-hosting a mail server directly, PTR record configuration is already handled correctly by that provider as part of their own infrastructure management, making this entirely a non-issue in practice — it's specifically the self-hosted mail server scenario, discussed in more depth elsewhere on this blog, where this otherwise obscure DNS record type becomes a genuinely practical, sometimes deliverability-determining consideration.
The Takeaway
Reverse DNS occupies an unusual position among DNS record types discussed in this series: it directly affects email deliverability, yet it's controlled by the IP address owner (typically a hosting provider) rather than the domain owner sending the mail — meaning a self-hosted mail server operator needs to specifically verify and, where necessary, request a proper PTR record configuration through their hosting provider directly, entirely separate from anything configured in their own domain's DNS zone.
Tags: email deliverability, PTR records, reverse DNS