SMTP Reverse DNS PTR Record: Set and Verify rDNS (2026)

Setting and verifying an SMTP reverse DNS PTR record is about proving your mail server’s IP address actually belongs to the hostname it claims.

Imagine you’re a detective at a post office. When a letter arrives, you don’t just look at the return address; you want to confirm that the address really belongs to the sender. That’s what a PTR record does for email. It’s a lookup from an IP address back to a hostname. This is crucial for mail servers because if they can’t verify your IP address maps to a legitimate hostname, they’re much more likely to treat your outgoing email as spam.

Here’s how it works in practice. When your mail server (say, mail.example.com at IP 192.0.2.10) sends an email to another server, the receiving server will perform a forward DNS lookup for mail.example.com to get its IP address. It will then immediately perform a reverse DNS lookup on 192.0.2.10 to see if it resolves back to mail.example.com. If the reverse lookup fails, or resolves to a different hostname, your email is highly suspect.

Setting the PTR Record

PTR records are managed in the DNS zone for the IP address, not your domain name. This means you’ll typically need to contact your IP address provider (your ISP, hosting provider, or cloud provider) to set this up.

Let’s say your mail server is mail.example.com and its static IP address is 192.0.2.10.

Identify the IP address block: You need to know the specific IP address block your provider manages. For 192.0.2.10, this is a 192.0.2.0/24 block.
Construct the reverse DNS zone name: For IPv4, you reverse the octets of the IP address and append .in-addr.arpa.. So, 192.0.2.10 becomes 10.2.0.192.in-addr.arpa.. For IPv6, it’s more complex, reversing every nibble (4 bits) and appending .ip6.arpa..
Create the PTR record: Within this reverse DNS zone, you create a PTR record for the specific IP address. For 192.0.2.10, you’ll create a record named 10 (the first octet of the reversed IP) pointing to mail.example.com..
- Provider Interface: Most providers have a web portal or API for managing reverse DNS. You’ll typically enter the IP address and the target hostname.
- Example Request to Provider: "Please set the PTR record for IP address 192.0.2.10 to mail.example.com.."

Verifying the PTR Record

Once you’ve requested the PTR record, it can take some time for DNS propagation (minutes to hours, depending on TTLs). You can verify it using command-line tools.

Using dig (Linux/macOS):
```
dig -x 192.0.2.10 +short
```
This command performs a reverse lookup (-x) for the specified IP address and (+short) displays only the answer.
- Expected Output:
```
mail.example.com.
```
- If it’s not set or incorrect: You might see nothing, an error, or a different hostname.
Using nslookup (Windows/Linux/macOS):
```
nslookup 192.0.2.10
```
This command performs a reverse lookup by default for an IP address.
- Expected Output:
```
10.2.0.192.in-addr.arpa      name = mail.example.com.
```
- If it’s not set or incorrect: nslookup might report "Non-existent domain" or show an incorrect name.

The Importance of Forward-Confirmed Reverse DNS (FCrDNS)

For maximum deliverability, you want a setup where the forward DNS (A record) and reverse DNS (PTR record) match exactly. This is called Forward-Confirmed Reverse DNS (FCrDNS).

A Record: mail.example.com resolves to 192.0.2.10.
PTR Record: 192.0.2.10 resolves to mail.example.com.

If your PTR record points to server1.example.com but your A record for mail.example.com points to 192.0.2.10, many mail servers will reject your mail. You must ensure the hostname in the PTR record is the actual hostname your mail server uses for sending, and that this hostname has an A record pointing back to the IP address.

A common pitfall is having your PTR record point to a generic hostname provided by your ISP (e.g., cpe-192-0-2-10.yourisp.net) while your mail server is configured to send mail as mail.example.com. You need to get your provider to set the PTR record to mail.example.com. (or whatever your server’s FQDN is).

The next hurdle you’ll encounter is ensuring your SPF, DKIM, and DMARC records are correctly configured to further authenticate your email.