Reverse DNS and PTR records: why mail gets rejected

What the rejection means

Every IP that sends mail should have a PTR record: a reverse-DNS entry that maps the IP back to a hostname. Strict receivers check it, and some reject mail from an IP that has no PTR, or whose PTR does not line up. RFC 1912 puts it bluntly: failing to have matching forward and reverse records “can cause loss of Internet services similar to not being registered in the DNS at all.”

What receivers actually test is usually forward-confirmed reverse DNS (FCrDNS): your sending IP has a PTR pointing to a hostname, and that hostname's A / AAAA record points back to the same IP. If the two do not agree, the check fails.

The exact bounces you will see

Gmail returns 550 5.7.25:

550-5.7.25 This message was blocked because the sending IP address
doesn't have a PTR record, or the forwarding DNS entry doesn't
reference the sending IP address. Gmail requires that sending IP
addresses have a PTR record.

(“Forwarding DNS entry” here is Google's phrase for the forward A record, the second half of the FCrDNS check.)

Postfix mail servers return one of two messages, and they are not interchangeable:

Client host rejected: cannot find your hostname, [203.0.113.5]

Client host rejected: cannot find your reverse hostname, [203.0.113.5]

The first (the stronger check) fails unless full FCrDNS passes; the second fails only when the IP has no PTR at all. You will often see them behind a 450 temporary or 550permanent code, depending on the server's configuration. The phrase “cannot find your reverse DNS record” that floats around online is a paraphrase, not what a server actually says.

It is separate from SPF, DKIM, and DMARC

Reverse DNS is its own signal. A passing PTR does not satisfy DMARC, and passing DMARC does not satisfy a receiver that wants reverse DNS. Treat it as a third thing to get right alongside authentication.

One trap worth calling out: publishing a PTR record is not the same as the SPF ptr mechanism. The ptr mechanism inside an SPF record is deprecated, RFC 7208 says do not use it, because it is slow and unreliable. Publishing a PTR record for your sending IP is the opposite: good practice, and required by Gmail and Yahoo. They share a name and nothing else.

The cause is usually one of these

• No PTR record at all for the sending IP.
• A PTR that fails FCrDNS: the PTR hostname has no forward record, or it resolves to a different IP than the one sending.
• A generic, dynamic-looking PTR.It may pass FCrDNS but still get penalized. Yahoo asks senders not to use reverse DNS “that looks like a dynamically-assigned IP.”
• IPv4 set but IPv6 forgotten, when the server also sends over IPv6 with no PTR on that address.

How to fix it

• Set the PTR where the IP lives, not in your domain's DNS.A PTR record sits in the reverse zone owned by whoever owns the IP, your hosting or cloud provider or ISP, not in your domain's normal DNS panel. You request or set it through them. On AWS, for example, you set the forward A record first, then set reverse DNS on the Elastic IP from the EC2 console or the CLI.
• Make the names match (FCrDNS). Point the PTR at a real hostname you control (for example mail.yourdomain.com) and make sure that hostname's A / AAAA record resolves back to the same sending IP.
• Confirm with dig:

  dig -x 203.0.113.5 +short        # PTR -> mail.yourdomain.com
  dig mail.yourdomain.com +short   # A   -> 203.0.113.5 (must match)

• Match your HELO/EHLO name to the PTR. The hostname your server announces should be the same fully qualified name as the PTR.

If you send through a hosted provider, you probably do not need to do anything

On Microsoft 365, an ESP, or most managed senders, the provider owns the sending IP and its PTR, and it is already valid. Reverse-DNS rejections almost always come from self-hosted mail servers or dedicated IPs you control. If that is not you, this is rarely the real problem, recheck SPF, DKIM, and DMARC instead.

Frequently asked

Where do I add a PTR record?

Not in your domain's DNS panel. A PTR record lives in the reverse zone owned by whoever owns the IP address, which is your hosting or cloud provider or ISP. You set or request it through them, for example with the Update reverse DNS option on an AWS Elastic IP. Set the forward A record first.

What is forward-confirmed reverse DNS (FCrDNS)?

It is a two-way check: your sending IP has a PTR record pointing to a hostname, and that hostname's A or AAAA record points back to the same IP. If the two do not match, strict receivers reject the mail.

Is this the same as the SPF ptr mechanism?

No, and it is easy to confuse them. Publishing a PTR record for your sending IP is good practice and is required by Gmail and Yahoo. The ptr mechanism inside an SPF record is deprecated; RFC 7208 says not to use it because it is slow and unreliable. They share a name and nothing else.

I send through Microsoft 365 or an ESP. Do I need to set a PTR?

Usually no. On shared sending infrastructure the provider owns the IP and its PTR record, and it is already valid. Reverse-DNS problems almost always come from self-hosted mail servers or dedicated IPs you control.