What the receiver is telling you

The catch-all code for 'our policy says no' when the receiver has not chosen a more specific one. Read the text around it, because it varies: relaying denied means you sent to a server that is not the recipient's MX; a gateway reject with an ID means a content or reputation rule fired; Gmail's version means authentication did not pass. The one thing it is not is a bad address — the recipient was never the question.

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. Read the rest of the line. The receiver almost always says why in words.
2. If the wording mentions relay, check that you are sending to the domain's real MX and not a stale host.
3. If it mentions a rule, ID or policy, treat it as a reputation or content block: pause, check authentication and blocklists, then resume slowly.
4. If it names a gateway (Barracuda, Proofpoint, Mimecast), the block is at the company's filter — one domain, not your reputation everywhere.

don't Do not remove the address, and do not retry blindly. Fix what the text names first.

Decode the whole bounce

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

Common questions