What is an SMTP 552 error and how should it be managed?
Published 10 Jul 2025
Updated 16 Oct 2026
13 min read
Summarize with
Updated on 16 Oct 2026: We clarified SMTP 552 retry exceptions, message-size checks, and Gmail content rejections.
An SMTP 552 error normally means a mail server permanently rejected the current delivery attempt. The rejecting server can be an outbound relay, an intermediate gateway, or the recipient server. Its standard meaning is that the requested mail action was aborted because storage allocation was exceeded. In real bounce logs, the reply can point to a full recipient mailbox, an oversized message, an administrative size limit, or a provider-specific policy condition.
Do not resend the unchanged message just because the condition looks recoverable. Read the enhanced status code and the complete reply first. A 552 5.2.2 points to an over-quota mailbox. A 552 5.2.3 points to a mailbox message-size limit. For 552 5.3.4, check whether the reply names total message size, header limits, or attachment count. A 552 paired with 5.7.x text needs the policy, content, authentication, or reputation issue corrected before another attempt.
Do not suppress first and investigate later
A storage, size, or policy-related 552 is a permanent failure for that SMTP attempt, but it does not prove that the address is invalid. Suppressing every 552 contact without reading the reply removes valid recipients. Repeatedly retrying an unchanged message is also wrong because it repeats a condition the receiving server has already rejected.
What SMTP 552 means
SMTP 552 means "requested mail action aborted: exceeded storage allocation." Mail systems also attach enhanced status codes and explanatory text, which provide the useful diagnosis. Some providers use 552 with policy-oriented 5.7.x replies, so the complete line matters more than a guessed meaning based on 552 alone.
A 5.2.2 code means mailbox full. A 5.2.3 code means the message length exceeds an administrative limit for that mailbox. A 5.3.4 code means the message is too big for the receiving system. A 5.7.0 code is an undefined security status, so the accompanying text must identify the policy, content, authentication, or reputation issue. A vague 5.2.0 code gives no precise mailbox reason and needs classification using the rest of the reply and the pattern across recipients. RFC 3463 recommends reporting a full mailbox as a persistent temporary failure, commonly 452 4.2.2, although providers also return 552 5.2.2. Follow the actual SMTP reply when deciding whether the sending server should retry.
Common 552 bounce examplestext
552 5.2.2 Mailbox full 552 5.2.3 Message length exceeds administrative limit 552 5.3.4 Message too big for system 552 5.2.0 Other or undefined mailbox status 552 5.7.0 Message rejected due to policy
|
|
|
|---|---|---|
Mailbox full | Recipient quota | Hold until changed |
Administrative limit | Per-mailbox size cap | Reduce encoded size |
Message too big | System size limit | Reduce the size or count named in the reply |
Mailbox not found | Invalid address | Verify, then suppress |
Policy wording | Content restrictions or stated sender policy | Investigate evidence |
Use the full reply and provider pattern together. The three-digit code is not enough.
Google documents Gmail 552 5.7.0 as a content security rejection. Check blocked file types and archive contents first. Compressing a prohibited file does not make it acceptable; remove it or use an approved file-sharing link after confirming it is safe. Check authentication or reputation when the reply supplies that evidence. Group provider-specific failures before changing sending behaviour. These breakdowns on Gmail 552 5.7.0 and Yahoo/AOL 552 replies are useful when the exact provider wording matches.
How SMTP SIZE and encoding affect limits
Message-size failures are based on the transmitted message, not the attachment's size on disk. The total includes headers, the text and HTML bodies, MIME boundaries, inline images, and encoded attachments. Base64 expands binary attachment data by about 33 percent before MIME line wrapping and headers add more bytes. With standard MIME line wrapping, the encoded attachment is roughly 37 percent larger than the binary file. A 20 MB file therefore becomes about 27.4 MB before the rest of the message is added.
A server that advertises the SMTP SIZE extension in its EHLO reply can publish its maximum accepted message size in bytes. If the sender declares a larger SIZE value with MAIL FROM, the server can reject the message before the body is transferred. A mailbox-specific limit can also cause a 552 at RCPT TO, and a server can return 552 after the DATA transfer if the completed message exceeds a limit or the declared size was inaccurate. An advertised limit does not guarantee that every downstream server or mailbox accepts that size.
Rough encoded-size estimatetext
Base64 data size = 4 x ceil(file bytes / 3) With standard MIME line wrapping, allow about 1.37 x the binary file size 20 MB attachment x 1.37 = about 27.4 MB before other message content Add headers, body content, MIME boundaries, and inline assets Compare the complete MIME message with the applicable limit in bytes
- Measure the full MIME message: Do not compare the raw attachment alone with the provider's limit. If the reply names header size or attachment count, reduce that specific element.
- Leave headroom: A file close to the published cap will exceed it after encoding and message overhead.
- Reduce before resending: Compress or re-export files, remove inline data images, trim unnecessary HTML, or send a normal link instead of a large attachment.
- Check each destination: The receiving system or individual mailbox can enforce a lower limit than the sending platform.
When 552 means too many recipients
A legacy "552 Too many recipients" reply at RCPT TO is an exception to ordinary permanent-failure handling. RFC 5321, section 4.5.3.1.10, says clients should treat 552 as temporary when it means the server exhausted its recipient buffer. The correct reply for that implementation limit is 452.
- Reduce the number of envelope recipients per SMTP transaction and retry only those that were not accepted. Do not resend to recipients whose delivery already succeeded.
- Confirm that the reply describes a recipient-buffer limit. A configured policy restricting recipients per message is a separate condition and still requires compliance with that policy.
This exception does not make size, mailbox-quota, or content-policy 552 replies temporary. Preserve the command stage and full wording so bounce processing does not suppress valid recipients after a legacy recipient-buffer rejection.
How to classify a 552 bounce
Classify a 552 bounce by asking whether the failure belongs to one recipient, one message, one sending source, or one recipient provider. Each pattern has a different fix. Retrying the same message after a size or policy rejection wastes sending attempts. Permanently suppressing every over-quota recipient discards addresses that can become reachable after the recipient clears space.
SMTP 552 bounce classification flowchart for reading the enhanced status code and choosing a fix, retry, or suppression.
Potentially recoverable
- Quota wording: Hold the address out of normal sends and requeue only after evidence that the recipient cleared space.
- Provider spike: Pause or reduce the affected recipient domain while checking whether the reply describes a provider policy condition.
- Message issue: Fix the total encoded size, attachment, or stated content issue before sending again.
Permanent handling
- Invalid recipient: Verify and suppress when the reply says user unknown, mailbox closed, or no such address.
- Repeated policy block: Stop attempts when the stated condition remains unchanged or the same corrected recipient still fails.
- No confirmed recovery: Keep the address out of automated campaigns until a valid recovery signal exists.
Keep the raw bounce string, enhanced code, SMTP stage, rejecting server hostname, and recipient provider. In a non-delivery report, capture Diagnostic-Code and Remote-MTA when present so the rejection can be traced to the server that issued it. If a sending platform stores only a simplified hard or soft label, use that label as a routing hint rather than the final diagnosis. Outside the legacy recipient-buffer exception, the 552 response is permanent for the failed attempt, even when a recipient-side change can make a later message deliverable.
How to manage SMTP 552 errors
A reliable 552 workflow starts with evidence, then changes only the part of sending that caused the rejection. One over-quota mailbox does not require pausing every campaign. A sudden cluster of policy-style 552 replies at one provider does justify isolating that traffic while the cause is checked.
- Capture raw text: Save the SMTP reply, enhanced code, rejecting server hostname, recipient domain, sending IP, sending domain, campaign, timestamp, and SMTP command stage.
- Group by provider: Check whether the issue affects one mailbox, one recipient domain, one campaign, or one sending source. Compare a small message to another known recipient at the same domain when the scope is unclear.
- Check the message: Measure the full encoded size and review attachments, inline assets, URLs, and HTML only when the reply points to those elements.
- Check the recipient: Verify spelling and status when the reply includes mailbox-not-found, closed-account, or invalid-recipient wording. For mailbox-full wording, ask the recipient through another channel to clear space or contact their administrator about quota.
- Isolate provider issues: Reduce only the recipient providers showing an abnormal pattern while preserving unaffected traffic.
- Review sender controls: When the reply points to sender identity or authentication, confirm SPF and DKIM pass results, DMARC domain matching against the visible From domain, rDNS, HELO identity, and sending-domain consistency.
- Document the decision: Record the evidence and the condition that must change before the group is requeued, suppressed, or escalated.
A practical provider recovery pattern
When one provider returns an abnormal cluster of policy-style 552 replies, stop automatic retries for that group and resume only after the stated condition has been addressed.
Example recovery sequencetext
Stop automatic retries for the affected policy-style 552 group Separate size, quota, address, and policy replies Correct the condition named in each reply Requeue only recipients with a changed condition Resume provider traffic with a small engaged segment Hold the ramp if the provider's 552 rate rises above its established baseline
Checks for SMTP 552 policy rejections
When a 552 reply is vague, inspect the original message's headers and MIME size, then test a representative message through the same sending source. Suped's email tester adds sender-side authentication and content context before sending-volume rules are changed.
For policy-style 5.7.x replies, check the sending domain as a system. Suped's domain health checker provides a view of DMARC, SPF, and DKIM readiness. Ongoing DMARC monitoring identifies sources sending on behalf of the domain, while blocklist monitoring helps compare listing changes with policy rejection spikes when the reply supports a reputation investigation. These checks do not fix mailbox quota or message-size failures.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A test result does not replace the receiving server's reply. It adds sender-side context: whether the message authenticates, whether DNS identities are consistent, whether the full message is unusually large, and whether a policy clue in the bounce matches the message or sender setup.
Where Suped fits
Suped is our DMARC and email authentication platform. It is relevant when a 552 reply points to sender identity, authentication failures, or a supported blacklist investigation. Use the SMTP reply to establish the cause before changing domain authentication.
A practical Suped workflow is to identify the rejected message's sending source in SMTP logs, compare that source with aggregate DMARC results, check SPF or DKIM pass results and domain matching against the visible From domain, and follow issue steps for the affected source or DNS record. Aggregate reports summarise authentication observations; they are not individual SMTP bounce logs. Blocklist monitoring adds listing context when the bounce supports that investigation.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Manual workflow
- Scattered evidence: Bounce exports, DNS records, DMARC XML, and listing results need manual correlation.
- Slow source mapping: Teams need to prove which source sent the message and whether it passed authentication.
- Unclear ownership: Marketing, IT, and agency teams can lack one shared record of the repair.
Suped workflow
- Source view: Aggregate DMARC data groups observed sending sources with SPF, DKIM, and domain-matching results.
- Issue steps: Detected authentication problems point to the affected source or record and the next repair step.
- Domain context: Teams can compare related signals across the domain without treating every 552 as an authentication failure.
Mistakes that make 552 worse
Most 552 problems get worse when the response is too broad or too mechanical. A sending platform can classify a 5xx bounce as hard because the text does not match known quota wording. That protects against endless retries, but it also means a valid over-quota address can be suppressed before anyone reads the full reply.
|
|
|
|---|---|---|
Suppress all | Lost contacts | Classify first |
Retry unchanged | Repeated rejection | Fix first |
Check raw file size | Missed MIME overhead | Measure encoded message |
Ignore SMTP stage | Incomplete diagnosis | Log command stage |
Use overall rate | Hidden provider spike | Segment by provider |
The better action keeps the fix tied to the evidence in the reply.
Use rate, not count alone
Calculate the 552 bounce rate as 552 rejections divided by attempted recipient deliveries for the same provider and reporting period. Use a consistent treatment of retries in both counts. Compare each recipient provider with its own established baseline, then split the results by enhanced code and reply text. This separates a few full mailboxes from a concentrated message-size or policy failure.
Views from the trenches
Best practices
Classify 552 bounces by provider, enhanced code, and message text before suppressing contacts.
Stop size, quota, and policy retries until the stated rejection condition has been corrected.
Track each provider against its own baseline because the overall bounce rate can hide a local spike.
Common pitfalls
Treating every 552 as an invalid address removes over-quota contacts that can become reachable.
Retrying an unchanged size or policy failure repeats rejection without correcting its cause.
Checking raw attachment size misses Base64 expansion, MIME headers, inline assets, and body size.
Expert tips
Store the raw reply and SMTP command stage so ambiguous 552 events can be reclassified later.
Compare 552 rates by recipient domain and enhanced code before changing sender infrastructure.
Use authentication and blacklist or blocklist evidence only when policy wording supports the check.
Marketer view
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 view
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
Keep the raw reply, group failures by provider and campaign, and choose message repair, recipient verification, policy remediation, or suppression based on evidence. Requeue only after the relevant condition has changed.
- Hold when: The reply says mailbox full or quota exceeded and there is no evidence yet that the recipient cleared space.
- Repair when: The reply names message length, total size, file content, URLs, sender policy, or authentication.
- Suppress when: The reply clearly says the mailbox does not exist or is closed, or the corrected condition still returns permanent address wording.
- Requeue when: The message was reduced, the address was corrected, the recipient confirmed available quota, or the stated policy issue was fixed.
