Blog

Email Bounce Codes Explained: Hard Bounce vs Soft Bounce (550, 421, 452)

A hard bounce means permanent delivery failure — the address is gone, blocked, or never existed. A soft bounce means temporary failure — try again later. Both come back as SMTP status codes: 5.x.x for permanent, 4.x.x for temporary. This guide explains every major email bounce code, what each one means, how platforms like Amazon SES and Mimecast classify them, and exactly what to do when you see them.

---

What Is an Email Bounce?

An email bounce is a failure notification returned by a receiving mail server during or after the SMTP delivery handshake. When delivery can't be completed, the remote server sends back a structured response containing:

• A 3-digit SMTP status code — e.g., 550, 421, 452
• An enhanced status code — a dotted extension like 5.1.1 or 4.7.0 that narrows the failure category
• A human-readable diagnostic message — e.g., "User unknown" or "Message temporarily deferred"

Bounces can originate from mailbox providers (Gmail, Outlook, Yahoo), corporate mail servers, or security gateways such as Barracuda, Mimecast, or Proofpoint. The underlying classification framework is the same across all of them: the first digit of the status code tells you whether the failure is permanent or temporary.

Understanding bounce codes is not just technical housekeeping. According to Amazon SES's sender reputation guidance, high bounce rates are one of the primary signals that can cause a sending account to be paused or shut down. The same logic applies across all major ESPs and mailbox providers.

---

Hard Bounces vs Soft Bounces — The Core Distinction

Every email bounce falls into one of two categories. Getting this distinction right determines how your list management system should respond.

Is SMTP Authentication Failure a Hard Bounce or Soft Bounce?

SMTP authentication failures are typically hard bounces (permanent failures) when they result from SPF, DKIM, or DMARC policy violations. The specific code determines the classification:

• 550 5.7.1 — Hard bounce. SMTP authentication failed and the receiving server has a policy to reject (not defer) unauthenticated mail from your domain.
• 550 5.7.26 — Hard bounce. DMARC failure with a reject policy. The domain's DMARC record tells receiving servers to permanently reject unauthenticated messages.
• 451 4.7.1 — Soft bounce. Temporary authentication-related deferral, often seen with greylisting or temporary policy holds.

Key distinction: A 5xx authentication failure means "we checked your credentials and you're permanently blocked." A 4xx authentication failure means "we're temporarily holding this while we verify."

To prevent authentication-related bounces, verify your domain's SPF, DKIM, and DMARC records are correctly configured using the GroupPost email health checker before sending.

A hard bounce is a permanent, unrecoverable delivery failure. The receiving mail server is telling you definitively: this message cannot and will not be delivered.

Common causes:

• The email address doesn't exist (user unknown)
• The recipient mailbox has been disabled, deleted, or abandoned
• The recipient's domain doesn't exist or has no valid MX records
• The receiving server has permanently blocked your sending identity by policy
• SPF, DKIM, or DMARC authentication failure on a strict-reject policy

Hard-bouncing addresses must be suppressed immediately. Every subsequent send to a known hard-bounce address signals to mailbox providers that your list quality is poor — accelerating reputation damage and increasing the likelihood that your future messages, even to valid addresses, land in spam.

Soft Bounces (Temporary Failures)

A soft bounce is a temporary failure. Delivery didn't succeed this time, but the address may be valid and the condition may resolve on its own.

Common causes:

• Mailbox full or over storage quota
• Receiving server temporarily unavailable or overloaded
• Greylisting — the server defers first-contact messages as a spam screen
• Rate limiting or reputation throttling — the provider is slowing your inbound volume
• Message too large for the recipient's server configuration

Soft bounces don't always indicate a problem with the address itself. Many are recipient-side conditions that resolve without any action on your part. That said, persistent soft bounces — the same address failing 3, 4, 5 times in a row — often signal an address that is effectively inactive, even if it hasn't generated a hard bounce yet.

---

Hard Bounce Codes (5xx) — Complete Reference

The following are the most common hard bounce codes you'll encounter across Gmail, Outlook, Yahoo, and corporate mail environments. All are represented by SMTP 5xx status codes, indicating permanent failure.

550 — Permanent Rejection (Most Common Hard Bounce)

550 is the most frequently seen hard bounce code. The receiving server has rejected the message permanently. The enhanced sub-code narrows the reason:

Understanding 550 5.7.1 — The Most Common Authentication Bounce

550 5.7.1 is one of the most frequently encountered hard bounces for senders with authentication issues. The full error message typically reads:

550 5.7.1 Delivery not authorized, message refused

or

550 5.7.1 Message rejected due to local policy

This code means the receiving mail server checked your message's authentication (SPF, DKIM, DMARC) and found it failed to meet their acceptance policy. Common root causes:

• SPF failure: Your sending IP is not authorized in your domain's SPF record
• DKIM failure: Message signature missing or invalid
• DMARC reject policy: Your domain publishes p=reject and authentication failed
• Blocklist: Your sending IP or domain appears on the recipient's blocklist
• Content policy: Message content violated the receiving organization's policy rules

How to fix 550 5.7.1 bounces: Run the GroupPost domain health checker to verify SPF, DKIM, and DMARC records are correctly published and aligned. If authentication is correct but 550 5.7.1 persists for a specific domain, contact that domain's mail administrator — the block is at their policy level, not your sending infrastructure.

551, 552, 553, 554 — Other Permanent Failures

What Does "550 — Hard Bounce Deferred" Mean?

You may occasionally see error descriptions that pair a hard bounce code with language like "deferred." This is not a contradiction — it reflects a two-phase process some platforms use:

1. The receiving server initially returns a 5xx code, indicating permanent failure.
2. Your sending system (or ESP) defers the final suppression action briefly while it verifies whether the bounce is genuine or a transient misclassification.
3. After the deferral window expires without a successful retry, the address is confirmed as a hard bounce and suppressed.

In practice: if the underlying SMTP code is 5xx, the message will never be delivered. The "deferred" label describes your platform's internal queue management, not the ultimate delivery outcome. Treat it as a hard bounce.

---

Soft Bounce Codes (4xx) — Complete Reference

4xx codes are temporary failures. The receiving server is asking your mail system to try again later. Most sending platforms retry automatically with exponential backoff over 24–72 hours.

421 — Service Temporarily Unavailable / Rate Limited

421 is the most important soft bounce code for high-volume senders. It almost always means the receiving server is actively limiting or throttling your inbound traffic.

450 / 451 — Mailbox or Server Temporarily Unavailable

452 — Insufficient Resources

"Denied by Policy" — Hard or Soft Bounce?

You may see bounce descriptions reading "denied by policy" paired with either a 4xx or 5xx code. The code is what matters:

• 550 5.7.1 — denied by policy: hard bounce. The receiving server has a standing rule refusing your mail — often due to SPF/DKIM/DMARC failure or domain reputation. Investigate authentication and blocklist status via the GroupPost email health checker.
• 451 4.7.1 — denied by policy: soft bounce. The server is applying a temporary policy hold — common with greylisting, rate throttling, or reputation holds that lift over time.

---

How Amazon SES Classifies Email Bounces

When you use Amazon Simple Email Service (SES) as your sending infrastructure, bounce notifications are normalized into a structured JSON event delivered via Amazon SNS, EventBridge, or a webhook. SES provides both the raw SMTP codes from the receiving mail server and its own higher-level classification.

As documented in Amazon SES's notification contents reference, every bounce event includes a bounceType and bounceSubType:

SES Bounce Types

SES Bounce Subtypes

Important SES reputation note: According to Amazon's SES enforcement FAQ, SES will place a sending account under review when its bounce rate exceeds 5%, and may pause sending if it exceeds 10%. The recommended operational target is to keep hard bounces below 2% at all times.

---

Mimecast Bounce Classification

Mimecast is one of the most widely deployed email security gateways in enterprise environments. When your outbound email passes through Mimecast — either your own organization's Mimecast gateway, or your recipient's — the bounce messages and classifications you receive may differ from raw SMTP codes.

Mimecast processes bounces at multiple layers and surfaces them with its own terminology in the Mimecast Administration Console and message tracking interface.

What Does "Bounce - Rejected by Reviewer" Mean?

Bounce - Rejected by Reviewer is one of the most common Mimecast bounce classifications. This specific error message appears when:

Hard Bounce — Bounce - Rejected by Reviewer

This Mimecast-specific hard bounce means your email was delivered to the recipient organization's Mimecast email security gateway, queued for content inspection, and then permanently rejected by either an automated policy rule or a human security reviewer.

Why Does "Rejected by Reviewer" Happen in Mimecast?

Common reasons for "Rejected by Reviewer" in Mimecast:

• Message matched a content policy (blocked file type, suspicious URL, keyword match)
• Sender domain or IP appeared on Mimecast's threat intelligence feeds
• Message failed Mimecast's impersonation protection checks
• The recipient's organization has a policy that requires manual approval for messages from your domain

Mimecast Bounce Types Reference

If you're consistently seeing "Rejected by Reviewer" bounces for a specific recipient organization, the path forward is to contact that organization's IT or mail administrator — not to change your list or ESP. The block is at their gateway, not at the mailbox level.

---

Mailchimp and ESP-Specific Bounce Classifications

Email service providers (ESPs) like Mailchimp, Constant Contact, Campaign Monitor, and others add their own classification layer on top of raw SMTP codes. The most commonly searched is Mailchimp.

Mailchimp: "Hard Bounce — MC Returned No SMTP Detail"

This specific Mailchimp bounce classification means:

Hard Bounce — MC Returned No SMTP Detail

Mailchimp received a bounce response from the remote mail server, but the server's response did not include a usable SMTP status code or diagnostic message. Rather than leave the bounce unclassified, Mailchimp defaults these to hard bounce as a conservative protective measure.

Possible underlying causes:

• The receiving mail server returned a non-standard or malformed SMTP response
• The connection was dropped before a full SMTP status could be transmitted
• A security gateway (like Mimecast or Proofpoint) intercepted and terminated the SMTP session without returning a standard code
• The recipient domain's MX server is poorly configured

Because Mailchimp classifies these conservatively as hard bounces, the affected address will typically be suppressed from future sends. You can review individual bounced addresses in Mailchimp's audience activity log and manually re-subscribe addresses you believe were incorrectly suppressed — but do so judiciously.

Common ESP Bounce Code Terminology

---

Email Bounce Rate Benchmarks

Knowing your own bounce rate is only useful in context. Here are the thresholds that matter:

Thresholds sourced from Amazon SES enforcement FAQ, Mailchimp compliance documentation, and SendGrid email deliverability best practices guides.

---

How Many Soft Bounces Before You Suppress an Address?

Hard bounces are simple: suppress immediately, no exceptions.

What Does "Suppress Bounces from This Recipient" Mean?

Suppressing a bounced address means adding it to a permanent or temporary exclusion list that prevents future send attempts. When an ESP or sending platform says "suppress bounces from this recipient," it means:

• The address will be automatically skipped in all future campaigns
• No send attempt will be made (protecting your sender reputation)
• The address remains in your contact database but is marked as "suppressed" or "do not send"
• You can manually unsuppress addresses if you believe they were incorrectly classified

Why suppression matters: Every time you send to a known hard-bounce address, mailbox providers see it as a signal that your list quality is poor. Repeated sends to invalid addresses accelerate reputation damage and increase the likelihood that your future messages — even to valid addresses — land in spam or get blocked entirely.

Hard bounce suppression: Permanent and immediate. Once an address hard bounces with a 5xx code, it should never receive another message from your sending domain.

Soft bounce suppression: Conditional. After 3–5 consecutive soft bounces without a successful delivery, the address is added to the suppression list. If the address later becomes reachable (e.g., user clears their mailbox), you can manually unsuppress it.

Soft bounces require more nuance. The operational question is: at what point does a repeatedly soft-bouncing address become effectively undeliverable?

The most widely used rule across major ESPs and deliverability best practices is:

• Hard bounce: suppress after 1 occurrence
• Soft bounce: suppress after 3–5 consecutive soft bounces to the same address

"Consecutive" is the important word. A single soft bounce followed by successful delivery means the address is valid and the condition was genuinely temporary. An address that soft-bounces 5 sends in a row almost certainly reflects a mailbox that is permanently full, deactivated, or behind a gateway that won't accept your mail.

Some additional suppression considerations:

• Time window: some platforms reset the soft-bounce counter if a successful delivery occurs within a defined window (30–90 days). This is good practice — it doesn't penalize addresses that genuinely had a temporary issue long ago.
• Bounce type matters: a 452 4.2.2 (mailbox full) might deserve more retries than a 421 4.7.28 (reputation throttle from Gmail), which is often a signal to slow down your entire sending pace rather than suppress the address.
• Greylisted addresses: 450 4.7.1 greylisting typically resolves on the first retry after a few minutes. Don't count greylisting retries toward your soft-bounce threshold.

---

Why Bounce Handling Matters for Email Deliverability

Proper bounce handling is one of the clearest signals you send to mailbox providers that you are a legitimate sender who respects recipients' inboxes:

• You stop sending to addresses that are proven invalid — reducing wasted traffic and noise.
• You avoid hammering servers that are temporarily overloaded or throttling you.
• You can distinguish between a reputation-related soft bounce (requiring action on your sending patterns) and a simple mailbox-full condition (requiring only patience).
• You maintain a cleaner list, which improves open and click rates — engagement signals that directly improve inbox placement over time.

Google's Gmail Bulk Sender Guidelines explicitly call out high bounce rates as a reason messages are routed to spam or rejected entirely. Microsoft's Outlook.com Policies, Practices, and Guidelines similarly cite unmanaged bounce rates as a signal used by SmartScreen filtering.

The compounding effect is significant: a sender with a clean list and low bounce rates earns gradually expanding inbox placement. A sender who ignores bounces faces the opposite — throttling compounds, more messages land in spam, and eventually domain and IP reputation becomes difficult to recover.

Frequently Asked Questions About Email Bounce Codes