Email Bounce Codes Explained: What Hard and Soft Bounces Mean

Overview

The practical goal of this article is simple: help you read email bounce codes with less guesswork. If you send newsletters, transactional email, support notifications, or internal alerts, a bounce is not just an error message. It is feedback from the receiving system about what happened to your message at a specific point in the delivery path.

At a high level, bounce messages fall into two broad categories:

• Hard bounce: a permanent failure. The address may not exist, the domain may be invalid, or the receiving system may reject the message in a way that is unlikely to change without direct intervention.
• Soft bounce: a temporary failure. The mailbox may be full, the receiving server may be unavailable, or the message may have hit a temporary policy limit. These are often worth retrying for a limited period.

That distinction is useful, but it is not enough on its own. In practice, you also need to know why the message failed. A temporary DNS issue, a blocked IP, a bad recipient, and a content-based rejection can all look like "delivery failed" in a nontechnical interface. The right response is different in each case.

Most bounce notices include an SMTP reply code or enhanced status code. These usually follow a recognizable pattern:

• 2xx: success
• 4xx: temporary failure, often treated as a soft bounce
• 5xx: permanent failure, often treated as a hard bounce

You may also see enhanced codes such as 4.1.1 or 5.7.1. These add more detail. The first digit still tells you whether the condition is success, persistent temporary failure, or permanent failure. The remaining digits help narrow the category, such as addressing problems, mailbox status, mail system status, routing, or security policy.

One important caution: different providers phrase bounce reasons differently, and some systems classify edge cases in their own way. A "mailbox unavailable" message may mean an invalid recipient at one provider and a policy-based temporary rejection at another. Treat the status code and the human-readable explanation together, not separately.

If you are troubleshooting broader email delivery issues, it also helps to review your sending foundation. A weak authentication setup, poor IP reputation, or incomplete DNS records can create bounces that look unrelated at first glance. For a domain-level checklist, see Custom Domain Email Setup Checklist: DNS, MX, SPF, DKIM, and DMARC.

How to compare options

When people compare bounce messages, they often compare wording. A better approach is to compare them by operational impact. The useful question is not "Which message sounds worse?" but "What should I do next?"

A reliable comparison framework has five parts.

1. Compare by permanence

Start with whether the failure is likely permanent or temporary.

• If the code begins with 5, assume the issue is permanent unless there is strong evidence otherwise.
• If the code begins with 4, assume the issue may clear on retry, but do not retry forever.

This is the core of the hard bounce vs soft bounce distinction. It shapes suppression rules, alerting, and list hygiene.

2. Compare by layer of failure

Then identify where the problem occurred:

• Recipient layer: invalid address, disabled mailbox, unknown user
• Domain or routing layer: DNS issue, no valid mail exchanger, routing failure
• Mailbox capacity layer: full mailbox, quota exceeded
• Server availability layer: timeout, receiving server down, connection failure
• Policy or security layer: blocked sender, failed authentication, content rejection, reputation issue

This matters because a recipient-layer failure usually calls for suppression, while a routing or policy failure may require infrastructure fixes.

3. Compare by whether the sender can act

Some bounces can be fixed by the sender; others can only be fixed by the recipient or their provider.

• Sender-actionable: SPF or DKIM misalignment, bad reverse DNS, sending too fast, malformed message, broken MAIL FROM configuration
• Recipient-actionable: full inbox, deprovisioned user, local policy at the destination
• Shared responsibility: content filtering, volume spikes, reputation complaints

This helps prevent unproductive loops where support teams keep retrying messages that need a DNS or authentication correction instead.

4. Compare by retry strategy

Not every soft bounce deserves the same retry pattern. A temporary network timeout may clear quickly. A repeated 4.7.x policy throttle may need slower sending, not more attempts.

As a practical rule:

• Retry temporary transport and availability issues for a limited window.
• Slow down or batch retries for throttling and rate-limit responses.
• Suppress or quarantine addresses that repeatedly cycle through temporary failures over multiple campaigns or sends.

If you are building automation around this logic, a workflow article such as Building automation for email workflows: APIs, webhooks and integration patterns for developers can help frame retry and suppression decisions.

5. Compare by business consequence

Finally, compare bounces by what they mean for your communication workflow.

• A hard bounce in a product signup flow may indicate a bad address or typo that should trigger user correction.
• A soft bounce in a password reset flow may justify a brief retry with secondary notification options.
• A policy rejection for a bulk campaign may signal a deliverability problem that needs immediate monitoring before reputation deteriorates.

In other words, the same SMTP error code can have different operational priority depending on whether the email is transactional, security-related, internal, or promotional.

Feature-by-feature breakdown

This section is the reference part of the guide. Use it to map common email bounce codes and SMTP error codes to likely meanings and next steps.

Unknown user or invalid recipient

Typical patterns: 5.1.1, 550 user unknown, recipient address rejected

What it usually means: The mailbox does not exist, the address is misspelled, or the account was removed.

How to classify it: Usually a hard bounce.

What to do: Suppress the address quickly. Check for common typo patterns if the address was manually entered. If the address belongs to a customer or employee, verify whether the mailbox was renamed or deprovisioned.

Mailbox unavailable

Typical patterns: 5.2.1, 550 mailbox unavailable

What it usually means: The mailbox exists but cannot receive mail, or the provider uses this language for a broader recipient-side issue.

How to classify it: Often hard, but provider context matters.

What to do: Review the explanatory text. If this repeats consistently, suppress. If it appears during a known migration or service outage, treat it more cautiously.

Mailbox full or quota exceeded

Typical patterns: 4.2.2, 5.2.2, over quota

What it usually means: The recipient mailbox has exceeded storage limits.

How to classify it: Often soft at first. Repeated long-term failures may effectively become permanent for your workflow.

What to do: Retry for a short window. If the same address continues to bounce this way over time, downgrade confidence in future delivery and consider suppression for noncritical mail.

Domain not found or no valid MX

Typical patterns: 5.1.2, 5.4.x, domain does not exist, no MX records

What it usually means: The domain part of the recipient address is invalid, expired, mistyped, or missing valid mail routing records.

How to classify it: Usually hard.

What to do: Check for typo domains. If the domain should be valid, inspect DNS. This is especially relevant during business email setup, domain migration, or cutover work. For server-side context, see IMAP, POP3, and SMTP Settings for Major Email Providers for related mail server settings concepts.

Temporary server failure

Typical patterns: 421, 450, 451, 4.3.x, service not available, local error in processing

What it usually means: The receiving server is temporarily unavailable, under load, or unable to process the message.

How to classify it: Soft bounce.

What to do: Retry with backoff. Monitor for patterns by provider or destination domain. If the same issue persists across many recipients at one destination, the problem may be on their side rather than yours.

Rate limiting or throttling

Typical patterns: 4.7.0, too many connections, try again later, rate limit exceeded

What it usually means: The receiving system is limiting the volume or speed of mail from your infrastructure.

How to classify it: Soft bounce, but operationally important.

What to do: Reduce concurrency, pace delivery, segment large sends, and monitor reputation. Repeated throttling can be an early sign that your traffic profile or sender reputation needs attention.

Authentication failure

Typical patterns: 5.7.1, SPF fail, DKIM fail, DMARC reject

What it usually means: The receiving system did not trust the message because sender authentication failed or alignment did not meet local policy.

How to classify it: Usually hard for the affected message, though fixable in your setup.

What to do: Check SPF includes, DKIM signing, DMARC policy, envelope sender alignment, and any forwarding path that may affect authentication. This is one of the most actionable classes of bounce for admins and developers. A good companion read is Webmail Security Checklist for Small Businesses and IT Teams.

Blocked sender or reputation-based rejection

Typical patterns: 5.7.1, message refused, access denied, IP blocked

What it usually means: The destination sees risk in the sender IP, domain, content, or complaint pattern.

How to classify it: Usually hard for the current send attempt, though the underlying issue may be reversible.

What to do: Pause large sends if the pattern is widespread. Review complaint sources, bounce spikes, authentication, list hygiene, and recent sending changes. Also assess whether your content resembles phishing or scam patterns; that can trigger defensive filtering. Related reading: How to Spot a Phishing Email: Red Flags, Examples, and Reporting Steps.

Message too large

Typical patterns: 5.3.4, message size exceeds fixed maximum message size

What it usually means: The message or attachments exceed receiving limits.

How to classify it: Usually hard for that specific message.

What to do: Reduce attachment size, switch to file links, or compress content. For automated systems, enforce attachment size limits before send.

Content rejected or policy violation

Typical patterns: 5.6.x, 5.7.x, content refused, policy rejection

What it usually means: The content, structure, links, or message formatting triggered a destination policy.

How to classify it: Often hard for the current version of the message.

What to do: Review templates, URLs, headers, MIME structure, and tracking links. Test a simplified message. Compare accepted and rejected versions to isolate changes.

What the first digit usually tells you

• 4.x.x: temporary issue, retry carefully
• 5.x.x: permanent issue, investigate and usually suppress or fix before resending

What the middle category often suggests

• x.1.x: addressing or destination status
• x.2.x: mailbox status
• x.3.x: mail system status
• x.4.x: network or routing status
• x.5.x: protocol or mail delivery status
• x.6.x: content or media issues
• x.7.x: security or policy status

This pattern is useful for quick triage even when a provider-specific bounce message is verbose or inconsistent.

Best fit by scenario

The right way to handle email bounce meanings depends on the kind of system you run. Here is a practical comparison by use case.

For marketers and lifecycle teams

Your main concern is list quality and sender reputation. Hard bounces should usually be removed quickly. Soft bounces should be watched for repeated failures, especially across campaigns. Policy and reputation rejections deserve escalation because they can affect larger segments of your sending program.

Best approach: aggressive suppression for invalid recipients, measured retry for temporary failures, and clear monitoring by domain and campaign.

For SaaS platforms sending transactional email

Your concern is whether critical product mail reaches the user. Password resets, verification links, and billing notices need more careful retry logic than bulk notifications.

Best approach: classify by message criticality, retry temporary failures with backoff, and surface invalid-recipient errors back to the application when appropriate.

For IT admins managing business mail

Your concern is often broader than one send. You may be diagnosing tenant misconfiguration, DNS breakage, relay policy, or user provisioning issues.

Best approach: combine SMTP bounce analysis with account lifecycle checks, DNS validation, authentication review, and mail flow tracing. If users are also reporting access issues, a troubleshooting path such as How to Fix Webmail Login Problems: A Step-by-Step Troubleshooting Guide may help separate login problems from delivery problems.

For developers building mail workflows

Your concern is normalization. Different providers emit different language for similar failures, so your system needs a durable internal taxonomy.

Best approach: map raw responses into categories such as invalid recipient, temporary server issue, throttling, authentication failure, content rejection, and unknown. Store the original bounce text, but automate decisions from normalized classes.

For teams evaluating email or webmail platforms

Your concern is operational visibility. Some systems expose raw SMTP diagnostics; others hide them behind simplified labels. If you are comparing tools, bounce reporting quality is an important feature, not a minor admin detail.

Best approach: compare platforms by visibility into SMTP error codes, webhook payload detail, suppression management, retry control, and auditability. If you are at the platform-selection stage, you may also want to review Business Email Hosting Comparison: Webmail Features, Security, and Pricing and Comparing webmail clients for enterprise use: criteria for choosing the right interface.

When to revisit

The useful outcome of understanding SMTP error codes is not memorization. It is better decisions over time. Revisit your bounce-handling rules whenever your environment changes.

You should review this topic again when:

• You switch email providers, SMTP relays, or webmail platforms
• You change DNS, authentication, or routing policies
• You launch a new sending domain or subdomain
• You add higher-volume campaigns or new transactional flows
• You notice spikes in mail delivery failure rates, complaints, or provider-specific rejections
• You adopt new suppression, retry, or webhook automation logic

A practical maintenance routine looks like this:

1. Build a bounce taxonomy. Keep a short internal list of normalized categories and map provider-specific responses into them.
2. Separate temporary from permanent failures. Make sure your systems do not keep retrying invalid recipients.
3. Track by destination domain. Patterns at one provider often reveal throttling, policy, or routing issues faster than account-level review.
4. Store raw diagnostics. Even if your dashboard shows simplified labels, retain the raw SMTP response for debugging.
5. Audit authentication after any mail setup change. If you update DNS, relays, or vendor integrations, confirm SPF, DKIM, and DMARC still align.
6. Review support playbooks. Make sure customer-facing and IT-facing teams know which errors require retries, corrections, or escalation.

If your organization also supports end users who access email through webmail, keep your operational docs connected. Delivery failures, login issues, and client configuration problems often get reported together even when the root causes are different. Helpful references include Webmail Login Pages for Popular Email Providers: Official URLs and Access Help and Securing webmail login: MFA, SSO, and session management best practices.

The simplest long-term rule is this: treat bounce messages as structured operational signals. Compare them by permanence, cause, and next action. That gives you a repeatable way to handle hard bounce vs soft bounce questions, reduce avoidable retries, and fix the mail delivery failure issues that actually belong to your infrastructure.