Why reverse DNS matters so much
Receiving mail servers look up the name (PTR record) of every delivering IP address and check that this name points back to the same IP. This is called forward-confirmed reverse DNS (FCrDNS). Without it, mail ends up in spam or is rejected outright. Google and Yahoo have explicitly required it since 2024. Typical error messages:
550-5.7.25 [203.0.113.10] 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. 450 4.7.1 Client host rejected: cannot find your reverse hostname, [203.0.113.10]
Where the PTR record is set
The PTR record does not belong to your domain but to the IP address. Only whoever owns the IP can set it: your hosting provider or ISP. That is why you will not find it in your domain’s DNS management.
- Hetzner: Cloud Console → server → Networking → edit reverse DNS; for dedicated servers in Robot under “IPs”.
- OVHcloud: Bare Metal Cloud → Network → IP → “…” → modify reverse DNS.
- AWS: EC2 → Elastic IPs → Actions → “Update reverse DNS”. The A record must exist first.
- Azure: via CLI with
az network public-ip update --reverse-fqdn. - DigitalOcean: the PTR follows the droplet name. So name the droplet exactly like the mail server.
- Home or office internet connection: impossible with dynamic IPs; with static IPs usually only on request to the ISP.
Step by step
- Choose a name, e.g.
mail.example.com. - A record (and AAAA for IPv6) in your zone:
mail.example.com → 203.0.113.10. - PTR at the provider:
203.0.113.10 → mail.example.com. - HELO name of the mail server set to the same name. Postfix:
myhostname = mail.example.comin main.cf. Exchange: FQDN in the send connector. - Check SPF: the IP must be in the sender domain’s SPF record, e.g. via
mxorip4:203.0.113.10.
The PTR does not have to match the sender domain. A mail server mail.example.com may send mail for other-domain.com without problems. What matters is that PTR, A record and HELO match each other.
The IPv6 trap
If your server has an IPv6 address, Postfix often delivers to Gmail & co. over IPv6. Then the IPv6 address needs a PTR and a matching AAAA record too. If you cannot set it, turn off sending over IPv6:
# Postfix main.cf inet_protocols = ipv4 # or allow IPv6 but prefer IPv4: smtp_address_preference = ipv4
Checking
# PTR of the IP dig -x 203.0.113.10 +short # does the name point back to the IP? dig +short A mail.example.com # Windows nslookup 203.0.113.10 # see the server's HELO openssl s_client -starttls smtp -connect mail.example.com:25 -quiet
Depending on the TTL, PTR changes can take a few hours until all resolvers see them. The DNS lookup shows PTR and the forward check in one step; the DNS propagation check shows which resolvers already know the new A record.
FAQ
Must the PTR name contain my sender domain?
No. It only has to be a real name that points to the same IP via an A or AAAA record. Generic names like 203-0-113-10.provider.net are rated worse by some receivers, though.
Can an IP have several PTR records?
Technically yes, in practice it causes problems. One name per IP is the safe way.
I cannot set the PTR. What now?
Send outgoing mail through a smarthost (relay) of your provider or a mail service. Your server keeps receiving mail itself but sends via the relay.
How long until the PTR takes effect?
At the provider usually immediately. Resolvers that cached the old value only see it after the TTL expires, often one to 24 hours.