What does “blocked by policy” mean in bounce codes?

"Blocked by policy" in a bounce means the receiving mail server rejected your message because of a rule the recipient organization wrote. It is not the spam filter saying your content looks spammy. It is the IT team saying "we do not accept mail that looks like this, from senders like you, to mailboxes like that."

You will usually see it paired with an SMTP enhanced status code like 5.7.1 ("delivery not authorized, message refused") or 5.7.0 ("other or undefined security status"). Those codes are defined in RFC 3463 and RFC 5248. The 5.7.x family is the bucket for security and policy rejections, as opposed to 5.1.x (bad address) or 5.4.x (network/routing). For more on how to read these, see What's a 5xx permanent rejection vs a 4xx temporary one?.

What kinds of policies actually trigger this

The most common ones we see when triaging client bounces:

• Attachment type blocked. Executables (.exe, .bat, .js), macro-enabled Office files, password-protected zips. Microsoft 365 blocks 96 file extensions by default (Microsoft docs).
• External sender to internal-only address. Distribution lists, payroll@, board@, anything the admin marked as "staff only."
• Sender not on an approved list. Some companies whitelist their vendors and block everything else, especially in finance, legal, and healthcare.
• DMARC policy rejection. If your domain publishes p=reject and you fail alignment, the receiver bounces with 5.7.1 and a policy reason. That is technically authentication failure, but it shows up under the same code family.
• TLS required. Some receivers refuse mail that arrives unencrypted. You will see something like "TLS required by policy."
• Keyword or content rule. Less common but real, especially in regulated industries.

How to tell policy from spam filtering

The bounce text itself is the giveaway. Look for the phrase. Real examples from production bounces:

• 550 5.7.1 Message rejected by organization policy
• 550 5.7.0 This message was blocked because its content presents a potential security issue
• 554 5.7.1 Service unavailable; Sender blocked by recipient policy

Compare that to a spam-filter rejection, which usually names the filter or the reason: "message identified as spam," "high probability of spam," or a blocklist URL. Policy bounces talk about the organization. Spam bounces talk about the message. If you want the longer version of that distinction, see Block vs quarantine vs junk classification.

What to actually do

Policy blocks are not a reputation problem you can fix by warming an IP. They are a permission problem. Steps:

1. Read the bounce. The enhanced status code plus the human-readable text usually tells you what rule fired. Do not guess.
2. Try a different channel to reach the recipient. Call, text, or LinkedIn message them. Tell them their server rejected your email and paste the bounce.
3. Ask them to whitelist you. Either your sending domain, your sending IP, or your specific address. Their IT team can add an allow rule in minutes.
4. Change what triggered the rule. If it was a .zip attachment, send a link to a shared folder instead. If it was DMARC, fix your alignment before resending.
5. Do not keep retrying the same message. 5.7.x is a 5xx code, which means permanent failure. Retrying just wastes your sender reputation.

One thing worth flagging: a single policy bounce from one company does not mean you have a deliverability problem. It means that company has rules and you tripped one. But if you are seeing a pattern across many recipients, especially with 5.7.1 and DMARC mentions, the problem is on your end and you need to look at how filters evaluate sender behavior and your authentication setup.