Reverse DNS (PTR) for mail servers: setup and FCrDNS

What a PTR record is

Normal DNS maps names to addresses. Reverse DNS maps addresses to names, using special zones:

• IPv4: the octets reversed under in-addr.arpa. The PTR for 203.0.113.25 lives at 25.113.0.203.in-addr.arpa.
• IPv6: each hexadecimal nibble reversed under ip6.arpa.

25.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.example.com.
mail.example.com.           3600  IN  A    203.0.113.25

The first line is the reverse record and the second is the matching forward record. Both must exist.

Why receivers care

Spam from infected home computers and botnets almost always comes from IPs with generic or missing reverse DNS. Checking for a sensible, forward-confirmed PTR is cheap and filters a lot of junk, so receivers use it as a baseline requirement:

• Gmail requires valid forward and reverse DNS for sending IPs. Failures return temporary error 4.7.23 or permanent error 5.7.25.
• Many corporate gateways and smaller providers reject or heavily penalise connections from IPs without a PTR.
• A PTR that looks residential (dsl-203-0-113-25.isp.example) suggests a home connection that shouldn't be sending mail, even when it resolves.

Forward-confirmed reverse DNS

FCrDNS is the round trip:

1. Look up the PTR for the connecting IP and get mail.example.com.
2. Look up the A/AAAA records for mail.example.com.
3. Check that the original IP is among them.

If step 2 fails, or returns a different IP, the check fails even though a PTR exists. This is the most common half-finished setup: the provider set the PTR, but nobody added the A record in the domain's DNS.

Who can set it

The PTR lives in the reverse zone of the IP's owner, not in your domain's zone. Your DNS host can't create it.

Choosing the hostname

• Use a name in a domain you control, e.g. mail.example.com or mx1.example.com.
• It doesn't have to match the From: domain of every message. A server sending for many domains can have one PTR.
• It should match the name the server uses in its SMTP greeting (HELO/EHLO) wherever possible; some receivers compare them.
• Avoid names that look dynamic or residential.

Fixing 4.7.23 / 5.7.25 bounces

1. Find the sending IP in the bounce, or in your outbound mail logs.
2. Run it through the Email Blacklist Check. It reports the PTR and whether it forward-confirms.
3. If there is no PTR, request one from the IP's owner (table above).
4. If the PTR exists but doesn't confirm, add an A/AAAA record for that hostname pointing to the IP.
5. Wait for the TTLs to expire, then send a fresh test message.

Common mistakes

• Adding a "PTR record" in your domain's DNS host. It has no effect; the reverse zone isn't there.
• Office mail sent from a dynamic or residential IP. Even with a PTR, it should go through an authenticated relay.
• IPv6 forgotten. If your server has IPv6 and sends over it, the IPv6 address needs its own PTR and AAAA record. Gmail checks whichever protocol you connect with.
• Several PTRs for one IP. It's allowed, but some receivers check only the first; keep one.

From the field: Hosting your own mail server that does not go through a service as the next hop will require you to work with your ISP to get that PTR record created. They will only do so if you are paying for static IP addresses from them. The only real exception to that is if you own the full IP block, which most organizations do not.

Sources

• Gmail email sender guidelines FAQ
• RFC 1035: Domain names, implementation and specification (IN-ADDR.ARPA)
• RFC 3596: DNS extensions to support IPv6 (ip6.arpa)