When sending an email over the internet, one of the most critical checks an incoming mail server performs is verifying the sender’s identity. This process involves many layers of authentication and reputation assessment, but the very first step is confirming that the connecting IP address. One of the primary tools for this verification is the Reverse DNS (rDNS) or PTR (Pointer) record.

This article covers what a PTR record is, why it is vital to email deliverability, how the verification mechanism works, and what happens if your setup is incorrect.

What is a Reverse DNS (PTR) Record?

In the Domain Name System (DNS), an A record (or AAAA for IPv6) translates a human-readable domain name (e.g., mail.tinkmail.me) directly into an IP address (e.g., 192.0.2.1).

A PTR record performs the exact opposite mapping. It resolves an IP address back to its associated domain name. When you query the IP 192.0.2.1, the DNS response provided by the PTR record should state mail.tinkmail.me.

In the context of an email server, the PTR record definitively answers the question: “Who owns or operates the IP address currently connecting to me?”

We can use dig to check the PTR record for an IP address:

dig -x 192.0.2.1 +short

If the output is mail.tinkmail.me (assuming the PTR record is our mail server), then the PTR record is correctly configured. If there is no output or it returns a generic hostname, then the PTR record is missing or misconfigured.

Why is the PTR Record So Important?

As spam became pervasive in the early internet, operators of mail systems needed a reliable metric to filter legitimate servers from compromised botnets and dynamic residential IP allocations. Creating A records was easy—spammers could register a domain and point it anywhere.

However, issuing PTR records typically requires authority over the IP allocation. Only the owner of the IP block (like your hosting provider or ISP) can create or delegate the creation of PTR records for those addresses. Because it is much harder for spammers to control their PTR records, receiving servers place significant trust in the existence of a valid, correctly configured reverse DNS mapping.

Without a PTR record—or if the PTR record points to a generic, system-generated hostname (like ec2-192-0-2-1.compute-1.amazonaws.com)—receiving mail servers will heavily penalize your email’s reputation score.

In our experience, some major free email providers such as GMX / Caramail, will not even allow the connection to proceed if the PTR record is missing or fails the verification process.

How Receiving Servers Verify Reverse DNS (FCrDNS)

To establish the trustworthiness of a sending mail server, the receiving server implements a process called FCrDNS (Forward-Confirmed reverse DNS). It works in three steps:

1. The Reverse Lookup (PTR Query): When your mail server (192.0.2.1) attempts to open a connection to the receiving mail server, the receiver detects your IP. It queries the DNS system for the PTR record associated with 192.0.2.1. Result: Assume it returns the hostname mail.tinkmail.me.

2. The Forward Lookup (A/AAAA Query): The receiver then takes the hostname it just learned (mail.tinkmail.me) and queries the DNS system for its A or AAAA record to see what IP address the domain advertises. Result: The domain mail.tinkmail.me resolves back to 192.0.2.1.

3. The Match: The receiver compares the IP from Step 2 with the IP that originally connected in Step 1. Because they match (192.0.2.1 equals 192.0.2.1), the connection survives the FCrDNS check. It verifies a symmetric, intentional configuration by both the domain owner and the IP owner.

Furthermore, the hostname returned in Step 1 should ideally match the domain the sending server claims in its SMTP EHLO/HELO greeting. Even if it doesn’t match perfectly, having a passing FCrDNS check under a legitimate, non-generic domain name is the baseline requirement.

Summary

The PTR record is the foundational layer of email reputation. Before configuring SPF, DKIM, or DMARC, your primary objective when setting up a mail server must be coordinating with your infrastructure provider to establish a proper reverse DNS record that points to your mail server’s canonical hostname, ensuring the FCrDNS loop completes successfully.