How does reverse DNS work for email?

What are the requirements?

A PTR record maps the address to a domain name

RFC 1035 defines a PTR record's data as a domain name that points to a location in the DNS namespace. For reverse mapping, that location is constructed from the address rather than from a normal hostname.

For IPv4, RFC 1035 defines the reverse namespace under IN-ADDR.ARPA. Each address octet becomes a label in reverse order. The reversal lets DNS operators delegate reverse zones along network boundaries.

Illustrative only. Do not publish this as a production record.
52.0.2.10.in-addr.arpa.  IN  PTR  mail.yourdomain.com.

For the IPv4 address 10.2.0.52, RFC 1035 places reverse data at 52.0.2.10.IN-ADDR.ARPA. A PTR query for that reverse name can return mail.yourdomain.com.

The record does not authenticate a sender by itself. It states what hostname the reverse DNS zone publishes for an IP address.

IPv6 uses reversed hexadecimal nibbles

IPv6 reverse DNS uses a separate IP6.ARPA tree. RFC 3596 specifies that an IPv6 address is represented as dot-separated hexadecimal nibbles, followed by .IP6.ARPA.

Illustrative only. Do not publish this as a production record.
8.b.d.0.1.0.0.2.ip6.arpa.  IN  PTR  mail.yourdomain.com.

The full reverse name for a production IPv6 address contains all 32 hexadecimal nibbles in reverse order. RFC 3596 also records that IP6.ARPA replaced the older IP6.INT domain.

Forward confirmation checks the returned hostname

A common receiver check has two DNS stages:

• Query the IP address for PTR records and collect the returned hostnames.
• Query each returned hostname for A records, AAAA records, or both, then check whether the original IP address appears in those results.

Illustrative only.
198.51.100.25
  PTR query -> mail.yourdomain.com
  A query for mail.yourdomain.com -> 198.51.100.25
  Result -> forward-confirmed reverse DNS passes

This is why a PTR result is only half the mechanism. A PTR can exist while the returned hostname resolves to a different address, has no usable A or AAAA record, or encounters a DNS error.

RFC 8601 registers pass, fail, temperror, and permerror result values for iprev in the Authentication-Results header field. A receiver can report such a result, but the RFC also cautions that applications should avoid treating reverse mapping as authentication or a security control. The method remains common, yet it does not establish ownership of a message's From domain or replace SPF, DKIM, and DMARC.

EHLO and PTR are related signals, not the same requirement

An SMTP client identifies itself with EHLO or HELO. That name is often compared with connection information, but RFC 5321 section 4.1.4 does not require a server to reject mail because the EHLO domain does not correspond to the client IP.

The RFC states:

An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis.

A mismatch can still be useful for logging and tracing. It is not a universal SMTP rule that makes the message invalid. For the specific operational case where these names disagree, see when reverse DNS does not match the SMTP banner.

When does the requirement take effect?

The underlying DNS mechanism has no single new operative date. RFC 1035, which defines IPv4 reverse mapping and PTR records, was published in November 1987. RFC 3596, published in October 2003, specifies IPv6 address mapping in IP6.ARPA. RFC 8601, published in May 2019, defines the iprev result method for Authentication-Results.

Mailbox providers can add their own sender requirements. Google's Email sender guidelines state that all senders must have valid forward and reverse DNS from February 1, 2024. Google requires the sending SMTP server's public IP to have a PTR record resolving to a hostname, and that hostname to have an A record for IPv4 or AAAA record for IPv6 resolving back to the same public IP.

That is a Google sender requirement, not a new universal SMTP requirement. A receiver can also apply private filtering policies that are not published as an RFC.

How do I implement the requirement?

1. Identify the public IP used for the SMTP connection

Use the IP that connects to recipient mail servers. This can differ from a web server address, a NAT gateway, or an internal mail host address.

For a hosted sending service, determine whether the provider assigns the public IP and controls its reverse DNS. Do not assume a domain's normal DNS administrator can change the PTR record.

2. Find the reverse DNS owner

Identify the provider that owns or delegates the reverse zone for the sending IP. The provider may be an ISP, cloud platform, hosting company, or dedicated IP service.

Ask that owner to publish the desired PTR hostname if its documented process allows it. The hostname should be one the organization can also publish in forward DNS.

3. Publish the corresponding forward record

Publish an A record for IPv4 or AAAA record for IPv6 so that the hostname returned by the PTR lookup resolves to the same public sending IP.

This guidance creates the two-way DNS relationship that Google's sender guidance describes. It does not make reverse DNS an identity standard or guarantee a receiver will accept a message.

4. Keep SMTP identity evidence separate

Inspect the actual SMTP exchange and delivered message headers separately from DNS. An EHLO name, a PTR hostname, an SPF identity, DKIM signing domain, and DMARC alignment can be related but are different protocol fields and checks.

A correct PTR record does not prove that an application sent through that IP, that the message was signed correctly, or that a receiving mailbox provider accepted the message.

How do I validate compliance?

Start with the authoritative reverse lookup for the public sending IP. Confirm that it returns the intended hostname. Then query that hostname's A record or AAAA record and verify that the original IP appears in the answer.

Use the IP reputation checker to inspect the PTR hostname returned for a public IP. It can show a published PTR result, but it does not perform the follow-up A or AAAA lookup needed to establish an iprev result. A timeout or empty result also needs careful interpretation because public DNS responses can vary with resolver reachability and timing.

For a full mail-path validation, gather evidence at separate layers:

• DNS: confirm the PTR record and matching forward A or AAAA record through the authoritative DNS path and a public resolver.
• Vendor: review the sending provider's current verification status when it manages the SMTP service.
• Message: inspect a delivered message from the exact production path, including relevant Authentication-Results and SMTP tracing headers.
• DMARC: review aggregate-report data after mail has accumulated to understand the domains and sources actually using the organization’s identity.

Check the PTR hostname for your sending IP

A reverse lookup can show which hostname the IP owner currently publishes before you investigate a mismatch or contact the provider that controls the reverse zone.

Check the IP's published PTR record

This check returns a PTR result for an IP address. It does not forward-confirm the hostname, repair a mismatch, monitor the production sending path, or predict how a mailbox provider will treat a future message.