Mailbox full bounce: suppress the lead or retry later? Read the status class first

The phrase is less important than the SMTP class

Gmail, for example, documents 4.2.2 for a recipient inbox that is out of storage, which is a temporary class. Other systems can use different wording or later convert a persistent condition into a permanent failure. Your parser should prioritize the numeric reply and enhanced status over the English phrase. A first temporary mailbox-full result is not the same evidence as “user unknown.”

Let the transport retry without duplicating the campaign touch

If the current message is in an SMTP queue, allow the transport to retry according to its backoff policy. Mark the campaign touch as delivery_pending and block the sequence from creating another copy. If the mailbox frees space, the original message may still be accepted. Sending a new follow-up while the first delivery is retrying increases pressure and can create confusing duplicate arrival when the recipient returns.

Set a business limit on persistence

Temporary does not mean retry forever. Once the MTA’s queue expires or the condition repeats across a defined review window, move the lead to mailbox_full_stale or manual review. At that point, re-verify the address or seek a newer business contact from an authoritative source. The important distinction is that the address has not been proven nonexistent, yet its ability to receive current outreach is poor enough that continuing automatic attempts is not useful.

Do not count mailbox full as a hard-bounce list-quality error immediately

For source-quality reporting, track mailbox-full separately from permanent invalid recipients. A list provider that returns many 5.1.1 unknown users has a different problem from one containing several employees with temporarily full storage. Over time, persistent mailbox-full addresses may still indicate stale contacts, but combining them with hard bounces on day one hides the reason. Clean metrics improve both deliverability decisions and vendor accountability.

Stop future follow-ups while delivery is unresolved

Even though the lead remains valid in principle, pause sequence progression. A follow-up is not helpful if the first message has not been accepted. Store the original touch’s delivery status and only resume cadence after the transport reaches a final state. If it eventually succeeds, calculate the next follow-up from the appropriate accepted/delivered timestamp. If it expires, require review before another campaign message is created.

A worked timeline

Monday 09:10: recipient returns 452/4.2.2 mailbox full. The relay retries with backoff. Monday afternoon and Tuesday morning produce the same temporary result. Tuesday evening the queue expires. The application now marks the touch expired-temporary and the lead mailbox_full_review, not hard-bounced. A later re-verification or confirmed new address can reactivate the lead. If instead the server returns a permanent 5.x.x recipient failure, the state can move to global suppression with that evidence attached.

Use previous successful delivery as context

If the same address accepted mail last month and suddenly reports full storage, that history supports the temporary interpretation. If an old purchased list contains an address that has never successfully delivered and remains full for repeated checks, the practical value is lower. Keep prior delivery evidence and verification dates available to the decision engine. Context should influence prioritization without overriding an explicit permanent SMTP result.

Test parser precedence

Create fixtures where the body text contains “mailbox full” but the status code differs. Assert that a 4.2.2 remains temporary, a clearly permanent recipient-level 5.x.x becomes suppressible, and a malformed notice falls into unknown review. This prevents a broad string match from overruling protocol evidence. Provider wording changes frequently; numeric class and structured DSN fields are more stable anchors.

Use a two-stage rule for quota failures

Mailbox-full wording often describes a recipient that previously existed but is currently unable to accept more mail. The SMTP class and enhanced status tell you whether the reporting system considers the condition temporary or permanent for this attempt. If it is a 4xx delivery state, keep the address out of new campaign touches while the transport retry window runs; do not immediately add it to the same global suppression class as an unknown user. If the server later returns a permanent recipient failure, or repeated quota failures exceed your business expiry window, the campaign can stop trying without pretending the address never existed.

Keep sequence timing synchronized with that state. Suppose step one receives a mailbox-full temporary failure on Tuesday. Wednesday’s scheduled follow-up should not fire merely because the calendar says one day passed—the prospect never received step one. Pause the sequence while the message is unresolved. If delivery succeeds Thursday, compute the next delay from the accepted event; if it expires undelivered, close or review the sequence according to policy. Historical context also matters: a recipient with recent successful deliveries deserves different interpretation from an address that has never accepted mail. Store the raw diagnostic so your parser can be audited when providers use quota wording alongside different enhanced codes.

Keep quota failures out of the hard-bounce denominator at first

If your quality dashboard uses hard-bounce rate to decide whether a lead source is poor, immediate classification of every temporary quota response as a hard bounce can distort the conclusion. Count the event first as a temporary delivery problem and move it only when the transport or your expiry rules produce a permanent outcome. This preserves a useful distinction between stale addresses and temporarily unavailable mailboxes. It also makes source comparison fairer: a list should not look worse simply because several otherwise valid recipients happened to hit storage limits during the measurement window.

Field checklist

• Read numeric SMTP and enhanced status before matching “mailbox full.”
• Keep the first 4.2.2-style result temporary.
• Block sequence progression while the original message is still retrying.
• Move persistent cases to stale-address review after queue expiry.
• Track mailbox-full separately from permanent invalid-recipient metrics.
• Unit-test conflicting text and status-code examples.