---
title: "Reverse DNS (rDNS)"
description: "Reverse DNS (rDNS) is a technique that resolves an IP address to a domain name, providing identification and verification of the server associated with the IP address."
url: "https://mailmum.io/glossary/reverse-dns-rdns/"
---

# Reverse DNS (rDNS)

Reverse DNS (rDNS) is a technique used to map an IP address to a domain name
using a [Pointer (PTR) record](https://mailmum.io/glossary/pointer-record-ptr/). 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)](https://mailmum.io/glossary/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 &mdash; zone naming, IPv6, delegation of
blocks smaller than a `/24` &mdash; are covered on the [PTR
record](https://mailmum.io/glossary/pointer-record-ptr/) 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:

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

Then confirm the name resolves back to the same address:

```sh
$ 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 &mdash; 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 &mdash; 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](https://mailmum.io/glossary/mail-transfer-agent-mta/) configuration, not in DNS.

## Related reading

* [Pointer record (PTR)](https://mailmum.io/glossary/pointer-record-ptr/) &mdash; the record type
  itself, where it lives, and who controls it.
* [Hostname](https://mailmum.io/glossary/hostname/) &mdash; the name a mail server presents in the
  SMTP greeting, and what happens when the three names disagree.
* [Discover mail system setup errors using MailMum
  monitoring](https://mailmum.io/posts/discover-mail-system-setup-errors-using-mailmum-monitoring/)
  &mdash; a worked example of a HELO name and a reverse name that do not match.
* [Howto block mailservers using uncommon TLDs in hostname through
  Postfix](https://mailmum.io/posts/howto-block-mailservers-using-uncommon-tlds-in-hostname-through-postfix/)
  &mdash; frequently changing reverse DNS on the same address is itself a signal
  worth acting on.
