SMTP Bounce Codes: How to Read and Act on Failed Email

Overview

SMTP bounce codes are the compact failure messages returned when a receiving mail server rejects or delays delivery. The code tells you whether the problem is temporary, permanent, recipient-specific, content-related, or reputation-related. The operator mistake is treating every bounce as either "bad address" or "try again later"; the useful workflow is to classify the code, preserve the diagnostic text, and trigger the right follow-up automatically.

Read the code in three layers

Start with the first digit of the SMTP reply. A 2xx response is success, a 4xx response is a transient failure that may succeed later, and a 5xx response is a permanent failure for that attempt. RFC 5321 defines the SMTP reply model, while RFC 3463 adds enhanced status codes in the `class.subject.detail` format, such as `4.2.2` for a temporarily full mailbox or `5.1.1` for a bad destination mailbox.

Then read the enhanced status subject when it is present. `X.1.X` usually points at addressing or mailbox problems, `X.2.X` at mailbox state, `X.3.X` at mail system status, `X.4.X` at network or routing, `X.5.X` at protocol or command problems, and `X.7.X` at security, policy, or reputation issues. Finally, keep the human diagnostic string because receivers often include the most actionable detail there: blocklist names, policy URLs, authentication failures, or rate-limit hints.

• Use the first digit for temporary vs permanent classification
• Use enhanced status codes for subject-level diagnosis
• Store the raw diagnostic text; it often contains the fix
• Separate recipient failures from domain-wide reputation or policy failures

Turn bounce codes into an action map

A good bounce workflow makes the next step deterministic. Recipient-not-found failures should move the address into suppression immediately. Temporary 4xx failures should stay in a retry queue with exponential backoff and a maximum age. Mailbox-full failures deserve a short retry window, not permanent suppression on the first event. Reputation and policy blocks should create an incident signal because retrying the same content to the same provider can deepen the problem.

Do not let the provider's broad category be the only record. Normalize into your own fields: class, enhanced code, provider, recipient domain, provider message ID, campaign or transactional template, raw diagnostic, final decision, and who reviewed any manual override. That lets you answer whether a spike came from one imported list, one Gmail policy block, one broken DKIM setup, or one template that triggered filtering.

• Permanent recipient failures belong in suppression
• Temporary failures belong in a bounded retry queue
• Policy and reputation failures belong in incident review
• Provider-domain clustering matters more than one-off messages

1. Parse the SMTP reply and enhanced status code when the provider exposes it.
2. Classify the failure as recipient, mailbox, content, authentication, reputation, network, or provider-limit related.
3. Choose the default action: suppress, retry, pause segment, pause provider/domain, or escalate for review.
4. Record the raw diagnostic text and the normalized decision on the send event.
5. Aggregate failures by recipient domain and campaign before resuming volume.

Operator checklist for common SMTP failures

Use this checklist when bounce codes start appearing in webhooks or delivery logs. The order matters: protect recipients and reputation first, then debug the provider-specific detail. If you suppress good recipients during a reputation incident, you lose reachable users; if you keep mailing bad addresses during a hard-bounce spike, you damage the domain for everyone else.

For transactional email, avoid blanket pauses unless product-critical mail is clearly being rejected across a provider. For marketing campaigns, it is safer to pause the affected segment or campaign while you inspect authentication, list source, content changes, and complaint signals.

• Pause the smallest affected scope, not every mailstream by default
• Compare failures by provider domain, template, segment, and sending domain
• Keep transactional and marketing incidents separate where possible
• Resume gradually after the root cause is fixed

Where Mailbase fits in bounce-code operations

Mailbase is relevant when SMTP failures need to become operational workflow instead of invisible provider logs. Delivery and bounce events can feed analytics, suppression/compliance controls, send-job review, and reply context so a teammate can see whether a campaign is healthy before continuing volume.

For teams using a BYO useSend stack, the same discipline still applies: keep the sending layer responsible for delivery events, and let the workflow layer make those events visible next to campaigns, segments, templates, and replies. The point is not to guess deliverability from a single chart; it is to turn raw failures into retry, suppression, and incident decisions.

• Use suppression for hard recipient failures
• Use send-job review for retryable or provider-specific failures
• Use analytics by provider to spot clustered blocks
• Keep diagnostics attached to the campaign or transactional send that caused them

Common Mistakes

• Skipping SPF, DKIM, and DMARC, or assuming they're a one-time setup.
• Sending real volume from a brand-new, un-warmed domain.
• Reusing a stale list without re-verifying, so bounces spike.
• Ignoring complaint rate until a single bad campaign sinks the domain.

Sources & Further Reading

Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.

Related guides

More on smtp bounce codes and the surrounding deliverability workflow:

FAQ

Related reading