CxO Tools / Deliverability / Email Errors / Reverse DNS

No Reverse DNS (PTR / FCrDNS): Why Mail Servers Reject You

Reverse DNS (rDNS) is the PTR record that maps a sending IP address back to a hostname, published in the IP's in-addr.arpa (IPv4) or ip6.arpa (IPv6) reverse zone. "No reverse DNS" means a PTR lookup on your sending IP returns nothing (NXDOMAIN/empty). FCrDNS - Forward-Confirmed reverse DNS - is the stronger check: the PTR must resolve the IP to a hostname, AND that hostname's A/AAAA record must resolve back to the exact same IP. A missing PTR, or a PTR whose hostname does not point back to the IP, fails FCrDNS and is what many receiving mail servers penalize or reject.

Why it matters

Receiving MTAs use PTR/FCrDNS as a cheap, hard-to-forge reputation signal: legitimate mail infrastructure almost always has matching forward and reverse records, while botnets, compromised hosts, and hijacked residential IPs usually do not. A missing or non-matching PTR causes outright rejection (5xx "no reverse DNS"/"client host rejected"; Gmail returns enhanced status 5.7.25), aggressive greylisting, or heavy spam scoring (e.g. SpamAssassin RDNS_NONE / FCrDNS penalties). Google and Yahoo have mandated FCrDNS on the sending IP since February 2024, and for IPv6 senders they require a valid IPv6 PTR with matching FCrDNS before they will accept mail directly from your IP. This is governed by RFC 1912 §2.1 (Reverse DNS / matching PTR records).

Common causes

  • Sending mail directly from an IP that never had a PTR configured, common on freshly provisioned cloud VMs and on-prem static IPs.
  • A generic or provider-default PTR that looks dynamic/residential (e.g. ec2-203-0-113-5.compute.amazonaws.com, 203-0-113-5.dynamic.isp.net), receivers treat these as untrusted even though a PTR technically exists.
  • Forward/reverse mismatch: the PTR hostname has no A/AAAA record pointing back to the sending IP, so FCrDNS fails even though a PTR is present.
  • Sending over IPv6 with only an IPv4 PTR configured, big providers reject AAAA-originated mail that lacks an IPv6 PTR + FCrDNS.
  • HELO/EHLO hostname announced by your MTA does not match the PTR hostname, weakening or failing correlation checks.
  • Mail originating from a dynamic/residential IP range that is listed on the Spamhaus PBL and can never obtain legitimate rDNS.

How to fix No Reverse DNS (PTR / FCrDNS)

  1. Confirm the problem: run `dig -x <your-sending-IP> +short` (or `nslookup <IP>`). An empty result means no PTR. Do this for the exact IP your MTA egresses from, including IPv6 if you send over v6.
  2. Test FCrDNS end-to-end: take the hostname the PTR returns and run `dig A <hostname> +short` (and AAAA for v6). It must resolve back to the same sending IP. If it doesn't, FCrDNS is broken and must be fixed even if a PTR exists.
  3. Pick one dedicated, real FQDN for the mail host (e.g. mail.example.com) that you control. Avoid names containing dynamic, dhcp, pool, client, or the provider's generic pattern.
  4. Create the FORWARD record first: publish an A record (and AAAA if sending over IPv6) for that FQDN pointing to the sending IP. FCrDNS can't pass until this exists.
  5. Set the PTR where the IP block is controlled, you usually cannot set it in your own DNS. Use your cloud/host console: AWS EC2 (submit the reverse-DNS request or delegate the reverse zone), Azure/GCP reverse DNS settings, or your hosting/ISP panel. For colo/on-prem, ask whoever owns the IP allocation to point the PTR at your FQDN. Note that the PTR must resolve to a real A record, not to a CNAME alias.
  6. For IPv6: set a PTR for the specific /128 address you actually send from (nibble format under ip6.arpa) and confirm its AAAA points back, or disable IPv6 sending and send over IPv4 only if you can't.
  7. Align your MTA's HELO/EHLO to the same FQDN: Postfix `myhostname` / `smtp_helo_name`, Exim `primary_hostname`, Exchange send-connector FQDN. HELO should match the PTR.
  8. Wait for TTL/propagation, then re-verify with `dig -x` and an external checker (MXToolbox reverse-lookup or a send-and-inspect header test), and send a test message to a Gmail/Outlook account to confirm acceptance.
Mail Health Report

Frequently asked questions

Can I just add the PTR record in my own DNS zone?

Almost never. PTR records live in the reverse (in-addr.arpa / ip6.arpa) zone for the IP block, which is controlled by whoever owns the IP: your ISP, hosting company, or cloud provider. You request or set it through their console or support, not in your domain's forward zone. You only control the forward A/AAAA record.

Does the PTR hostname have to match my main sending domain exactly?

No. It must be a valid FQDN that passes FCrDNS (forward record points back to the IP) and should not look generic/dynamic. Best practice is that it also matches the HELO/EHLO your MTA announces. It doesn't have to be your primary domain, but it should be a real name you control.

I send through Google Workspace / Microsoft 365 / SendGrid: do I need to fix PTR?

No. Those providers own the outbound IPs and already publish correct PTR/FCrDNS records. Reverse DNS only matters for IPs you send directly from, your own mail server or appliance.

Why does IPv6 seem stricter about reverse DNS?

Large receivers (notably Google) require IPv6 senders to have a valid IPv6 PTR with matching FCrDNS and will reject otherwise. A common failure is having an IPv4 PTR but no IPv6 PTR while the server prefers IPv6 for outbound, set the AAAA/PTR pair or force IPv4 sending.

Related

Mail Health Report SuperCheck SPF PermError SPF Softfail (~all) Multiple SPF Records No DMARC Record