What does the Gmail error '452 4.2.2 The email account that you tried to reach is over quota' mean, and how should I handle it?
Updated on 24 Oct 2026: We clarified Gmail storage recovery and corrected the retry and suppression guidance for quota bounces.
The Gmail error 452 4.2.2 means Gmail temporarily refused delivery because the recipient's inbox is out of storage space. In plain terms, the person you are emailing has reached the storage quota that applies to their Gmail account. For personal Google Accounts, this storage is shared with Google Drive and Google Photos.
Handle it as a recipient-side soft bounce. Let the sending mail server retry with controlled backoff, temporarily suppress addresses that keep returning the quota response, and reserve invalid-address suppression for confirmed recipient errors such as 550 5.1.1. This quota response alone says nothing about whether your SPF, DKIM, DMARC, IP reputation, or content passed Gmail's other checks.
Google's SMTP error documentation lists 452 4.2.2 as a recipient storage failure. Google's error suffixes also matter: gsmtp marks a Google SMTP response, while gcdp points to a Google Workspace custom policy. Use the complete SMTP code and error text to decide how long to keep the message queued and when to pause future sends to that address.
Typical bounce texttext
452 4.2.2 The email account that you tried to reach is over quota. Please direct the recipient to Google's over quota help page. ... - gsmtp
What the error means
This is a mailbox capacity problem at the recipient side. RFC 3463 defines the enhanced status code X.2.2 as "mailbox full" and treats it as a persistent transient failure. Gmail uses a temporary response because the recipient can fix the condition by deleting stored data, permanently emptying Trash and Spam, buying more Google storage, or getting a Workspace administrator to adjust storage. Once Google updates the available space, a later queued retry can succeed without any change from the sender.
For Google Workspace, distinguish a user's storage restriction from the organization's pooled storage limit. Google's Workspace storage FAQ says users can still send and receive email when the organization exceeds its pooled limit. Have the recipient's administrator check the affected user's quota and license before assuming the whole organization is unable to receive mail.
- Meaning: The recipient account is full enough that Gmail refuses more mail for now.
- Class: The 4.2.2 status is temporary, so the sending server normally queues and retries the message.
- Cause: The recipient's applicable storage quota has been reached. Personal Gmail storage is shared across Google services.
- Outcome: A queued delivery can succeed after storage becomes available, or the sender can eventually expire the message and return a final bounce.
A 452 response means temporary failure, but the enhanced code matters. A 452 4.2.2 response is storage-related, while 452 4.5.3 identifies too many recipients or a per-transaction policy limit. A 550 or 552 response is permanent, but it does not always mean the address is invalid. Use the enhanced status code and error text together before deciding whether to suppress the recipient.
|
|
|
|---|---|---|
452 4.2.2 | Temporary quota | Retry |
Repeated 452 4.2.2 | Still full | Pause |
552 5.2.2 | Full and inactive | Stop this message; suppress pending recovery |
550 5.1.1 | No user | Suppress invalid address |
Queue expired after 452 4.2.2 | Sender stopped retrying | Confirm recovery before submitting a new message |
Delivered | Quota fixed | Resume |
How to classify common Gmail quota outcomes
Why delivery can resume later
A Gmail address can report over quota and then receive mail again because Gmail checks the recipient account at each delivery attempt. The address can remain valid throughout the failure. What changed is the available storage or receiving condition, not necessarily the address itself.
- Storage cleanup: Deleting large Gmail messages, Drive files, Photos uploads, or backups can reopen space after the recipient permanently empties the relevant trash folders.
- Storage purchase: A Google One plan can restore receiving for a personal account. For Workspace, ask an administrator to review the affected user's storage limit and license.
- Update delay: Google says a Google One upgrade can take up to 24 hours to apply, and large deletions can take 48 to 72 hours to appear in the storage total. See Google's storage guidance.
- Automatic retry: For 452 4.2.2, the sending server normally retries the queued message, so manual resend loops add noise and can create duplicates.
A queued message can deliver after Gmail sees the freed space. If the sending server has already expired the message and issued a final bounce, Gmail does not retain it for later delivery, so the sender must submit a new message.
In a delivery status notification (DSN), also called a non-delivery report (NDR), Action: delayed means the sender is still trying. Action: failed means the sender has stopped, even if the Diagnostic-Code still contains 452 4.2.2. A delay notice can also include a Will-Retry-Until deadline. These fields are defined in the DSN specification; a final queue-expiry notice does not establish that the address is invalid.
How recipients can fix a full Gmail mailbox
Contact the recipient by phone or another working address so they can check the correct Google Account. A personal account includes up to 15 GB shared across Google services; paid and Workspace limits differ. Google's over quota help explains how to review and reduce storage use.
- Review storage usage across Gmail, Google Drive and Google Photos. Archiving email only removes it from the inbox; it still uses storage.
- In Gmail, search for has:attachment larger:10M to find large messages. Save anything needed elsewhere, then delete messages that are no longer needed.
- Permanently empty Gmail Trash and Spam, plus the relevant Drive or Photos trash after cleanup. Items left there still count toward storage.
- If cleanup is insufficient, add storage to the personal account or ask the Workspace administrator to review the applicable user limit. Confirm that receiving works after the storage total updates.
Once space is available, let any queued message retry. Request a fresh copy only if the original delivery has already failed. Reducing an attachment does not resolve an account that remains over quota; a message-size rejection uses a different code, such as 552 5.3.4.
How senders should handle Gmail 452 4.2.2
Let the queued message retry and pause future campaigns if the address keeps failing. Do not classify a Gmail address as invalid on the first 452 4.2.2 because that discards addresses that recover after the recipient clears space.
- Record: Store the exact SMTP code, enhanced code, receiving provider, recipient, message ID, campaign, timestamp, and response suffix.
- Retry: Let the mail transfer agent (MTA) retry the queued message with backoff instead of submitting fresh copies in a short window.
- Pause: After repeated quota failures, stop normal campaigns for the address for a defined cooling-off period.
- Suppress: Use temporary suppression for persistent quota failures. A Google 552 5.2.2 ends retries for that message and warrants suppression pending confirmed recovery; 550 5.1.1 identifies a nonexistent mailbox and supports invalid-address suppression.
- Restore: After confirmed recovery or a later successful delivery, clear the temporary quota state and let normal engagement rules control future mail.
Gmail 452 4.2.2 soft bounce handling: retry with backoff, pause repeated quota failures, and suppress when appropriate.
Illustrative recipient-level suppression rulestext
# Apply to Google-hosted recipients, including Workspace custom domains. # Count each recipient/message pair once, not every delivery attempt. if receiver_is_google and smtp_code == "452" and enhanced == "4.2.2": record_quota_failure_once(recipient_id, message_id) mark_soft_bounce("recipient_over_quota") let_mta_retry_with_backoff() if quota_failed_messages_in_14_days >= 2: pause_future_campaigns() if quota_failed_messages_in_14_days >= 3: suppress_temporarily("30 days") elif receiver_is_google and smtp_code == "552" and enhanced == "5.2.2": stop_retrying_current_message() suppress_until_recipient_confirms_recovery() elif receiver_is_google and smtp_code == "550" and enhanced == "5.1.1": stop_retrying_current_message() suppress_invalid_recipient()
Do not create a global hard bounce after one quota soft bounce or after an unrelated 5xx response. Use temporary suppression after repeated quota failures. A permanent failure ends the current delivery attempt; use the recipient-specific reason to decide how future messages should be handled.
When a spike deserves investigation
A sudden increase in this error still deserves a quick investigation, especially if the audience and sending cadence were stable before. The most useful first split is simple: are the errors concentrated in the same recipients, or spread across many Gmail recipients?
Same recipients
- Pattern: A small group of addresses keeps returning the same quota error.
- Meaning: Those recipients have not cleared storage, or the storage total has not updated. Repeated failures alone do not prove that an account is abandoned.
- Action: Pause those addresses and retry on a slower schedule.
Many recipients
- Pattern: The error appears across a broader Gmail segment at the same time.
- Meaning: Review the bounce parser and retry logic, then compare the affected campaign with recent sends.
- Action: Check raw SMTP responses and recent audience changes.
If the spike is broad, check the mechanics before assuming Gmail changed something. Confirm that your ESP or MTA did not change bounce classification, that you are not counting every retry as a new recipient-level bounce, and that one campaign did not target a colder Gmail segment.
Example quota bounce thresholds
Illustrative thresholds for distinct messages with quota failures per recipient within 14 days. Count a message once regardless of its retries. Use the same example policy as the suppression rules below.
First failure
1
Keep the existing message queued for normal retries
Pause campaigns
2
Pause future marketing sends; let queued retries finish
Temporary suppression
3+
Pause future campaigns for 30 days, then review recovery
For a deeper look at reputation impact, see over quota bounces. If the message looks like a broader temporary Gmail deferral instead of a storage issue, compare it with Gmail tempfail errors.
How to rule out a separate sender issue
This response identifies a recipient storage problem. Verify the sending path when a new bounce pattern also includes other SMTP errors or affects other providers, so a separate sender issue receives the right fix.
- Raw logs: Check the final SMTP response, not only the category assigned by your ESP.
- Retry counts: Separate recipient count from retry count so one mailbox does not look like many bounces.
- Authentication: Use a domain health check to review published SPF, DKIM, and DMARC records. Inspect received-message headers to confirm actual authentication results.
- Reputation: Review blocklist (blacklist) status when many providers start failing together, not for isolated quota bounces.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's product combines DMARC monitoring with SPF and DKIM visibility and blocklist monitoring. Use Suped alongside raw delivery logs to investigate a separate authentication failure or blocklist (blacklist) listing. DMARC aggregate reports do not report recipient storage capacity or the status of your retry queue.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
A real inbox test is also useful after a routing or authentication change. Send a fresh message and inspect the authentication results with the email tester. Review the results for that tested message and sending path before returning to bounce analysis. The test does not measure the original recipient mailbox's available space.
Google Workspace Admin console Email Log Search showing a deferred Gmail 452 4.2.2 over quota result.
How to set retry and suppression rules
The default rule should protect the queue and sender metrics without discarding valid recipients too quickly. Over quota recipients can return after they clean up storage, but repeated sends to the same full mailbox create noise and waste capacity. Treat the thresholds below as an example policy for distinct messages per recipient within 14 days. They are not Gmail requirements, and individual queue retries do not increment these counts.
|
|
|
|---|---|---|
First | One distinct message with 452 4.2.2 | Keep queued |
Repeat | Two distinct messages with 452 4.2.2 in 14 days | Pause future campaigns |
Persistent | Three or more distinct messages with 452 4.2.2 in 14 days | Suppress future campaigns for 30 days, then review |
Permanent quota response | Google 552 5.2.2 | Stop this message; suppress pending recovery |
Invalid address | Google 550 5.1.1 | Suppress invalid recipient |
Example lifecycle for Gmail over quota addresses
The exact timing depends on mail type and your MTA configuration. Check the sending service's actual retry schedule and queue expiry. For transactional mail, consider the message's useful lifetime: a password reset or verification code can expire before delivery. For marketing mail, pause future campaigns sooner because the message loses value with time and repeated submissions do not help the recipient clear storage.
SMTP retry guidance generally recommends retry intervals of at least 30 minutes and a give-up time of at least 4 to 5 days. Managed sending services use their own configurable limits, so confirm the queue deadline in your logs or delivery notice. Google's storage-update delays are separate from your sender's retry window.
- Transactional: Use a retry window that respects message expiry, then contact the user through another channel if needed.
- Marketing: Pause future sends after repeated quota failures. Review recovery and engagement before resuming after a temporary suppression period.
- Sales: Stop automated sequences for the address and avoid manual resend loops.
- Systems: Keep quota bounces separate from invalid-address and spam-policy bounces.
Views from the trenches
Best practices
Pause repeated quota failures before deciding whether to suppress future campaign sends.
Keep recipient quota bounces separate from policy, authentication, and content bounces.
Track unique recipients, not only retries, so a full mailbox does not inflate reports.
Common pitfalls
Treating the first Gmail quota soft bounce as a permanent invalid address wastes leads.
Counting every retry as a fresh bounce makes a small quota cluster look like a spike.
Blaming sender reputation before checking raw SMTP text sends teams down the wrong path.
Expert tips
Use a temporary suppression state that clears after a later delivery to the same address.
Check whether the same recipients repeat before changing your whole Gmail send plan.
Separate transactional retry windows from marketing cadence because urgency differs.
Expert view
Expert from Email Geeks says the error means the recipient has hit Google storage quota, so the sender does not need to fix mail authentication for that bounce.
2023-09-05 - Email Geeks
Marketer view
Marketer from Email Geeks says repeat quota addresses should receive fewer attempts so the sender can see who clears storage and who remains unavailable.
2023-09-05 - Email Geeks
