Reverse DNS (rDNS)

Reverse DNS (rDNS) is a technique used to map an IP address to a domain name using a Pointer (PTR) record. It involves querying the DNS system in reverse, starting with the IP address, to retrieve the associated domain name (e.g. 127.0.0.1 -> localhost). Reverse DNS is commonly used for verifying server identities, preventing email spam, and troubleshooting network issues.

For mail servers it is not optional in practice. A missing or mismatched reverse DNS entry is one of the most common reasons an otherwise correctly configured server cannot deliver mail.

Why should an email server have a valid Reverse DNS record?

• Identity verification: Many receiving servers perform a reverse lookup on the connecting IP address and compare the result to the hostname given in the SMTP HELO/EHLO greeting. A valid rDNS record confirms the server is what it claims to be.
• Spam filtering: Filters such as SpamAssassin and rspamd score a missing or generic rDNS entry as a negative signal. It is rarely enough to reject a message on its own, but it adds to a total that can be.
• Outright rejection: Some large mailbox providers refuse connections from addresses with no rDNS record at all, before the message body is ever transmitted.
• Sender reputation: A correct record indicates a deliberately administered server rather than a compromised host or a consumer connection, which contributes to the reputation of the sending IP address.
• Traceability: It allows a recipient to trace mail back to the responsible domain, which is also how abuse reports find their way to you.

What is forward-confirmed reverse DNS?

Having a PTR record is necessary but not sufficient. What receiving servers generally test is the full round trip, known as forward-confirmed reverse DNS (FCrDNS):

1. The server connects from IP address 192.0.2.25.
2. The receiver looks up the PTR record for 192.0.2.25 and gets mail.example.com.
3. The receiver looks up the A or AAAA record for mail.example.com and gets 192.0.2.25.

If step 3 returns the original address, the check passes. If the PTR record points to a hostname that resolves elsewhere or does not resolve at all, the check fails even though a PTR record exists. Both halves have to agree, and they are usually managed by two different parties: the forward record by you, the reverse record by whoever holds the address space.

The HELO/EHLO hostname should match as well. A server whose PTR record says mail.example.com but which greets as localhost is a familiar misconfiguration, and it gets treated accordingly.

Where can I set a reverse DNS record for an IP address?

Because the reverse zone belongs to the address block rather than to your domain, you cannot set this in your own DNS. Who to approach depends on where the address came from:

• Hosting provider or VPS: usually a field in the control panel that you can edit yourself.
• Internet Service Provider (ISP): normally a support request. On consumer connections it is frequently not offered at all, which is one reason sending mail directly from a home connection rarely works.
• Your own address allocation: you operate the reverse zone and set the record directly.

The mechanics of the record itself — zone naming, IPv6, delegation of blocks smaller than a /24 — are covered on the PTR record page.

How can I check a reverse DNS record?

Check the full round trip rather than the PTR record alone. Starting from an IP address:

$ dig -x 212.227.15.18 +short
mout.gmx.net.

Then confirm the name resolves back to the same address:

$ dig a mout.gmx.net +short
212.227.15.18
212.227.17.22
212.227.17.21
212.227.15.15

The original address appears in the forward answer, so FCrDNS passes. A server sending from several addresses needs each of them to resolve back to a hostname that in turn includes that address.

Two failure modes to watch for:

• dig -x returns nothing — there is no PTR record at all.
• dig -x returns a name, but the forward lookup on that name returns a different address or nothing — the two halves disagree and FCrDNS fails.

Common reverse DNS problems

• No PTR record. Most likely on a new server or a freshly assigned IP address. Request one from whoever holds the block.
• Generic provider hostname. Automatically assigned names that embed the IP address mark the range as unattended or dynamic, and are scored accordingly. Replace it with your real mail hostname.
• Stale record after a migration. The PTR record still points at the old hostname while forward DNS has moved on, breaking FCrDNS silently.
• IPv6 forgotten. A server with working IPv4 rDNS but no ip6.arpa record will fail checks whenever it happens to connect over IPv6. If you cannot set IPv6 reverse DNS, it is usually better to disable IPv6 for outbound mail than to send without it.
• HELO/EHLO mismatch. DNS is correct on both sides, but the mail server is configured to greet with a different name. This is fixed in the MTA configuration, not in DNS.