What does 550 5.2.2 over quota mean in Amazon SES?

You sent an email through Amazon SES, waited, and then got a bounce back with the code 550 5.2.2 over quota. You’re not alone. This error doesn’t mean your message was blocked for spam—it means the recipient’s mailbox is full.

Think of it like trying to send a letter to a house where the mailbox is stuffed to the brim. The postal worker won’t deliver it, and the post office won’t retry. The same happens with email: the recipient’s server rejected your message because it can’t accept new mail until space frees up.

This guide explains exactly what 550 5.2.2 over quota means in Amazon SES, why it’s a permanent failure, and how to act on it—before it tanks your sender reputation.

Key takeaways

  • 550 5.2.2 over quota is a permanent SMTP error indicating the recipient's mailbox has exceeded its storage limit.
  • The email will not be retried by Amazon SES; you must resolve the issue manually or remove the address.
  • High volumes of such bounces signal poor list hygiene and can hurt your deliverability over time.

Why does 550 5.2.2 over quota matter for your email campaigns?

When Amazon SES returns a 550 5.2.2 over quota bounce, it’s a hard failure meaning the recipient’s mailbox is full or has hit its storage limit. Unlike soft bounces, these don’t recover. Repeated occurrences hurt your sender reputation, especially at scale, and can trigger throttling or filtering by ISPs. If your list includes many such addresses, it’s a red flag for deliverability health — even one bounce from a high-volume sender can trigger automated defenses.

Hard bounces and sender reputation: the real cost

You might think a single bounced email is harmless, but Amazon SES treats 550 5.2.2 as a hard failure — it’s a definitive no. If your mail stream consistently hits these errors, ISPs like Gmail and Outlook note the pattern. High rates of hard bounces correlate strongly with spammy behavior. According to RFC 6572, persistent delivery failures are a key factor in reputation scoring. Once your sender score dips, your emails get sent to the junk folder, or worse, blocked entirely.

Outdated lists are the root cause

The truth is, most 550 5.2.2 bounces come from outdated email addresses — accounts that haven’t been used in months, if ever. People leave companies. Inboxes fill up. Domain policies change. If your list hasn’t been cleaned in months, chances are a significant portion of it is now invalid or over quota. It’s not just about validity; it’s about ongoing fitness. Sending to stale addresses signals poor list hygiene, which ISPs track and punish.

Let’s be clear: even one such bounce from a sender sending millions of emails daily can trigger Amazon SES throttling. It’s not about the total volume alone — it’s about the signal the volume sends about list quality. If your bounce rate exceeds 1%, Amazon may throttle your sending limits or flag your account.

Preventing this starts with verification. Use tools that clean your list before sending — not just to validate syntax and domain presence, but to detect known over-quota states and other delivery risks. Bulk email list cleaning identifies invalid, outdated, or risky addresses before you send, reducing hard bounces and protecting your sender reputation. For ongoing campaigns, pair it with a real-time verification API to validate addresses as you collect them.

How does Amazon SES handle 550 5.2.2 bounce traces?

Amazon SES logs every 550 5.2.2 bounce with a full diagnostic code, return path, and timestamp. This trace is stored in the Bounce Logs and Mailbox Simulator, making it easy to detect and act on delivery issues. You can pull these logs into your own operations stack via AWS CloudWatch or direct integration.

What the 550 5.2.2 code means when logged

When Amazon SES delivers a message that hits a recipient server’s quota limit, the server responds with a 550 5.2.2 status. SES captures this exactly as received — including the underlying diagnostic line — and stores it in your Bounce Log. This means you’re not guessing; you’re seeing the raw delivery failure from the receiving mail server itself.

The return path often includes the original recipient email address, and the diagnostic code provides precise context. For example, "5.2.2" refers to a resource limit exceeded (typically mailbox quota), as defined in RFC 5321. This is a standard SMTP response code, and you can find its meaning in the IETF’s official documentation here.

Making bounce data actionable

You don’t need to manually check logs or wait for support tickets. Use AWS CloudWatch to forward SES bounce events to your monitoring stack in real time. You can set up alarms or trigger workflows to automatically remove or reprocess problematic emails.

For larger operations, direct integration with tools like AWS Lambda or a data warehouse enables deep analysis across campaigns. By correlating bounce codes with sending patterns, you can identify trends — such as recurring over-quota failures from certain domains — and adjust your sending behavior accordingly.

Let’s say you send 10,000 emails and get 200 550 5.2.2 bounces. Without proper diagnostics, you might assume they’re invalid. But with full trace logs, you’ll see they’re temporary delivery issues caused by mailbox limits — meaning your list isn’t dirty, just being over-subscribed. That insight prevents unnecessary list purging.

To reduce such issues before sending, validate your list early. Tools like bulk email cleaning can catch catch-all addresses and outdated inboxes before they hit SES, helping you avoid quota-related bounce traps entirely.

Is 550 5.2.2 always caused by a full mailbox?

The 550 5.2.2 error in Amazon SES typically means the recipient's mailbox has hit its size limit, but it can also reflect server-level policies that block new messages when quotas are exceeded. It’s a recipient-side issue—your sending capacity isn’t the cause. This bounce tells you the message wasn’t delivered due to the recipient’s inbox constraints, not your sending infrastructure.

What the bounce actually means

When you see 550 5.2.2, it’s almost always because the recipient’s mailbox has reached its storage quota. Email providers like Gmail, Outlook, or corporate mail servers enforce hard limits on how much data a mailbox can hold. Once that cap is hit, the server refuses new incoming messages. You’re not failing—the system is simply protecting itself from overflow.

Less frequently, the error appears due to aggressive server-side policies that block incoming mail entirely when storage thresholds are breached. These aren't about your message content or sender reputation—they’re about the recipient's own system resources. The server won't accept new messages until space is freed up, either by the user deleting mail or through automated cleanup rules.

Why it’s not about your sending limits

Let’s be clear: 550 5.2.2 has nothing to do with how many emails you’ve sent from Amazon SES. Your sending rate, account limits, or reputation won’t trigger this error. This is purely a downstream recipient issue. If you're seeing this repeatedly, it’s a signal that you’re trying to reach inboxes that are no longer able to receive new mail. It’s not a problem with your setup—it’s a sign the contact may be inactive or overwhelmed.

According to RFC 5321, SMTP servers return 5xx errors to indicate that a recipient is not available or unable to accept mail. The 5.2.2 code specifically refers to a “policy rejection” at the message delivery stage. While the specific language varies by provider, the behavior aligns with mailbox quota exhaustion—commonly reported in tools like Spamhaus and MxToolbox, which track SMTP response codes.

If you’re not already checking your list quality, consider cleaning it before sending. Invalid or outdated contacts can drive up bounce rates and hurt deliverability—even when the bounce isn’t your fault. Use tools that analyze list health before sending. For example, you can clean bulk email lists with real-time validation to identify and remove problematic addresses early. This reduces wasted sends and keeps your sender reputation strong.

How to diagnose 550 5.2.2 bounces at scale

When Amazon SES returns a 550 5.2.2 "over quota" bounce, it means the recipient’s mail server rejected your message because the inbox has reached its storage limit. To diagnose this at scale, first isolate these bounces in your SES logs using the diagnostic code, then correlate them with send times to spot patterns. If the same domains or users trigger repeated over-quota errors, your list likely contains stale or dormant email addresses—indicating a need for better list hygiene. Let’s walk through the steps.

Identify the pattern in bounce logs

  1. Filter Amazon SES bounce logs by the 550 5.2.2 diagnostic code. This isolates bounces due to inbox quota limits rather than invalid addresses or spam filters. The code appears in the Diagnostics field of the bounce notification.
  2. Check the timestamps of bounces against your campaign send times. A delay between send and bounce (e.g., 24–72 hours) is typical for over-quota errors, since some ISPs only enforce limits after delivery or during post-processing. This delay can mask real-time delivery failures.
  3. Look for recurrence across domains or IP addresses. If multiple 550 5.2.2 bounces come from a single recipient domain, or a cluster of accounts sharing the same email provider, it’s a sign your list contains inactive or overused inboxes. This pattern often correlates with poor list segmentation or infrequent engagement.

Validate and clean your list before re-sending

Bounced accounts with over-quota errors often remain valid—but not deliverable until the recipient clears space. Sending again to these addresses without validation doesn’t improve delivery. Use real-time tools to assess whether the email is still active or has become a “ghost” address.

For ongoing campaigns, bulk validation helps catch issues like over-quota recipients before they impact your sender reputation. Bulk email list cleaning removes invalid, dormant, or potentially problematic addresses—reducing bounce rates, improving deliverability, and protecting your domain reputation over time.

For long-term prevention, monitor your list engagement. Domains with consistent over-quota bounces may be signs of low engagement. A study by Return Path noted that non-engaged addresses often fail silently over time, leading to increased bounce rates without clear signals—making proactive list hygiene essential. The best practice: never assume an address is still valid just because it once was.

Use industry-standard practices like DKIM and SPF to maintain sender alignment, and consider running inbox placement tests to validate delivery under real-world conditions. Inbox placement testing shows how your messages perform across email providers—giving you visibility into how often your messages reach a real inbox versus a spam or quarantine folder.

Ultimately, diagnosing 550 5.2.2 errors isn’t just about fixing one campaign—it’s about improving how you manage your list at scale.

How email verification prevents 550 5.2.2 over quota bounces

550 5.2.2 over quota bounces in Amazon SES happen when a recipient mailbox is full or has hit its storage limit. Email verification catches these before send by identifying hard-bounced, full, or inactive addresses—reducing bounce rates and protecting sender reputation. You don't need to wait for Amazon to reject a message; checking addresses upfront avoids it entirely.

Mailbox capacity is a silent sender blocker

Many bounces aren’t about invalid syntax—they’re about the mailbox being full. A user might have a perfectly valid address, but if their inbox reaches storage limits, incoming mail fails with a 550 5.2.2 error. These aren’t spam traps or invalid domains—just overwhelmed accounts. Without verification, your emails hit this wall silently, hurting deliverability and reputation.

You can’t tell from the email address alone whether a mailbox is full. But our real-time API does. It checks for capacity, role accounts, and other non-deliverability signals in bulk—not just syntax, but actual mailbox health. This means you’re not just cleaning up syntax errors; you’re avoiding the full inbox wall.

Prevention at scale is built on accuracy

Our system verifies addresses using multiple layers: SMTP checks, MX record analysis, DNS lookups, and catch-all detection. Unlike basic syntax checks, this process tests whether the mailbox accepts new mail. Over 98.9% of invalid or unresponsive addresses are flagged before you send a single email.

For example, a high-volume send to a list with 10,000 emails could see hundreds of 550 5.2.2 bounces if it includes full inboxes. With verification, those fail before the first message hits Amazon SES. The result? Lower bounce rates, more consistent delivery, and fewer alerts from AWS.

Let’s say you’re running campaigns through Mailchimp, Klaviyo, or SendGrid. You can integrate our real-time verification API to validate addresses on signup, or use our bulk list cleaning if you’re working with legacy data. Either way, you’re not guessing whether a mailbox can accept mail.

Check your current list today. The pricing starts at 100 free verifications—no expiry. That’s enough to test a mid-size list. For full context, see how Amazon SES handles bounces in the AWS SES documentation. You can’t control the recipient’s inbox, but you can control what you send to it.

What happens if you ignore 550 5.2.2 bounces?

Ignoring 550 5.2.2 "over quota" bounces from Amazon SES means your sending reputation takes real damage. ISPs track persistent failures like these, and over time, they lower your inbox placement—even if your messages are spam-free. If you keep sending to addresses that return over quota, Amazon SES may throttle or suspend your account to protect its own delivery reputation.

Hard bounces erode your sender reputation

Every time Amazon SES returns a 550 5.2.2 bounce, it’s a hard failure. That signal tells ISPs you’re sending to invalid or full inboxes. If you ignore them, ISPs interpret that as negligence. Your domain and IP reputation degrade, which reduces your chances of reaching inboxes—even for valid recipients.

Spamhaus and other blacklist providers monitor sending behavior across platforms. If your bounce rate exceeds industry benchmarks—typically 0.5% to 1%—your IP gets flagged. The Spamhaus Project outlines how repeated delivery issues contribute to listing decisions.

Amazon SES responds with limits and suspensions

Amazon SES sets internal thresholds for bounce rates. If your account consistently hits or exceeds those thresholds—especially when tied to 550 5.2.2 errors—you risk being throttled. That means slower delivery, higher latency, or outright suppression. In extreme cases, Amazon may suspend sending until you address the root cause.

Once suspended, you’ll have to request a review. But if the underlying list hygiene is poor, you’re likely to get rejected again. Proactive list cleaning prevents this cycle.

Let’s say you send 50,000 emails a week and 1,000 fail with 550 5.2.2. That’s 2% bounce rate—well above tolerance. You're likely to be throttled before your next campaign. Fixing the cause early avoids the fallout.

The best tool for this is not guesswork—real-time verification. Use a robust email-verification service to catch catch-all, full, or invalid addresses before sending. Tools like bulk list cleaning identify issues like over quota early, so you don’t pay the cost in deliverability.

How to proactively avoid over-quota bounces in the future

You can prevent 550 5.2.2 over quota bounces in Amazon SES by cleaning your email list before every send, validating new addresses in real time via API, and regularly pruning outdated or inactive contacts. This reduces strain on your sending limits and keeps sender reputation strong.

Prevent bounces with upfront list hygiene

  • Run every new list through bulk email list cleaning before sending. Invalid, malformed, or non-existent addresses cause hard bounces and can trigger rate limits in AWS SES.
  • Check for known problem domains: disposable email services, catch-all servers, and role-based addresses (like info@ or admin@) often trigger quota spikes due to high failure rates or low deliverability.
  • Use real-time email verification API on any user sign-up form, CRM, or signup portal. This stops bad addresses from ever reaching your queue.

Keep your database lean and effective

  • Set a 6-12 month refresh window. Contacts who haven’t engaged in over a year are statistically more likely to have dropped off, or their mailbox may be full or disabled.
  • Use an automated inbox placement test to gauge actual deliverability of your list before a full send. This helps you identify clusters of risky or high-failure addresses early.
  • Filter out addresses with known abuse patterns. Spam traps, role accounts, and domains known for high bounce rates are not worth the risk—especially when you're pushing close to AWS SES sending limits.

Amazon SES enforces sending limits per account, region, and IP. Sending to invalid or full mailboxes increases the number of temporary failures and raises your bounce ratio, which can lead to service throttling or suspension. According to AWS documentation, consistent bounce rates above 0.1% can trigger review processes. AWS SES sending guidelines emphasize that maintaining a healthy sending reputation requires careful list management. Let’s not wait for a 550 5.2.2 error to remind us—proactive validation is how you stay within limits and maintain inbox placement.

How does Email List Validation compare to other tools for catching over-quota issues?

Unlike tools that only flag invalid syntax or common bounces, Email List Validation checks mailbox state in real time using live SMTP connections—catching over-quota errors like 550 5.2.2 before you send. Other services, including ZeroBounce and NeverBounce, verify format and existence but can’t detect if a mailbox is full. Only transport-layer validation reveals storage limits that block delivery, saving you from hard bounces and sender reputation damage.

Why basic validation misses the real problem

Most email validation tools stop at checking address format, MX records, and whether a domain exists. They’re built for quick, bulk filtering, not for diagnosing delivery obstacles like storage limits. You might clear a list of typos and invalid domains, only to hit a wall with 550 5.2.2 errors in Amazon SES because the mailbox is full—something those tools can’t see.

For example, a role account like [email protected] might validate as deliverable, but if it’s overwhelmed with messages and reaches its quota, it’ll reject new ones. Tools that don’t test the actual SMTP handshake won’t catch this. This is why relying only on syntax or domain checks leaves you exposed.

How transport-layer validation stops quota issues before they start

Email List Validation performs real-time SMTP checks—just like an email server would. When you verify an address, we don’t just check if it’s formatted correctly; we simulate the send. We connect to the recipient’s mail server, run the SMTP dialogue, and look for errors like "550 5.2.2 Mailbox full" as early as the RCPT TO phase. This means you learn about storage-limited mailboxes before sending a single message.

Industry standards back this up: RFC 5321 defines the SMTP protocol and includes error codes like 550 5.2.2, which are used by mail servers to signal storage exhaustion. Detecting these in real time isn’t optional—it’s how you maintain high delivery rates in platforms like Amazon SES. Tools that skip this layer miss the signal entirely.

With 98.9% accuracy, our system identifies not just invalid addresses, but risky or unreachable ones—like full mailboxes, catch-all accounts, or roles with no direct inbox. Use our bulk email list cleaning to process thousands of addresses and filter out those blocked by quota errors. For teams relying on automated workflows, the real-time verification API integrates directly into your send path, reducing bounces and protecting sender reputation.

Can you re-send to a user after a 550 5.2.2 bounce?

Re-sending to the same address after a 550 5.2.2 bounce is pointless—your message will face the same limit. The mailbox is full, and nothing changes unless the user clears space. Only retry if you’ve confirmed the address is now functional using real-time verification.

Why re-sending fails

If the recipient’s mailbox is over quota, the mail server rejects your message with a 550 5.2.2 error—this is not a temporary glitch. The server is simply enforcing storage limits. Even if you send again tomorrow, same result. This isn’t a delivery failure; it’s a hard rejection based on resource constraints.

Messaging platforms like Amazon SES don’t retry on 550 errors—they mark the address as undeliverable. Attempting to resend without verification wastes send credits, harms sender reputation, and may increase the risk of being flagged by feedback loops.

What to do instead

Let’s say the user is a high-value customer or leads to your product. Instead of hammering their stalled inbox, reach them on a different channel—email, phone, or a messaging app. Request they free up space or confirm they still want your communications.

Once you get confirmation, verify the address again using a real-time validation API before re-adding them. This step is critical. An address that returned 550 5.2.2 may now be inactive, deleted, or reconfigured. Only validate the live state—not the past.

Tools like the real-time email verification API check for deliverability in seconds. It confirms the mailbox still exists, accepts new messages, and avoids re-triggering bounce chains. This keeps your list healthy and your inbox placement stable.

For bulk operations, use a bulk verification tool to preemptively clean lists before sending. Most major email providers, including AWS, enforce mailbox quotas and limit retries. A single 550 5.2.2 can signal deeper issues—like an abandoned account or full spam filter—so treat it as a signal to pause and reassess, not a retry prompt.

When in doubt, check the recipient’s domain policies and SMTP documentation. Some providers, like Microsoft 365, publicly document mailbox size limits and auto-rejection thresholds. Microsoft’s official docs explain how quota enforcement works in detail.

How to keep your deliverability steady when you can't fix the recipient's quota

Bounces due to over quota (550 5.2.2) are inevitable when recipients hit their storage limits. You can’t control their inbox size, but you can reduce how often you send to addresses that are already outdated or inactive.

Every valid email you send counts. The fewer stale addresses in your list, the fewer bounce-related hits on your sender reputation. A clean list means fewer blocked or delayed messages, even when third-party constraints apply.

Proactive steps to maintain steady deliverability

  • Run regular verification on your list to remove outdated or inactive emails before sending.
  • Test your messages with inbox-placement tools to preview how they land on major providers like Gmail and Outlook.
  • Integrate Email List Validation with SendGrid, HubSpot, Klaviyo, or other platforms to catch invalid addresses early in the funnel.

Keep reading

Ready to put this into practice? Email List Validation verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does 550 5.2.2 over quota mean the email address is invalid?

No—not invalid, just unreachable due to a full mailbox. The address exists but cannot receive mail.

Can Amazon SES automatically retry a 550 5.2.2 bounce?

No. This is a permanent failure code. SES does not retry. The message is discarded.

How do I know if a 550 5.2.2 bounce is from a real user or a fake address?

Only active email addresses can reach full quota. Use email verification to distinguish valid addresses that are full from permanently invalid ones.

What’s the difference between 550 5.2.2 and 554 mailbox full?

The codes are functionally identical. Some providers use 550 5.2.2; others use 554. Both mean the mailbox is at capacity.

Can role addresses cause 550 5.2.2 bounces?

Yes—mailboxes like info@ or sales@ can overflow due to high volume. These addresses are often poorly managed and more likely to hit quota limits.

Does Email List Validation detect over-quota bounces before sending?

Yes—via real-time SMTP checks, we verify mailbox status, including storage capacity, before delivery.

How do I clean my list to prevent 550 5.2.2 issues?

Use Email List Validation to remove invalid, role, disposable, and stale addresses. Prioritize list hygiene over sending volume.

Can a high bounce rate from 550 5.2.2 lead to a blocklist?

Yes—repeated hard bounces, even for quota issues, can trigger throttling or suspension in Amazon SES and affect your reputation.

Is there a way to test if a mailbox is full without sending?

Yes—Email List Validation uses live SMTP transactions to check mailbox availability, including storage limits, without delivering content.

How often should I verify my email list?

Verify before every major send. Use the real-time API for onboarding and bulk verification for quarterly cleanups.