What do extremely verbose 'mailbox full' bounce messages tell us?
Published 9 Jun 2025
Updated 16 Oct 2026
14 min read
Summarize with
Updated on 16 Oct 2026: We clarified quota diagnostics and retry handling for verbose mailbox-full bounces.
Extremely verbose "mailbox full" bounce messages usually tell us one useful thing and a lot of noisy internal detail. The useful thing is normally near the front: the receiving system could not allocate enough mailbox storage for the message and returned a status such as 5.2.2 or 552 5.2.2. The rest is often a storage-driver trace, exception chain, mailbox database identifier, or provider-specific debug output meant for the receiver's logs rather than your bounce processor.
The practical reading is simple: classify the bounce by the structured status and clear human-readable reason, keep enough raw text for audit, and do not let the long diagnostic tail drive list-removal decisions by itself. A verbose bounce can look severe because it contains words like "permanent exception", but a mailbox quota condition does not always mean the address is invalid. It means the receiving system reported a storage or quota problem for that delivery attempt.
What the verbose bounce is actually saying
A long bounce message is not a long list of separate reasons. It is usually one delivery failure wrapped in internal stack detail. In a message like smtp;554 5.2.2 mailbox full, the strongest evidence appears before the diagnostic stream. The receiving server identified the destination mailbox, tried to create or store the message, then failed because a storage quota or capacity limit blocked delivery.
Compressed exampletext
smtp;554 5.2.2 mailbox full; STOREDRV.Deliver.Exception:QuotaExceededException; Failed to process message due to a permanent exception; [Stage: CreateMessage]
The phrase mailbox full gives the human reason. The enhanced status code 5.2.2 normally reports a permanent mailbox-full result, while 4.2.2 identifies the same subject as a persistent temporary failure. A storage-driver exception indicates a failure in the mailbox delivery path; it does not establish whether sender authentication passed. Opaque numeric fields are usually implementation detail. They can help the receiving provider debug its system, but they rarely change the sender-side action.
Provider wording matters. Microsoft's Exchange Online NDR reference also documents 5.2.2 Submission quota exceeded for sender rate limits. Classify that as a sender submission limit, not a full recipient mailbox. Do not suppress recipients because of that diagnostic.
Fast interpretation
Read the structured delivery status notification (DSN) fields first. Then compare the SMTP reply and plain-language reason. If they consistently identify a quota condition, treat the remaining trace as supporting detail unless it names a more specific storage limit.
- Read a status such as 5.2.2 together with the provider's reason to distinguish mailbox storage from other quota limits.
- Human reason: Phrases such as mailbox full, quota exceeded, or over quota are stronger evidence than most internal trace fields.
- Trace detail: Provider-specific exception names can identify a hidden folder, shared store, or special quota, but opaque IDs seldom change list handling.
- Operational action: Store the full raw bounce somewhere searchable, then normalize the visible reason into a stable category for reporting.
A mailbox does not need to be completely out of space for every message. A large message can exceed the remaining quota while a smaller message still fits. If the DSN reports X.2.3 or X.3.4 or explicitly says the message exceeds a size limit, classify that as a message-size failure rather than mailbox full. A bare 552 also occurs with excessive message size, so confirm the enhanced code and diagnostic. See SMTP reply definitions.
Verbose mailbox full bounce decoded into SMTP reply, enhanced status code, quota reason, and internal trace.
Why a mailbox full bounce can be a 5XX
The surprising part is seeing a mailbox-full condition returned as a 5XX. Many senders expect over-quota to be temporary because the recipient can delete mail later. That expectation matches RFC 3463, which describes X.2.2 as a persistent transient failure. SMTP implementations do not always follow that recommendation. A 4XX SMTP response tells the sending mail transfer agent (MTA) to try later while the message remains queued. A 5XX quota response tells it to stop retrying that delivery.
A 554 5.2.2 mailbox full response therefore combines a permanent reply class with a mailbox-full subject and detail code. Read both layers. The leading 5 controls queue behavior for that delivery, while the matching quota reason identifies the failure category. It reports that this delivery failed; it does not prove that the address is permanently invalid.
4XX quota response
The receiver expects a later attempt to succeed, or at least leaves that possibility open during the delivery cycle.
- Queue behavior: The MTA normally retries while the message remains queued; a final failed DSN ends that cycle.
- List action: Count it as a soft bounce and wait for a pattern before suppression.
5XX quota response
The receiver rejected this message as undeliverable, even though the mailbox can become available later.
- Queue behavior: The MTA stops retrying the exact message after the final bounce.
- List action: Keep the quota reason separate from your sending platform's hard-bounce suppression rules.
Do not treat every 5XX as proof of an invalid address or a request to unsubscribe. The reply class matters, but the enhanced code and reason text also matter. Keep mailbox capacity separate from unknown user, disabled mailbox, policy rejection, and blocklist rejection. Hard bounce and soft bounce are platform labels; check your sending platform's suppression policy before reactivating a contact.
|
|
|
|---|---|---|
4.2.2 | Persistent temporary mailbox-full condition | Retry only while the original MTA is still trying |
554 | Permanent failure for this delivery attempt | Stop retrying that message |
5.2.2 | Normally mailbox full; confirm provider wording | Classify with the diagnostic |
STOREDRV | Mailbox delivery path failed | Inspect the named subtype |
QuotaExceededException | A storage quota exception in the delivery path | Apply recurrence policy |
5.2.2 Submission quota exceeded | Microsoft sender submission limit | Review sender rate limits; do not suppress recipients |
Compact interpretation of common quota-related bounce parts.
What the long internal trace can and cannot prove
In a genuine DSN, the trace helps identify the reported delivery stage, such as message creation or store delivery. It does not prove the mailbox owner abandoned the address, and it does not prove your sending infrastructure has an authentication problem. That distinction matters because bounce processors often overreact to the largest string in the record instead of the clearest signal.
When a diagnostic message includes strings such as QuotaExceededException and CreateMessage, treat them as extra evidence of a storage failure. They do not establish which authentication checks passed. Use the SMTP transcript and authentication results when the exact rejection stage matters.
How much weight to give each signal
Start with structured DSN fields and the clear SMTP reply. Use trace detail as supporting evidence.
High weight
First
DSN Action and Status fields
Medium weight
Second
SMTP reply, plain reason, and matching named exception
Low weight
Last
Opaque numeric fields, IDs, and long trace fragments
Do not discard the whole tail
Truncating every bounce after the first short phrase can hide account-disabled, policy, or abuse signals in other providers' messages. Normalize for dashboards, but keep raw bounces in logs with enough length to inspect later. Limit access and retention because raw DSNs can contain recipient addresses, message headers, and internal hostnames.
Why a mailbox looks empty but still rejects mail
A mailbox-full diagnostic identifies a quota condition, but the visible Inbox size does not always show the quota that failed. Check the storage named in the diagnostic before concluding the recipient abandoned the address.
- For Outlook.com, Microsoft Unified Storage is full means the Microsoft cloud storage quota is exceeded. OneDrive files and Outlook.com attachments count toward that quota, so mail can stop even when the email storage meter is below its limit. See Outlook.com storage limits.
- For Exchange Online, ask an administrator to compare visible mailbox usage and the hidden Recoverable Items folder against their separate quotas. A full Recoverable Items folder can prevent deletion and complicate cleanup. Microsoft's mailbox quota troubleshooting explains the checks.
- For mail-enabled public folders, the individual folder's post quota or the hosting public folder mailbox can block delivery. Microsoft's public folder quota guidance documents the same 554 5.2.2 mailbox full diagnostic.
- For an ordinary Outlook.com mailbox, moving messages to Deleted Items does not immediately free mailbox quota. Unneeded items must also leave Deleted Items before that space becomes available.
For an important individual message, contact the recipient through another channel and share the diagnostic. Ask the recipient or administrator to free space or adjust the applicable quota. After they confirm recovery, send a new copy if the original delivery has ended.
How to classify and act on these bounces
Classify verbose mailbox-full bounces into a quota category first, then decide the contact action based on recurrence. One bounce is not proof of permanent invalidity. Keeping an address active forever because "mailbox full" sounds temporary creates the opposite problem. Use a staged policy based on bounce count, failure age, recent engagement, subscriber context, and provider pattern.
- Parse the durable fields: Extract DSN Action and Status, SMTP reply, reporting server, recipient, and reason. Join campaign data from outbound logs.
- Create a quota category: Group mailbox full, over quota, and quota exceeded separately from unknown user, disabled mailbox, and policy rejection.
- Retry with limits: Let the original MTA handle queued temporary failures; do not automatically resubmit the original message after Action: failed, even when Status starts with 4.
- Suppress by pattern: Move addresses to temporary suppression after repeated quota bounces, then to longer suppression if the pattern continues. Count distinct messages, not retry attempts or duplicate DSNs.
- Reset on recovery: When a later message is delivered, clear the active quota-failure streak while retaining historical events for analysis.
- Review domain spikes: If one provider suddenly spikes, compare bounce text with recent sending volume and check whether the provider changed its reporting behavior.
For the broader troubleshooting path, use Suped's email tester to inspect authentication and message headers, including content signals, on a real sent message. That will not tell you whether a particular recipient mailbox is full, but it helps separate recipient-side quota failures from sender-side configuration problems.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Repeated evidence matters most for mailbox-full handling. A recipient who bounces once during a large campaign can recover. An address that returns quota failures for months remains unreachable, but this does not establish whether the recipient reads existing mail. Shared mailboxes, abuse addresses, public folders, and operational inboxes can fill during normal use.
|
|
|
|---|---|---|
One event | Quota reported for one delivery | Follow queue status; avoid immediate resends |
Repeated events | Ongoing storage issue | Pause sends |
Many over weeks | Persistent quota problem, not proof of abandonment | Use longer suppression |
Successful delivery | Mailbox recovered | Reset active streak |
Provider spike | Provider incident or changed diagnostics | Investigate |
A practical suppression model for quota bounces.
When the same provider starts returning quota language for many addresses at once, do not assume every user ran out of storage on the same day. Compare the spike with campaign volume, segment quality, engagement age, and any provider-specific incident. Check the full diagnostic for a sender submission limit before counting recipient quota failures. The same logic applies when investigating Microsoft bounces or deciding whether mailbox full remains a useful bounce category.
Where authentication and reputation still matter
A mailbox full bounce is primarily recipient-side, but sender-side health still needs review when these bounces appear alongside other failures. Authentication failures, blocklist (blacklist) listings, and poor domain reputation can appear next to quota bounces in the same campaign report. Looking only at one verbose diagnostic can hide the wider pattern.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped is our DMARC and email authentication platform. Use Suped to review sending sources and DMARC results while your bounce processor tracks recipient quota failures.
Check whether authenticated mail streams pass consistently. A DMARC monitoring view shows whether legitimate platforms use the expected domain and whether unknown sources send with your domain. A domain health check covers DMARC, SPF, DKIM, and related DNS signals. If quota bounces appear with reputation rejections, blocklist monitoring helps confirm whether IP or domain listings are part of the problem. Aggregate DMARC reports describe authentication results, not individual mailbox capacity or delivery outcomes.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Classify quota bounces separately from DMARC failures. Compare the categories by domain, provider, campaign, and source when the same mail stream has both kinds of failure.
Suped workflow
- Check authentication: Confirm DMARC domain matching and identify unauthenticated sources sending with your domain.
- Inspect reputation: Review blacklist results when quota bounces appear alongside policy rejections.
- Fix sender-side issues: Follow Suped's issue steps when DNS or authentication problems are present.
- Keep quota handling separate: Use the bounce processor for recipient recurrence and suppression decisions.
Read structured DSN fields before prose
A standards-formatted delivery status notification (DSN), often called a non-delivery report or NDR, separates machine-readable recipient fields from the human explanation. Parse the message/delivery-status part before scanning the surrounding prose. The Status field gives the transport-independent result, while Diagnostic-Code preserves the reported transport diagnostic.
Structured DSN exampletext
Final-Recipient: rfc822; recipient@example.com Action: failed Status: 5.2.2 Remote-MTA: dns; mx.example.net Diagnostic-Code: smtp; 554 5.2.2 mailbox full; STOREDRV.Deliver.Exception:QuotaExceededException
Action: delayed means the reporting MTA is still trying. Action: failed means delivery has ended, even with Status: 4.2.2 after retries expire. RFC 3464 defines Action separately from Status. If forwarding changes the address, correlate Final-Recipient with Original-Recipient when present and your outbound records.
|
|
|
|---|---|---|
Action | Whether delivery failed, was delayed, or completed | Set recipient-level outcome |
Status | The normalized enhanced status code | Choose the reason family with provider context |
Diagnostic-Code | The actual SMTP or transport diagnostic | Confirm provider wording |
Final-Recipient | The recipient described by this DSN block | Avoid applying one result to every recipient |
Original-Recipient | Original envelope recipient, when supplied | Correlate forwarded addresses with outbound records |
Remote-MTA | The remote mail server that reported status, when present | Support provider grouping |
Use these DSN fields before provider-specific trace text.
Treat DSNs as untrusted input
A DSN can be forged, malformed, or forwarded through another system. Bound field lengths, unfold continuation lines safely, redact sensitive data in logs, and correlate the report with an outbound message identifier before changing contact status.
How to build a defensive parser
A bounce parser should be boring and defensive. It should extract stable fields, compare codes with the reason, and avoid overfitting to one provider's noisy diagnostic format. Apply documented provider exceptions before generic quota matching, and send conflicting codes and reasons for review. It does not need to understand every numeric field in a storage-driver trace. It needs the delivery class, reason family, recipient domain, and evidence required for retry or suppression.
DSN outcome and reason extraction sketchtext
# Helpers inspect only this recipient's diagnostic. queue_action = "check_original_queue" if action == "failed": queue_action = "delivery_finished" elif action == "delayed": queue_action = "original_mta_retries" if documented_provider_submission_limit(reason): category = "sender_submission_limit" elif code_reason_conflict(status, reason): category = "manual_review" elif status == "5.1.1": category = "invalid_recipient" elif status in ["4.2.2", "5.2.2"]: category = "mailbox_quota" elif explicit_mailbox_quota(reason): category = "mailbox_quota" else: category = "unclassified"
Store at least four versions of the bounce: raw text, normalized reason, provider-specific subtype, and final contact action. This separation makes later cleanup easier. If a provider changes wording, reprocess the raw data. If the suppression policy changes, update the action without losing the original evidence. Process each recipient block separately and deduplicate events by outbound message and recipient before updating the failure streak.
Mailbox full bounce handling flow: read status, identify quota, check history, choose an action, and retain diagnostics.
Views from the trenches
Best practices
Keep raw bounce text available while showing a normalized reason in dashboards and reports.
Classify quota bounces separately from unknown user, disabled mailbox, and policy errors.
Use recurrence and age of engagement before moving mailbox-full addresses to suppression.
Common pitfalls
Truncating diagnostics too early can hide the only clear reason in some provider bounces.
Mapping every 5XX bounce to permanent removal ignores useful enhanced status detail.
Treating one full mailbox as proof of abandonment removes addresses without enough evidence.
Expert tips
Read DSN Action and Status together, then confirm the category against the provider's reason.
Watch provider-level spikes because wording changes can look like sudden list decay.
Keep quota, reputation, and authentication failures in separate reporting categories.
Marketer view
Marketer from Email Geeks says verbose quota bounces often contain far more diagnostic detail than senders need, so the useful reason should be extracted and the rest kept for audit.
2019-09-20 - Email Geeks
Marketer view
Marketer from Email Geeks says the best outcome in a noisy bounce is when the actual mailbox-full reason appears early enough that truncation still preserves the key clue.
2019-09-20 - Email Geeks
