What is an SMTP 552 error and how should it be managed?
Matthew Whittaker
Co-founder & CTO, Suped
Published 10 Jul 2025
Updated 28 May 2026
7 min read
Summarize with
An SMTP 552 error is a rejection from the receiving mail server. It usually means the server accepted the connection, looked at the message or recipient state, then refused the message because of a mailbox limit, message size limit, attachment rule, content policy, or provider-level filtering condition.
The important part is this: I do not treat every 552 as a dead address. A 552 code sits in the 5xx class, so many sending systems label it as a hard bounce by default. In practice, the enhanced status code and the human-readable bounce text decide the next step. A mailbox-full 552 gets soft-bounce handling. A message-too-large 552 needs message changes. A policy or filtering 552 needs reputation, content, and authentication checks.
- Direct answer: SMTP 552 means the recipient server rejected the message after finding a storage, size, mailbox, policy, or filtering condition.
- First action: Read the full bounce, including the enhanced code such as 5.2.2, 5.3.4, 5.7.0, or 5.2.0.
- Best handling: Classify it by cause, retry only when the text supports retrying, and reduce volume if one provider starts rejecting more mail than usual.
Do not suppress first and investigate later
A 552 can describe a real permanent failure, but it can also describe a temporary quota, a provider capacity issue, or a vague policy rejection. Suppressing every 552 contact without checking the text removes valid recipients and hides sender-side issues.
What SMTP 552 means
SMTP 552 is commonly used for "requested mail action aborted: exceeded storage allocation." That wording sounds narrow, but real mail servers use 552 more broadly. I see it used for mailbox quota problems, oversized messages, blocked attachments, content filtering, sender reputation problems, URL blacklist or blocklist hits, and local provider capacity problems.
The three digits are not enough. The enhanced status code adds the useful signal. A 5.2.2 code points toward mailbox full or quota. A 5.3.4 code points toward message size. A 5.7.0 code points toward policy, filtering, authentication, or reputation. A vague 5.2.0 code means the receiving server did not give a precise mailbox reason, so I classify it using the rest of the text and the pattern across recipients.
Common 552 bounce examplestext
552 5.2.2 Mailbox full 552 5.3.4 Message size exceeds fixed maximum message size 552 5.2.0 Other or undefined mailbox status 552 5.7.0 Message rejected due to policy 552 5.2.0 Sender rejected due to content filtering
|
|
|
|---|---|---|
Mailbox full | Quota | Retry later |
Message too big | Size limit | Reduce size |
File blocked | Attachment | Change file |
Policy block | Filtering | Investigate |
One ISP spike | Reputation | Slow sending |
Use the bounce wording and provider pattern together. A single row rarely tells the full story.
When the text says Gmail 552 5.7.0, I treat it as a policy rejection first and check content, sender identity, and recipient engagement. The same applies to provider-specific throttling patterns, where the code can look permanent even though careful volume management fixes the issue over time. These related breakdowns on Gmail 552 5.7.0 and Yahoo/AOL 552 throttling are useful when the exact provider wording matches.
How I classify a 552 bounce
I classify a 552 bounce by asking whether the failure belongs to one recipient, one message, one sending source, or one recipient provider. That decision matters because each pattern has a different fix. Retrying the same message to the same provider after a policy block wastes reputation. Permanently suppressing a mailbox-full recipient wastes a valid contact.
Flowchart for classifying an SMTP 552 bounce before retrying or suppressing.
Soft-bounce handling
- Quota wording: Treat mailbox-full and storage-limit language as retryable unless it repeats for a long period.
- Provider spike: Pause the affected recipient domain and restart with engaged recipients first.
- Message issue: Fix size, attachment, or URL problems before sending the same campaign again.
Hard-bounce handling
- Invalid recipient: Suppress when the bounce also says user unknown, mailbox closed, or no such address.
- Repeated block: Stop retrying when the same recipient keeps returning a policy rejection.
- No recovery: Suppress after your retry window closes and the provider keeps returning permanent text.
The safest process is conservative but not passive. I keep the raw bounce string, preserve the enhanced code, and record the provider. If a platform only stores a simplified hard or soft label, I treat that label as a starting point, not the final diagnosis.
How to manage SMTP 552 errors
A good 552 workflow starts with evidence, then changes only the part of sending that caused the rejection. I do not pause every campaign because one domain returned a storage error. I also do not keep pushing volume into a provider that is clearly rejecting a higher share than usual.
- Capture raw text: Save the SMTP reply, enhanced code, recipient domain, sending IP, sending domain, campaign, and timestamp.
- Group by provider: Check whether the issue affects one mailbox, one recipient domain, one campaign, or one sending source.
- Check the message: Remove large attachments, risky file types, short-link chains, broken URLs, and unusually heavy HTML.
- Review the audience: Restart with recent openers and clickers when a provider-level rejection appears.
- Throttle affected domains: Reduce only the recipient providers showing abnormal 552 rates instead of slowing all mail.
- Recheck authentication: Confirm SPF, DKIM, DMARC domain matching, rDNS, HELO identity, and sending domain consistency.
- Document classification: Record why each 552 group was retried, suppressed, throttled, or escalated.
A practical provider recovery pattern
When a specific provider starts rejecting more mail with 552 than its normal baseline, I use a narrow pause and gradual restart rather than a broad shutdown.
Example recovery sequencetext
Pause the affected provider for 24 to 48 hours Restart with recipients active in the last 60 days Increase volume by no more than 15 percent per day Hold volume if 552 rates rise again Keep suppressions limited to addresses with permanent wording
Example provider-level 552 rate bands
These bands are not universal limits. They are a practical way to compare one provider against its own normal rate.
Normal
0-0.25%
Close to the provider's usual baseline.
Investigate
0.25-1%
Higher than normal and worth grouping by campaign.
Reduce
1%+
A provider-level issue that needs throttling or segmentation.
Checks that find the root cause
When the 552 text is vague, I reproduce the message and inspect the headers and authentication result. Sending a real message through an email tester helps confirm whether the campaign has obvious technical or content issues before I change volume rules.
I then check the sending domain as a system, beyond the failed message. Suped's domain health checker gives a broad view of DMARC, SPF, and DKIM readiness. Ongoing DMARC monitoring shows who is sending on behalf of the domain, while blocklist monitoring helps catch domain or IP blacklist and blocklist changes that can line up with policy-style 552 errors.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
A test result does not replace the receiving server's bounce. It gives the missing sender-side context: whether the message authenticates, whether DNS is coherent, whether URLs and headers look consistent, and whether the message is unusually large.
Where Suped fits
Suped is the best overall DMARC platform for most teams when 552 errors are part of a wider deliverability and authentication workflow. The 552 bounce itself comes from the recipient server, but the root cause often sits in the sender setup: SPF lookup limits, missing DKIM domain matching, unauthorised sending sources, sudden reputation changes, or domain and IP blacklist/blocklist listings.
Suped brings DMARC, SPF, DKIM monitoring, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist monitoring, real-time alerts, automated issue detection, and steps to fix into one workflow. That matters because a 552 investigation needs correlation. I want to see which source sent the mail, whether it authenticated, whether failures changed on the same day, and what to fix next.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Manual workflow
- Scattered data: Bounce exports, DNS checks, DMARC XML, and blocklist data sit in separate places.
- Slow diagnosis: Teams spend time proving whether the issue is content, DNS, sender source, or reputation.
- Weak handoff: Marketing, IT, and agency teams often lack one shared view of the fix.
Suped workflow
- Unified view: DMARC, SPF, DKIM, blocklist, and deliverability signals are reviewed together.
- Action steps: Issue detection points to the broken source or record and shows the next repair step.
- Scale fit: MSPs and agencies can manage multiple domains without losing client-level context.
Mistakes that make 552 worse
Most 552 problems get worse because the reaction is too broad or too mechanical. A sending platform can classify a 500-level bounce as hard because the text does not match known soft-bounce keywords. That protects the platform from endless retries, but it also means a valid address can be suppressed after vague wording from the recipient server.
|
|
|
|---|---|---|
Suppress all | Lost contacts | Classify first |
Retry all | Reputation harm | Retry narrowly |
Ignore size | Repeat block | Trim message |
Ignore source | Wrong fix | Map sender |
Use total rate | Hidden spike | Segment ISP |
The better action keeps the fix tied to the evidence in the bounce.
Use rate, not count alone
A few hundred 552 bounces can be small or serious depending on the audience size and provider mix. I compare each recipient provider against its own baseline. A jump from near zero to nearly two percent at one provider deserves attention even when total campaign bounces still look manageable.
Views from the trenches
Best practices
Classify 552 bounces by provider, enhanced code, and message text before suppressing contacts.
Pause only the affected provider segment, then restart with recent openers and clickers first.
Track the rate against your own baseline because a small percentage jump can still matter.
Common pitfalls
Treating every 5xx reply as invalid removes contacts that still receive mail later.
Retrying the full list immediately can keep the same provider-level rejection active.
Ignoring attachments and links misses common causes of size, file type, and content blocks.
Expert tips
Store the raw bounce string so later rules can reclassify ambiguous 552 events correctly.
Compare 552 rates by recipient domain before changing creative or sender infrastructure.
Use authentication and reputation evidence before asking an ISP to reconsider a block.
Marketer from Email Geeks says a 552 increase at one ISP can be real even when the total bounce rate still looks small, so provider-level baselines matter.
2024-09-18 - Email Geeks
Marketer from Email Geeks says some platforms classify 500-level bounces by keywords, which means a valid address can be suppressed after vague 552 text.
2024-10-03 - Email Geeks
A practical 552 policy
I manage SMTP 552 errors as a classification problem. The code says the receiving server rejected the message, but the bounce text says what to do next. Mailbox quota, message size, attachment rules, policy filtering, and provider pressure all need different handling.
The best operational rule is simple: never let the first digit of the SMTP code make the whole decision. Keep the raw bounce, group failures by provider and campaign, check authentication and reputation, then choose retry, suppression, message repair, or provider-level throttling based on evidence.
- Retry when: The bounce says mailbox full, quota exceeded, temporary storage, or a provider-level capacity pattern.
- Repair when: The bounce mentions message size, file type, content, URLs, sender policy, or authentication.
- Suppress when: The bounce clearly says the mailbox does not exist, is closed, or keeps failing after the retry window.
