SMTP error 552 5.7.0: content rejected by policy

552 is a 5yz permanent failure that RFC 5321 defines generically as "exceeded storage

allocation", which is why it is also used for mailbox-full conditions (as 552 5.2.2). Paired

with 5.7.0 instead — the generic security/policy enhanced code — it means something different in

practice: a content or security policy rejected the message after it was fully received, not a

storage limit. Always read the enhanced status code, not just the base 552, to tell these apart.

A real transcript

DATA
354 Start mail input
...
.
552 5.7.0 Message rejected due to content policy

How the big three use this combination

Key reasons behind SMTP error 552 5.7.0

Content policy violations

The message trips a specific content rule — sensitive data patterns (DLP), disallowed attachment

types, or organisation-specific filtering rules on the receiving side.

Security settings and concerns

Encryption requirements not met, a flagged attachment type, or a security scan that could not

complete and defaulted to rejecting rather than allowing the message through unscanned.

Diagnose it yourself

1. Check message and attachment size against the provider's documented limits first, since

552 overlaps with genuine size rejections — confirm the message is not simply too large before

assuming this is a pure policy condition.

1. Review attachment types against common DLP and content-filter block lists — executable

files, certain archive formats, and documents with active macros are common triggers.

1. Check for sensitive-looking data patterns in the message body (anything resembling card

numbers, government ID formats, or credential-like strings) if the receiving organisation is

likely to run DLP scanning — this is a very common and easily missed trigger.

1. Confirm the message is actually encrypted or signed if the receiving domain requires it —

some corporate policies reject any inbound mail that does not meet a minimum transport or

content-encryption requirement.

Step-by-step solutions to resolve SMTP Error 552 5.7.0

For general senders

1. Reduce message and attachment size well under any documented limit, not just under it.
2. Remove or convert attachment types likely to be blocked by content-scanning policies.
3. Review the message body for anything that could be mistaken for sensitive data by an automated

DLP scanner, even if nothing sensitive is actually present.

Gmail-specific

Check Workspace admin content-compliance rules if you administer the sending or receiving domain —

many 552 5.7.0 rejections in a Workspace environment come from an organisation's own configured

rule, not a Google default.

Outlook-specific

Microsoft 365's DLP policies are configurable per tenant; if you are sending to a known

organisation repeatedly and hitting this, ask their IT team what specific DLP rule is firing rather

than guessing.

Yahoo-specific

Since Yahoo rarely uses this exact combination, a 552 5.7.0 from a Yahoo-hosted domain is worth

double-checking as possibly originating from a corporate gateway in front of it rather than Yahoo's

own infrastructure.

A cause worth checking before anything else: embedded tracking or redirect links

Several corporate content filters that produce this exact combination score a message partly on

where its links actually point, not just on the visible anchor text — a tracked link that redirects

through a third-party click-tracking domain before landing on the real destination is a common,

easy-to-miss trigger, since the filter resolves the redirect chain and evaluates the destination

domain's reputation, not the domain shown in the message. If you use link tracking through a sending

platform or CRM, test the message with tracking temporarily disabled before concluding the rejection

is about attachments or DLP patterns specifically — it narrows the cause faster than auditing

content first.

What not to do

• Do not assume 552 always means "mailbox full" — the 5.7.0 enhanced code specifically rules

that out and points at a policy condition instead; chasing a storage-limit explanation wastes

time here.

• Do not resend the identical message or attachment — this is a permanent 5xx tied to the

content itself, and it will be rejected the same way again.

• Do not strip out all formatting or data reflexively without first identifying which specific

rule fired, where that information is available — an overly aggressive content strip can remove

information the recipient actually needed, for no diagnostic benefit.

MailPilot's seed-inbox network and content-focused inbox-placement checks surface whether a

specific template or attachment pattern is triggering policy-based rejections at a given provider,

which is the fastest way to isolate a 552 5.7.0 cause before sending the same content to a full

list.