What the receiver is telling you

The receiver accepted the connection, looked at who was sending, and refused on policy. The recipient address is fine; the problem is your domain, your IP, your authentication or your content. Gmail spells out which in the text — domain reputation, IP reputation, content classification, DMARC. Exchange names the blocklist. Gateways cite a rule. This is the bounce that does the most damage when misread, because sending tools file it under 'bounced' and people scrub the address, when the correct response is to stop and look at the domain.

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 text. It tells you which of four things it is: domain reputation, IP reputation, authentication (DMARC/SPF/DKIM), or content.
  2. Domain reputation: pause the domain entirely, check Google Postmaster Tools, and plan to rotate a warmed replacement in. Domain reputation recovers slowly if at all.
  3. IP reputation on Workspace or Microsoft 365: the IP is shared, so the trigger is your domain's behaviour — same fix as above.
  4. Blocklist named: check the IP and domain on the blacklist checker, request delisting, and find what got you listed before resuming.
  5. DMARC named: your From domain has a reject policy and the message was not aligned. Fix DKIM alignment; do not loosen the policy.
  6. Content: run the copy through the spam word checker and cut links, images and trigger phrases.

don't Do not remove the address, do not retry at the same volume, and do not switch to a fresh domain without finding the cause — the new one will follow the old.

Decode the whole bounce

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

Common questions

Should I remove a 550 5.7.1 bounce from my list?

No. The recipient is not the problem. Removing them loses a lead and fixes nothing.

Gmail says 'very low reputation of the sending domain' — how long to recover?

Weeks at reduced volume with clean lists, if it recovers at all. Most fleets rotate the domain out and warm a replacement.

Is 5.7.1 always my fault?

Almost always it is something on the sending side — reputation, authentication or content. The exception is a corporate gateway with an over-strict rule, which blocks one company's inbound and says nothing about you elsewhere.

Related codes

Often seen alongside

Go deeper

Related reading

When it is broken

If this is the thing going wrong

The pages explain it. If you would rather it was simply fixed, that is the work I do.

← All error codesEmail authenticationReputationDeliveryInfrastructureBook a call →
Back to top