What Your Reverse DNS Record Tells Mail Servers About You

You’ve seen it in your mail gateway's logs. An incoming connection from some random IP address announces itself with a generic, nonsensical name: 'EHLO ip-172-31-45-67.ec2.internal' or 'EHLO host-92-40-252-25.dynamic.voo.be'. Your first thought isn't about SPF or DMARC. It's simpler. It's visceral. This doesn't feel like a legitimate mail server. It feels transient, unmanaged, and suspicious.

That gut feeling is the operational core of why reverse DNS matters for email. Before a receiving mail transfer agent (MTA) even bothers to check your SPF (RFC 7208) or DKIM (RFC 6376) signatures, it performs a much more fundamental check. It looks at the IP address you're connecting from and asks the internet's global address book a simple question: 'Who are you, really?'

If the answer is generic, missing, or contradictory, you’ve already failed a critical identity check. This small DNS detail carries an outsized weight in spam filtering and overall deliverability, yet it's one of the most commonly misconfigured aspects of a mail infrastructure.

The Handshake Has Two Halves

DNS, the internet's directory service, is something most IT admins associate with forward lookups. You have a name (like `www.example.com`) and you need an IP address (`93.184.216.34`). This is handled by an A record. It's like looking up a person's name in the phone book to find their number.

The Reverse Lookup: PTR Records

Reverse DNS does the opposite. Given an IP address, it finds the associated name. This isn't done with A records, but with a different record type: the PTR (or pointer) record. The lookup process is clever. To find the name for `203.0.113.10`, a resolver doesn't just search the whole internet. It reverses the IP address, appends a special suffix (`.in-addr.arpa`), and queries for a PTR record at `10.113.0.203.in-addr.arpa`.

The critical detail is one of ownership. You, the domain owner of `example.com`, control the A record for `mail.example.com`. But you don't own the IP address `203.0.113.10`. Your ISP or cloud provider does. Therefore, they control the `in-addr.arpa` zone and are the only ones who can create the PTR record that points back to your mail server's name.

When 'Good Enough' Isn't: Forward-Confirmed Reverse DNS

Just having a PTR record isn't enough. Any spammer can ask their shady hosting provider to point a PTR record for their IP to `mail.google.com`. This is where the concept of Forward-Confirmed Reverse DNS, or FCrDNS, becomes non-negotiable for mail servers. It's a consistency check that proves the relationship between the IP address and the domain name is intentional and bilaterally confirmed.

The Two-Step Validation

The process is a round trip. First, the receiving server takes your connecting IP address and performs a reverse lookup to find the PTR record name. Let's say `203.0.113.10` resolves to `mail.example.com`. Second, the receiver immediately performs a forward lookup on that resulting name, `mail.example.com`, to get its A record. If the A record's IP address matches the original connecting IP (`203.0.113.10`), the FCrDNS check passes. The circle is complete.

If the forward lookup on the PTR name returns a different IP, or no IP at all, the check fails. This symmetry is powerful. It proves that the owner of the IP address (via the PTR record) and the owner of the domain name (via the A record) are in agreement. One entity points to the other, and the other points back. This is a signal of a well-administered, deliberate setup.

Authentication-Results: mx.google.com; iprev=pass (mailout.example.com) smtp.remote-ip=203.0.113.10

When you see an `iprev=pass` in a header like the one above, this is what happened. The receiving MTA performed the FCrDNS check on your sending IP and it passed. A failure might be indicated by `iprev=fail` or the absence of the `iprev` check entirely. It's an early, foundational test of identity.

The Receiver's Calculus: A Signal of Intent

So why is this check so important to receiving mail servers? Because it's a fantastic, low-cost filter for abuse and laziness. Spammers operating botnets on compromised consumer machines or spinning up thousands of virtual servers for a campaign are operating at scale. Their IPs are dynamic, temporary, and have generic reverse DNS entries provided by the ISP, like `1-2-3-4.adsl.some-isp.com`. They aren't going to, and often can't, get a proper FCrDNS-compliant name set up for every node in their network.

A legitimate business, on the other hand, is expected to have a stable, well-configured mail infrastructure. Setting a PTR record demonstrates administrative control and professionalism. It says 'This IP address is not just some random machine; it is an intentional piece of our mail infrastructure, and we stand by the traffic it sends.'

The Connection to HELO/EHLO

This check often runs in tandem with another basic validation: comparing the reverse DNS name to the name your server provides in its SMTP `HELO` (or `EHLO`) greeting. Major receivers like Gmail and Microsoft 365 expect these to align. If your server connects from an IP that has a PTR of `mail.example.com`, but its `EHLO` banner says `exchange-server-01.local`, that's a mismatch. It's another signal of sloppy configuration, at best, or a spoofing attempt, at worst.

Failing an FCrDNS or HELO match check doesn't guarantee your email will be blocked outright. But it adds significant weight to your spam score. It erodes trust before your message content is even scanned. If your SPF alignment is broken by a forwarder and your DKIM signature fails due to a footer modification, a failed FCrDNS check might be the final strike that sends your perfectly valid invoice or marketing email to the junk folder.

Cloud Provider Gotchas: You Don't Own the Zone

For anyone who cut their teeth on on-premise mail servers, the process was straightforward. You'd ask your ISP to set the PTR record for your static IP block, and you were done. In the cloud, it's a different world. The scale and automation of cloud providers mean you can't just call someone up.

When you provision a virtual machine in AWS, Azure, or GCP, you get an IP address from their enormous pool. You don't own that IP, you're merely leasing it. Consequently, you can't just go into your own DNS hosting service and create the PTR record. The `in-addr.arpa` zone is controlled by Amazon, Microsoft, or Google.

The Per-Provider Paper Chase

Each cloud provider has its own specific—and often non-obvious—process for requesting a PTR record for your Elastic IP, Public IP Address, or ephemeral external IP. On AWS, for example, you have to fill out a specific 'Request to remove email sending limitations' form, even if you're not throttled, to specify the reverse DNS entry for an Elastic IP. On Azure, the command is done via PowerShell (`New-AzPublicIpAddress`) or the CLI, where you set a `-ReverseFqdn` for the public IP resource. Google Cloud also has a dedicated process.

This is a frequent point of failure. An engineer diligently sets up the A record for `mail.example.com` in their company's DNS zone but forgets this separate, provider-specific step. The result is a one-way configuration. The name points to the IP, but the IP points back to a generic cloud provider name like `ec2-34-228-2-21.compute-1.amazonaws.com`. The FCrDNS check inevitably fails, and deliverability suffers.

Your Audit and Remediation Checklist

Is your reverse DNS configured correctly? You don't have to guess. You can check it in 30 seconds from any command line.

Performing the Manual Check

First, identify the public IP address of your outbound mail server. If you have multiple, you must perform this check for each one. Once you have the IP, use `dig` or `nslookup`. For an IP of `203.0.113.10`, the command would be `dig -x 203.0.113.10` or `nslookup 203.0.113.10`. Look at the answer. Does it return a generic ISP name, or does it return your desired mail server hostname (e.g., `mail.example.com`)?

If it returns the correct hostname, you're halfway there. Now, complete the FCrDNS check. Take that hostname and do a forward lookup: `dig A mail.example.com` or `nslookup mail.example.com`. Does the IP address in this result match the original IP you started with? If yes, congratulations, your FCrDNS is correctly configured.

Fixing the Mismatch

If the check fails, the fix depends on the first step. If the reverse lookup returns a generic, missing, or incorrect name, your action item is clear: contact the owner of the IP address. This is your hosting provider, your cloud provider (AWS, Azure, GCP), or your business ISP. You need to follow their specific procedure to request a PTR record update. You must provide them with the IP address and the fully qualified domain name (FQDN) it should point to.

If the reverse lookup is correct but the forward lookup fails or returns the wrong IP, the problem is on your end. You need to go into your DNS settings for your domain and ensure the A record for your mail hostname is correct.

The takeaway

Fixing your PTR record is like tucking in your shirt before a meeting. It doesn't guarantee you'll close the deal, but showing up with it untucked suggests you don't care about the details. So much of deliverability is about projecting trustworthiness through technical hygiene. A passing FCrDNS check is a foundational signal that you are a serious, legitimate sender.

It's a low-effort, high-impact configuration that precedes more complex standards like DMARC and ARC. Don't let a simple DNS oversight be the reason your legitimate emails land in junk. While tools like MailSleuth.AI can help you dissect complex authentication failures post-delivery, getting your reverse DNS right is the prerequisite for earning the trust to get that far.