What to do about high bounce rates from iCloud 'user over quota' errors?
Updated on 6 Oct 2026: We added steps for persistent iCloud quota errors and clarified storage cleanup, bounce counting, and suppression rules.
The practical fix for high iCloud "552 5.2.2 user is over quota" bounces is to record the rejection, avoid an immediate manual resend, suppress addresses that keep returning the same error, and investigate where those iCloud addresses came from. The sender cannot clear the recipient's storage. Only the iCloud user can free space or upgrade their storage.
When this error is isolated to icloud.com, me.com, or mac.com recipients, treat it as a recipient mailbox condition first. If quota bounces are concentrated in welcome, back-in-stock, giveaway, discount, or other acquisition-heavy flows, compare lead sources and recent engagement before attributing the spike to signup quality.
- Immediate action: Record the 552 rejection and do not manually resend the same message straight away.
- Suppression rule: If the provider allows a later recovery attempt, keep it bounded and suppress repeated over-quota failures.
- Root cause: Audit the lead source, incentive, form protection, and consent path that produced the affected addresses.
- Reputation check: Confirm authentication and domain health only when other bounce types or domains show problems too.
What the iCloud error means
The enhanced status code 5.2.2 means mailbox full. In Apple's reply, the leading 552 is a permanent 5xx rejection for that message, even though the mailbox can recover after the recipient frees storage. By contrast, a 4.2.2 reply is temporary and permits the sending system to retry the queued message. Read the full reply: a bare 552 also appears with message-size failures, while 5.2.2 identifies a mailbox-full condition.
This is different from an authentication failure, a blocklist (blacklist) listing, or a content rejection. A full mailbox bounce points at the recipient side. A sudden concentration of those bounces in one campaign still matters because it can reveal stale data, low-intent signups, or addresses used only to claim an offer.
Do not force retries into full mailboxes
Do not override a 552 rejection by repeatedly resending the same message. Let your email service provider (ESP) apply its documented bounce policy, then use a short contact-level recovery window only if that policy treats mailbox-full recipients as recoverable.
|
|
|
|---|---|---|
First 552 5.2.2 | Current message rejected | Record and pause |
Repeated 5.2.2 | Persistent mailbox condition | Suppress marketing |
4.2.2 | Temporary mailbox condition | Use queued retry policy |
One source or flow | Source-level pattern | Audit opt-in |
Many domains and codes | Pattern requiring separate diagnosis | Check replies and setup |
Use the status code, wording, and repetition to decide what to do next.
What the recipient needs to do
Apple's iCloud storage guidance says an account that runs out of iCloud storage cannot send or receive iCloud Mail. The storage pool also covers backups, Mail, Photos, Drive, and other iCloud data, so a tidy inbox does not prove that space is available.
- Check total storage: Open Settings, select your name, then iCloud. Review total iCloud storage usage across Mail and other categories, not only the visible inbox or free space on the device.
- Review Mail on the web: Check Sent, Archive, Trash, and other server-side folders at iCloud.com, especially when a desktop mail client archives or hides copies.
- Free or add space: Apple's storage management steps explain how to delete unneeded data, empty Mail Trash, or move messages to a local mailbox outside iCloud. Moving mail to iCloud's Archive folder does not free storage. Upgrade iCloud storage if the account still needs the data.
- Request a new message: After storage is available, ask the sender to send a new copy because the message rejected with 552 was not delivered.
For account-critical mail, contact the recipient through another approved channel and explain that their iCloud account must accept mail before a replacement message can arrive. Do not include sensitive message contents in an insecure fallback channel.
If iCloud storage is available but mail still bounces
An over-quota rejection that continues after storage is freed needs an account-level check. Free space on an iPhone or Mac is separate from iCloud storage, and an empty inbox does not show the account's total usage.
- Confirm that the Apple Account for the bounced address shows available iCloud storage, including Mail and other stored data.
- If the problem began after an iCloud+ billing or plan change, confirm the currently active storage allowance. A downgrade reduces the capacity available to the account.
- Check Mail at iCloud.com and confirm that deleted messages have been removed from server-side Trash.
- Once available storage is confirmed, send one fresh test message from a separate account and check for its arrival in webmail.
Apple's iCloud Mail troubleshooting guidance recommends checking the service's system status and contacting Apple Support if the problem persists. Provide the full SMTP reply, test time, and confirmed storage usage. Keep bulk sends paused until receipt is confirmed.
How to triage the spike
Start by separating true iCloud quota bounces from other Apple-domain failures. Check the SMTP reply class, enhanced status code, bounce text, recipient domain, campaign or flow, and lead source. A bounce spike that appears only in a welcome series points in a different direction than a bounce spike across every campaign.
Flowchart showing how to classify iCloud quota bounces, audit signup sources, and suppress repeated failures.
The important distinction is whether the affected addresses are spread across the list or concentrated in one acquisition path. If the highest quota-bounce rate sits in welcome and back-in-stock flows, inspect the signup experience before changing sending infrastructure. Calculate the rate as quota-rejected messages divided by attempted messages for the same recipient-domain group and cohort, multiplied by 100. Count each message-recipient pair once, regardless of SMTP retries.
- Parse the full reply: Separate 552 5.2.2 rejections from 4.2.2 temporary failures, policy blocks, and content rejections.
- Segment Apple domains: Split icloud.com, me.com, and mac.com from other providers and typo domains.
- Count repeated failures: Track whether the same recipient returns the quota error once or across later, separate messages. Deduplicate retries and repeated webhook events for the same message.
- Map to source: Tag the form, offer, checkout step, paid campaign, pop-up, or referral path that created the address.
- Validate sender health: If other domains or bounce classes are affected, send a real test email and inspect the headers with an email tester before changing policy or infrastructure.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
When to retry or suppress iCloud quota bounces
Do not treat one iCloud quota event as proof that the address is permanently invalid. The 552 response rejects the current message, but the contact can become deliverable after the recipient frees storage. The problem is persistence. If later, separate sends return the same quota error, especially across several weeks, the address is not useful for active email programs.
Short recovery window
- First event: Record the rejection and follow the ESP's documented mailbox-full policy.
- Recent buyer: Allow a short contact-level observation period when the contact has clear recent intent.
- Transactional mail: Use another approved contact method when the message is account-critical.
Suppression trigger
- Repeated quota: Suppress after the same address fails on later, separate sends.
- Offer-only source: Sunset sooner when the address came from low-intent acquisition.
- No engagement: Use the lack of recent clicks, purchases, or site events to prioritize review when quota failures recur.
For contacts the ESP still considers recoverable, an example internal marketing rule is suppression after two quota rejections on separate messages within 30 days. Treat that threshold as a local policy example, with the ESP's native bounce handling taking precedence. Give less recovery time to low-intent signups and review recent customers separately, without overriding native suppression.
Example suppression logictext
# Local marketing example; apply native ESP bounce handling first. # Count distinct 5xx quota failures per recipient, not SMTP retries. if provider_domain in ["icloud.com", "me.com", "mac.com"] and smtp_reply_class == 5 and enhanced_status_code == "5.2.2" and distinct_quota_failed_messages_30d >= 2: suppress(marketing=true, reason="icloud_over_quota_repeat")
Do not generate extra sends solely to reach the recurrence threshold. Keep the suppression record and reason when importing or syncing contacts, so a list refresh does not reactivate the address. After the recipient resolves the storage issue and confirms successful receipt, review reactivation under the ESP's policy and the contact's existing consent.
Why lead source matters
A concentration of quota bounces in welcome and back-in-stock flows is a reason to review lead generation. Compare bounce rates and engagement by source before concluding that poor addresses are entering the list. A full mailbox alone does not establish the person's intent or consent.
Check whether these addresses came from a discount pop-up, contest, paid lead form, co-registration source, back-in-stock alert, or imported audience. With an incentive-heavy opt-in, a person can provide an old iCloud address that they rarely check. Investigate that possibility using actual engagement and recurring failures.
Source audit checklist
- Form path: Compare bounce rates by form, campaign, landing page, and popup variant.
- Offer type: Separate discount, contest, referral, and back-in-stock signups from checkout subscribers.
- Address age: Check whether quota bounces are concentrated among new signups or old dormant records.
- Validation: Use confirmed opt-in or a stricter first-send rule for risky sources.
There is also a spelling trap here. Make sure the bounce domain is actually icloud.com, not a typo domain or unrelated domain. A typo in internal reporting can send the investigation in the wrong direction.
If the issue is Apple-domain delivery more broadly, compare the symptoms against Apple-specific bounce patterns, including Apple email bounces and iCloud delivery issues. Quota bounces need hygiene work. Policy bounces need a different remediation path.
Check sender health when the issue is broader
Authentication problems do not cause a genuine 552 5.2.2 mailbox-full reply. Check sender health when failures also affect other recipient domains, include policy or authentication codes, or arrive with unusual deferrals. That broader pattern can indicate a separate sender-side problem alongside the iCloud quota bounces.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's DMARC platform supports this broader check by showing DMARC pass rates, sending sources, and SPF and DKIM domain-match results. Use its reports to investigate authentication failures alongside the SMTP replies recorded by your ESP. DMARC aggregate reports do not provide individual recipient quota-bounce logs or prove inbox delivery.
- DMARC domain match: Use DMARC monitoring to confirm that SPF or DKIM passes and meets DMARC's domain-matching requirement for the visible From domain.
- Bounce classes: Separate mailbox-full replies from authentication, policy, content, and reputation failures.
- Reputation signals: Use blocklist monitoring to investigate sender IP or domain listings when policy replies or broader delivery failures indicate a reputation problem.
- Source ownership: Make sure every sending service is approved, expected, and tied to a real business workflow.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If an authentication or reputation issue appears at the same time as the iCloud quota spike, handle it as a separate workstream. Suppress repeated quota failures while fixing the verified sender-side issue.
How to handle iCloud quota bounces in an ESP
Turn the bounce problem into a repeatable operational rule. Exact menu names change by platform, but the logic is stable: capture the complete reply, separate permanent and temporary status classes, segment affected recipients, suppress repeat failures, and report the trend by acquisition source.
- Create a segment: Filter for Apple recipient domains and complete replies containing 'user over quota', 'mailbox full', or 'out of storage', or enhanced status 5.2.2.
- Preserve status class: Keep the leading 4xx or 5xx reply so temporary and permanent handling does not get mixed.
- Add source fields: Include signup form, UTM values, list, flow, first seen date, and message ID in the export.
- Split by intent: Separate customers and recent clickers from zero-engagement incentive signups.
- Suppress repeats: Stop marketing sends after the documented recurrence threshold, especially without recent engagement.
- Watch the next cohort: After changing the form or offer, compare quota-bounce rates for new signup cohorts over the same observation window and report the attempted-message count.
If the address is tied to an active account, purchase, or support case, use another approved channel to ask the user to update their email address or clear storage. For a discount signup with no engagement and repeated quota bounces, suppression is the cleaner choice.
A practical target
After a source fix, compare the next signup cohort's iCloud quota-bounce rate with the previous cohort over the same observation window. A reduction supports the source diagnosis; a persistent spike needs further investigation.
How to prevent the next spike
Prevention comes down to better intake and faster cleanup. If people enter old iCloud mailboxes only to receive a discount or alert, the sender needs better consent quality, not more retries.
Quota-bounce response bands
Use recurrence and concentration to choose the next action for iCloud mailbox-full events.
First event
Observe
Record the 552 rejection and follow the ESP's documented policy
Repeated event
Suppress
Suppress marketing after the documented recurrence threshold
Source cluster
Investigate
Pause or fix the affected acquisition path
Confirmed opt-in is useful when a specific source keeps producing poor addresses, because subscribers must receive and act on a confirmation message before joining regular marketing. Another practical option is a stricter first-event rule: exclude a new address from normal marketing while a 552 quota rejection remains unresolved and there is no other engagement.
- Tighten forms: Use clear consent text, typo prevention, and abuse controls on high-volume forms.
- Measure by source: Report quota-bounce rate by signup path, not only by campaign.
- Stage suppression: Follow the ESP's initial bounce handling, then apply your recurrence rule only to contacts it still considers recoverable.
- Monitor the domain: Use Suped's authentication and sender alerts when the issue extends beyond quota bounces.
Views from the trenches
Best practices
Record the 552 rejection, then suppress after later sends confirm a recurring quota failure.
Segment quota bounces by source so acquisition problems do not hide inside campaign totals.
Keep authentication checks separate from mailbox-full handling, but review both together.
Common pitfalls
Do not assume iCloud quota bounces can be fixed by changing content or sending IPs alone.
Do not keep offer-only signups active after repeated quota bounces and no engagement.
Do not mix Apple policy bounces, quota bounces, and typo domains in one remediation bucket.
Expert tips
Use a shorter suppression window for new incentive signups than for recent customers.
Compare the next signup cohort after form changes rather than judging only old list data.
Use alternate contact methods for account-critical mail when the mailbox is full.
Marketer view
Marketer from Email Geeks says repeated iCloud over-quota bounces point to a recipient storage issue, so the sender's role is recording the rejection and suppressing stale addresses after repeat failures.
2024-02-20 - Email Geeks
Expert view
Expert from Email Geeks says a full mailbox acts like an abandoned mailbox when the same address fails across several sends over a month.
2024-02-21 - Email Geeks
