Reverse DNS and PTR records for email: what they are and who sets them

Forward and reverse DNS

Ordinary ("forward") DNS answers the question which IP address belongs to this name? - an A record for IPv4, AAAA for IPv6. Reverse DNS answers the opposite question: which name belongs to this IP address? The answer is stored in a PTR (pointer) record.

PTR records don't live in your domain's zone. They live in two special trees of the DNS: in-addr.arpa for IPv4 and ip6.arpa for IPv6. The IP address is written backwards, because DNS names get more specific from right to left while IP addresses get more specific from left to right.

10.2.0.192.in-addr.arpa.  3600  IN  PTR  mail.example.com.

For IPv6, the address is expanded to all 32 hexadecimal digits, which are then reversed one digit at a time:

0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN  PTR  mail.example.com.

You will rarely type these names by hand - the provider's panel asks for the IP and the hostname, and builds them for you.

Forward-confirmed reverse DNS

A PTR record on its own proves little: whoever controls an IP address can make it point to any name, including mail.google.com. That's why receivers check both directions. This is usually called forward-confirmed reverse DNS (FCrDNS):

1. Look up the PTR record of the connecting IP address and get a hostname.
2. Look up the A (or AAAA) records of that hostname.
3. Check that the original IP address is among them.

Only the owner of the IP can set the PTR, and only the owner of the domain can set the A record - so when both agree, the two parties really are connected. Google's sender guidelines describe exactly this check: the sending IP must have a PTR record that resolves to a hostname, and that hostname must have an A or AAAA record pointing back to the same IP.

10.2.0.192.in-addr.arpa.  PTR  mail.example.com.
mail.example.com.         A    192.0.2.10

Why receivers require it

Virtually every legitimate mail server sits on a static IP address with a deliberately configured name. Hijacked home computers sending spam don't: their IPs have no PTR record, or a generic one assigned by the internet provider, like host-192-0-2-10.dynamic.isp.example. A missing or generic PTR is therefore one of the cheapest and oldest spam signals there is.

• Gmail lists valid forward and reverse DNS for sending IPs as a requirement for all senders, not just bulk ones. Mail that fails it can be rejected or sent to spam.
• Yahoo asks senders to publish "valid, meaningful, non-generic" PTR records for all sending IPs and not to use names that look like dynamically assigned addresses.
• Many other receivers and spam filters score or reject mail from IPs without working reverse DNS.

What a good PTR looks like

• It names the mail server, for example mail.example.com, under a domain you control.
• The name resolves back to the same IP address (the forward-confirmed check above).
• It isn't generic: no IP address embedded in the name, no words like "dynamic", "dsl" or "pool" that receivers associate with home connections.
• Ideally it matches the name the server announces in its SMTP greeting (EHLO). That's not a strict rule, but a consistent identity looks better than three different names.
• One IP address gets one PTR record. Several names for one IP confuse more than they help.

The PTR hostname does not have to be in the domain you send mail from. A mail provider that sends for thousands of customer domains uses one name of its own for its sending IP, and your domain is authenticated through SPF, DKIM and DMARC instead.

IPv6 needs reverse DNS too

If your mail server has an IPv6 address and connects to receivers over IPv6, that address needs its own PTR record - the IPv4 one doesn't cover it. This is a common surprise: a server works fine over IPv4, gets an IPv6 address, starts preferring it, and mail suddenly bounces. Gmail rejects such mail with a 550 5.7.1 error saying the message "does not meet IPv6 sending guidelines regarding PTR records and authentication".

Either set a PTR for the IPv6 address (with a matching AAAA record on the hostname), or configure the server not to send over IPv6.

Who sets the PTR record

Reverse DNS is delegated along with the IP addresses themselves: regional internet registries (such as RIPE NCC in Europe) delegate the reverse zones for address blocks to the organizations holding them - internet providers, hosting companies, cloud platforms - and they decide what each IP's PTR says. So:

• Your registrar can't set it. Adding a "PTR" record in your domain's DNS panel creates a record under your domain, which no receiver ever queries. It has no effect.
• On a VPS or dedicated server, the setting is usually called "reverse DNS" or "rDNS" in the provider's network or IP settings. Many providers only accept a name that already resolves to the IP, so add the A record first.
• Some cloud platforms require a separate request before they enable reverse DNS or outbound mail on port 25 at all - check the provider's documentation.
• On a home or office connection, the internet provider controls the PTR. Business plans with a static IP sometimes let you set it; consumer plans usually don't - and many receivers distrust mail from those address ranges regardless.

If you use a hosted mail provider

Reverse DNS belongs to the server that connects to the receiver - and with a hosted provider, that is the provider's server, on the provider's IP address. You have nothing to set, and you couldn't if you wanted to: you don't control their IPs. Your part is publishing the records in your own domain - MX, SPF, DKIM and DMARC.

That is how AnyMail works too: our sending IP's reverse DNS is configured on our side, so the DNS setup page never asks you for a PTR record. The same goes for your domain's A and AAAA records - mail doesn't need them, so your website can stay where it is.

How to check reverse DNS

dig -x 192.0.2.10 +short
# mail.example.com.

dig A mail.example.com +short
# 192.0.2.10

On Windows, nslookup 192.0.2.10 does the reverse lookup. To find the IP that actually sent a message, open its original headers and look at the topmost Received: line added by the receiving server; many receivers also note the reverse name they saw there.