Reverse DNS for Email: Why PTR and Forward DNS Must Agree

Reverse DNS for email is a two-way check. A sending IP should have a PTR record that names a mail host, and that hostname should resolve forward through A or AAAA records to the same IP. When both directions agree, the result is often called forward-confirmed reverse DNS, or FCrDNS. In standardized email authentication results, the related method is named iprev.

Here is a hypothetical clean round trip:

192.0.2.40
  PTR  -> mail.example.net.

mail.example.net.
  A    -> 192.0.2.40

EHLO mail.example.net

The addresses above are from the documentation range, so they are examples, not a live mail setup.

A passing round trip is useful infrastructure hygiene. It is not SPF, DKIM, or DMARC, and it does not prove that a sender is safe. That distinction matters.

Why must the lookup return to the same IP?

A PTR record answers a question about an IP address: “What hostname represents this address?” Forward DNS answers the opposite question: “Which addresses belong to this hostname?”

If the answers do not meet in the middle, the name is not a stable identifier for that sending IP. For example, this is a mismatch:

192.0.2.40
  PTR  -> mail.example.net.

mail.example.net.
  A    -> 192.0.2.99

RFC 7601 defines an iprev=pass result when the reverse and forward lookup results agree. It defines failure when they do not agree, including when no matching forward result exists. The RFC also warns that reverse DNS is not a strong authentication mechanism.

Mailbox providers can impose stricter admission policy than the SMTP protocol baseline. Google’s current sender guidelines require a public sending IP to resolve through PTR to a hostname, and that hostname to resolve through A or AAAA to the same IP. M3AAWG’s Sender Best Common Practices similarly recommends meaningful reverse DNS and an exact match with the primary forward name for a dedicated sending IP.

Who controls the PTR record?

Usually, not the person who controls the domain’s normal DNS zone.

The owner of the IP address controls the reverse DNS zone. That is commonly your cloud provider, hosting company, ISP, or dedicated-IP email provider. You set the A or AAAA record in your domain DNS, then ask the IP provider to set the PTR record.

The safe order is:

1. Choose a stable, specific hostname such as mail.example.net.
2. Create its A or AAAA record pointing to the sending IP.
3. Configure the IP’s PTR record to return that hostname.
4. Set the SMTP client’s EHLO name to the same resolvable hostname when that host is the sender.
5. Test both directions from public DNS before sending production traffic.

A generic cloud hostname may technically resolve, but it tells operators less about the responsible sender. A stable hostname under a domain you control is easier to trace and maintain.

Where does EHLO fit?

EHLO is the name an SMTP client introduces during the connection. RFC 5321 says the client should use its primary host name when possible, and that the name should resolve to an address. A receiver may verify whether the name corresponds to the client IP.

There is a fair objection here: RFC 5321 also says a server must not reject a message solely because that EHLO-to-IP verification fails. So why bother?

Because that sentence defines a minimum SMTP interoperability rule, not every receiver’s full acceptance policy. Providers evaluate several signals around a connection. Clean forward and reverse DNS removes one avoidable inconsistency, improves traceability, and satisfies explicit provider requirements such as Google’s. It does not guarantee placement or acceptance.

The EHLO name, PTR hostname, and forward record do not have to be treated as a new authentication system. They are a coherent infrastructure identity. The message’s visible From domain and envelope identity remain separate concepts, as I explain in From vs Reply-To vs Return-Path.

How should you test the round trip?

Start with the sending IP, not the domain. Resolve its PTR names, then resolve each returned hostname forward. A match to the original IP is a pass. Keep missing data, mismatches, and lookup errors separate because they suggest different fixes.

This Node.js helper follows that state model. It uses dnsPromises.reverse() for PTR lookup and selects A or AAAA based on the input address family:

import { isIP } from "node:net";

export async function checkReverseDns(ip, dns) {
  const family = isIP(ip);
  if (!family) return { status: "invalid_ip" };

  let names;
  try {
    names = await dns.reverse(ip);
  } catch (error) {
    if (["ENODATA", "ENOTFOUND"].includes(error.code)) {
      return { status: "ptr_missing" };
    }
    return { status: "lookup_error", stage: "reverse" };
  }

  if (names.length === 0) return { status: "ptr_missing" };

  let completed = false;
  for (const hostname of names) {
    try {
      const addresses = family === 4
        ? await dns.resolve4(hostname)
        : await dns.resolve6(hostname);
      completed = true;
      if (addresses.includes(ip)) return { status: "pass", hostname };
    } catch (error) {
      if (!["ENODATA", "ENOTFOUND"].includes(error.code)) {
        return { status: "lookup_error", stage: "forward", hostname };
      }
    }
  }

  return {
    status: completed ? "forward_mismatch" : "forward_missing",
    hostnames: names,
  };
}

I tested the helper with injected DNS responses for a match, a mismatch, and a missing PTR. Injection makes the test deterministic and avoids presenting cached public DNS as a permanent truth.

What does a passing result not prove?

A PTR round trip does not authorize an IP to send for a domain. It does not sign a message, align the visible From domain, prove mailbox ownership, or establish that the sender is trustworthy.

You still need to configure and monitor SPF, DKIM, and DMARC. You also need sane sending practices, low complaint rates, and working bounce handling. Even then, delivery remains a receiver decision.

The same caution applies on the verification side. An SMTP response can be temporary, policy-driven, or inconclusive. Our guide to SMTP email verification explains why a transport observation should not be stretched into a certainty about a mailbox.

So the operational rule is simple: make the IP, PTR hostname, forward DNS, and EHLO name coherent, then treat that coherence as one infrastructure prerequisite among several. It closes a real gap without pretending to solve sender authentication or delivery on its own.