What the receiver is telling you

The receiver looked up the reverse DNS of the connecting IP and either found nothing or found a name that does not resolve back to that IP. Gmail's published requirement is a forward-confirming PTR, and it refuses connections that lack one. This only appears for senders running their own SMTP server, relay or VPS: Google Workspace and Microsoft 365 manage their own PTRs and never produce it. If you see it from a Workspace fleet, something is routing mail through a server you did not know about.

Why a policy block must not be treated as a bad address

Sending tools file every 5xx under "bounced", and the natural reflex is to scrub the address. For a policy block that is exactly wrong. The recipient exists and would have received the mail; the receiver refused it because of your domain, IP, authentication or content. Scrubbing throws away a lead and leaves the cause in place, so the next send produces the same block against the next thousand addresses. The right response is to stop sending from the affected domain, find what the receiver named, fix it, and resume at low volume.

What to do

1. Set a PTR record for the sending IP through the hosting provider — it lives in their reverse zone, not yours.
2. Make the PTR a real hostname (mail.yourdomain.com) and give that hostname an A record back to the IP.
3. Use the same hostname in the server's HELO/EHLO.
4. If you are on Workspace or 365 and see this, find the relay in the Received headers.

don't Do not try to work around it by sending through a different port or provider until the PTR is fixed; every major receiver checks it.

Decode the whole bounce

Paste the complete failure notice — every code and the receiver's wording — and get each part explained together.

Common questions