Reverse DNS PTR Record: Set It at Your Host, Not Registrar

On a first self-hosted mail server, this is the step where people get stuck. Every record in their own zone is right, SPF and DKIM pass, and Gmail still rejects every message. The bounce mentions “PTR” or “reverse DNS”, and the record it wants is somewhere you wouldn’t think to look.

What a reverse DNS PTR record is

Ordinary DNS turns names into addresses. Reverse DNS goes the other way. It uses dedicated zones, in-addr.arpa for IPv4 and ip6.arpa for IPv6, where the address is written backwards:

Under that name sits a PTR record holding the hostname:

25.2.0.192.in-addr.arpa.  86400  IN  PTR  mail.example.com.

dig -x does the reversing for you:

dig -x 192.0.2.25 +short
dig -x 2001:db8:10::25 +short

Where to set the PTR record

Not at your domain registrar. The reverse zone belongs to the holder of the IP block, which for a VPS is your hosting provider. Most providers show a “Reverse DNS” or “rDNS” field next to each IP in their panel. Enter mail.example.com there.

Some panels check that the name already resolves to that exact IP before accepting it. So create the forward record first. The A record for mail goes wherever your domain’s DNS is hosted, at betadomain in the customer area for the domain. Then set the PTR.

If there’s no field for it, ask support. Providers that hand out addresses behind NAT often can’t offer a custom PTR at all, which makes that server a poor choice for mail.

With IPv6 you usually get a whole /64, so you set PTRs per address. Use exactly the address Postfix sends from.

Forward-confirmed reverse DNS

Many receivers want more than a PTR. They check the round trip, called forward-confirmed reverse DNS (FCrDNS):

1. Resolve the connecting IP to a name via PTR.
2. Resolve that name back via A or AAAA.
3. If the original IP is in the answer, it passes.

IP=192.0.2.25
NAME=$(dig -x "$IP" +short)
echo "$NAME"
dig "$NAME" A +short

mail.example.com.
192.0.2.25

If the A record points elsewhere, the check fails. Google’s sender guidelines explicitly require a valid PTR with a matching forward record for sending IPs, and it is strictly enforced for IPv6.

Make PTR, HELO and myhostname agree

Three places should carry the same name:

postconf myhostname smtp_helo_name

smtp_helo_name defaults to $myhostname. The name doesn’t have to match the sender’s domain. A server called mail.example.com can send for example.org as long as SPF and DKIM for example.org are right. What matters is that PTR, A record and HELO agree with each other. The other mail records are covered in MX record setup.

IPv6 is where it usually breaks

If mail.example.com has an AAAA record and Postfix runs with inet_protocols = all, it delivers to Gmail over IPv6. Without a PTR for that IPv6 address, the bounce looks like this:

550-5.7.25 [2001:db8:10::25] The IP address sending this message does not have a
550-5.7.25 PTR record setup, or the corresponding forward DNS entry does not
550 5.7.25 point to the sending IP.

Two ways out: set the PTR for the IPv6 address, or restrict Postfix to IPv4 for now:

postconf -e 'inet_protocols = ipv4'
systemctl restart postfix

The PTR is the better fix. Background on the AAAA side is in the AAAA record guide.

Generic names and spam filters

Leave the provider’s default PTR in place and the round trip may technically pass, because generic names usually resolve back. Such servers still score worse. Spam filters treat hostnames containing the IP digits or words like dynamic, dsl or pool as a sign of a consumer connection. SpamAssassin has rules for this, such as RDNS_DYNAMIC, and RDNS_NONE for missing reverse DNS.

A meaningful name like mail.example.com avoids that. If one server handles mail for several domains, one PTR is still enough. The IP has one name, and it doesn’t need to match every sender domain.

How long a new PTR takes

Reverse zones often use long TTLs, sometimes 86400 seconds, so the provider’s old generic entry may stay cached at receivers for a day. Check the responsible nameserver directly:

dig -x 192.0.2.25 +trace | tail -n 4

If the authoritative server already returns your name, all that’s left is waiting. The mechanics are the same as for any other record, explained in DNS propagation time.

When reverse DNS doesn’t matter

For web servers, SSH and APIs, reverse DNS is irrelevant. Let’s Encrypt doesn’t query PTR records, and neither do browsers. In SSH, UseDNS defaults to off on current Debian and Ubuntu, so logins no longer wait on reverse lookups. You need the effort only when the server sends mail, even if that’s just system notifications or a website’s contact form.

Create the A record for mail, set the PTR at your provider, and test the round trip with dig -x. If you want a separate domain for the mail server, you can compare yearly prices at betadomain and type the name into the search. A .net domain is €16.99 a year, renewals included.

Step by step

1. Choose the mail hostnamePick a fixed name such as mail.example.com that is also set as myhostname in Postfix.
2. Create the A and AAAA recordsIn your own DNS zone, point mail.example.com at the server's IPv4 and, if used, IPv6 address.
3. Enter the PTR in the provider panelIn your VPS provider's control panel, set the reverse DNS of each sending IP to mail.example.com.
4. Verify forward-confirmed rDNSRun dig -x IP +short to get the name, then dig name A +short to confirm it resolves back to the same IP.