Fix Missing PTR (Reverse DNS) Record on Sending IP

What's happening

A PTR record (also called reverse DNS or rDNS) maps an IP address back to a hostname. For an outbound mail server at 203.0.113.45, the PTR record is at 45.113.0.203.in-addr.arpa and returns mail.example.com. The forward A record on mail.example.com must in turn point back to 203.0.113.45 — this round-trip is called Forward-Confirmed Reverse DNS (FCrDNS).

Receivers including Gmail, Microsoft 365, Yahoo, and Comcast routinely require PTR for any sending IP. Missing PTR is one of the top reasons that self-hosted MTAs (Postfix, Exim, Haraka) get junked or rejected outright with 550 5.7.1 "Helo command rejected: no rDNS" or similar.

PTR is configured at the IP address owner — your hosting provider (AWS, Linode, Hetzner) or ISP — not at your domain registrar. This catches many operators off guard: they assume DNS records all live in one place, when reverse DNS is delegated up the in-addr.arpa hierarchy and managed by whoever owns the IP block.

Why it matters

Self-hosted mail with no PTR is junked by Microsoft 365 (CAT:GENRDNS in headers), bounced by Comcast, and reputation-flagged by Gmail. Even if other authentication (SPF, DKIM, DMARC) passes, the lack of PTR is sometimes enough on its own to fail delivery.

Spamhaus, Barracuda, and other reputation lists penalize IPs without PTR. The penalty compounds with any other deliverability issue and accelerates blacklisting if even minor spam complaints arrive.

ESP-relayed mail is unaffected (the ESP manages PTR for their own IPs), but any direct sending — Postfix relays, transactional bursts from EC2, Kubernetes egress IPs — needs PTR or it will not deliver reliably.

Common causes

• Cloud provider IP came without default PTR (most providers require explicit configuration).
• PTR was set but does not resolve to a hostname with a matching forward A record (no FCrDNS).
• IP is in a range delegated to the upstream ISP and the customer cannot self-serve PTR.
• ESP migration moved sending to a new IP and PTR was never re-established.
• Multi-IP rotation (egress NAT pool) where some IPs have PTR and others do not.

Detect this on your site

Run a quick scan with the DNS Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Identify your sending IPs

   Send a test message and read Received headers — the public IP your mail uses to deliver is recorded. For Postfix, run postconf smtp_bind_address to confirm the egress. For Kubernetes, the egress depends on your CNI and NAT setup; egress IP is the public NAT address.

2. 2

   Test PTR with dig -x

   Run dig -x 203.0.113.45 +short. Substitute your IP. Output should be a hostname like mail.example.com. No output (or NXDOMAIN) means PTR is missing. A generic ec2-203-0-113-45.compute-1.amazonaws.com or similar provider-default name is also a problem — receivers treat it as low-trust.

3. 3

   Set PTR at your IP provider

   AWS: EC2 Console > Network & Security > Elastic IPs > Manage reverse DNS, or open a request via the AWS support form. Linode: Network panel > IPs > Edit > set Reverse DNS. Hetzner: Robot > Server > Reverse DNS field. DigitalOcean: Networking > Reverse DNS. The hostname you set must already exist as a forward A record.

4. 4

   Establish FCrDNS by publishing the matching forward record

   If PTR returns mail.example.com, then mail.example.com must have an A record pointing back to 203.0.113.45. Publish the A record at your DNS provider before requesting the PTR change, so receivers can immediately verify FCrDNS.

5. 5

   Verify with dig and a Mail-Tester probe

   Run dig -x 203.0.113.45 +short and dig +short A. The two must form a closed loop. Then send a test to mail-tester.com — its report includes a reverse-DNS line that should read "PTR is set and matches".

6. 6

   Match the HELO hostname in your MTA config

   Postfix smtp_helo_name = mail.example.com. The HELO sent to receivers should match the PTR target. Receivers cross-check HELO against PTR for FCrDNS, and a mismatch is sometimes enough to junk the message.

Example

# Verify PTR
dig -x 203.0.113.45 +short
# expected: mail.example.com.

# Confirm the FCrDNS round-trip
dig +short A mail.example.com
# expected: 203.0.113.45

# Postfix HELO setting
postconf -e "smtp_helo_name = mail.example.com"
systemctl reload postfix

FCrDNS verification and Postfix HELO alignment for direct-sending MTAs.

Related fixes