Email Bounces: SMTP Codes, Causes, and How to Fix Them

Email bounces are not a single failure type. They are a set of signals from receiving mail systems that tell you whether a message was rejected permanently, delayed temporarily, blocked for policy reasons, or unable to reach its destination.

For developers, the practical goal is not merely to count email bounces. It is to preserve the original SMTP response, classify the failure conservatively, stop repeatedly mailing known-bad recipients, and investigate patterns that point to DNS, authentication, reputation, content, or application-data problems.

What an email bounce is

An email bounce occurs when a message cannot be delivered as intended and the sending infrastructure receives a failure response or a delivery status notification. The failure may happen immediately while the sender is talking SMTP to the recipient server, or later after another mail server has accepted the message and attempted onward delivery.

In the common case, your application submits a message through an email provider's REST API or SMTP relay. The provider queues it, selects a destination mail exchanger from the recipient domain's MX records, then opens an SMTP connection to that destination. The receiving system can accept the message, defer it for later retry, or reject it.

A simplified SMTP conversation looks like this:

S: 220 mx.recipient.example ESMTP
C: EHLO mail.sender.example
S: 250-mx.recipient.example
C: MAIL FROM:<bounces@bounce.example.com>
S: 250 2.1.0 OK
C: RCPT TO:<person@recipient.example>
S: 550 5.1.1 <person@recipient.example>: Recipient address rejected: User unknown

That final response is a permanent recipient failure. A well-designed sending system should record the recipient, timestamp, provider message ID, SMTP reply, enhanced status code, destination domain, and any internal classification. It should then prevent future nonessential sends to that address.

A bounce does not automatically mean your sending platform is broken. A customer may have typed an address incorrectly, left a company, deleted a mailbox, filled their inbox, or been affected by a temporary outage. Conversely, a bounce can expose a configuration or reputation issue on the sender side. The difference is in the response code, wording, timing, and pattern across recipients.

The difference between rejection, deferral, and a delivery-status notification

The language around failures is often inconsistent between providers. Start with the underlying mail-flow event rather than relying only on dashboard labels such as “soft bounce” or “hard bounce.”

Immediate SMTP rejection

An immediate rejection happens while your sending service is attempting delivery. The remote server rejects a command, usually RCPT TO or the final message transfer after DATA.

Examples include:

550 5.1.1 User unknown
552 5.2.2 Mailbox full
554 5.7.1 Message rejected due to policy

The sender has a direct response from the receiving system. This is usually the highest-quality failure evidence because it identifies the recipient server's decision at the time of attempted delivery.

Temporary deferral

A deferral is a temporary failure. The remote server indicates that the sender should try again later, generally with a reply in the 4xx range.

421 4.7.0 Try again later
450 4.2.0 Mailbox temporarily unavailable
451 4.7.1 Temporary local problem

A reliable mail transfer agent queues the message and retries according to its delivery schedule. Your application should not immediately resubmit the same email after seeing a provider event classified as deferred; that can create duplicate delivery attempts and make a reputation or rate-limit problem worse.

A deferral becomes a final failure only when the sender's retry window expires or a subsequent attempt receives a permanent response. The exact retry policy differs by provider, so distinguish “still retrying” from “finally failed” in your event processing.

A delayed bounce or DSN

A receiving system may accept a message and later generate a Delivery Status Notification (DSN), often called a non-delivery report. This can occur when a message is relayed internally or onward to another system and fails after the first receiving server accepted it.

DSNs are useful evidence, but they are not always standardized or complete. Parse the machine-readable portions when available, including fields such as Final-Recipient, Action, Status, Diagnostic-Code, and Remote-MTA. Do not make suppression decisions from a human-readable subject line alone.

Why “soft” and “hard” are imperfect labels

“Soft bounce” generally means temporary and retryable; “hard bounce” generally means permanent and non-retryable. Those terms are useful shorthand, but they hide important detail. A 5.7.1 policy rejection is permanent for that message under current conditions, yet the underlying cause may be fixable by correcting authentication, changing content, or improving reputation.

Treat the actual SMTP and enhanced status codes as the source evidence. Use your own categories—such as invalid recipient, mailbox full, policy rejection, authentication failure, DNS failure, content issue, or provider throttling—to drive automation and investigation.

How to read SMTP reply codes and enhanced status codes

SMTP replies typically include a three-digit basic reply code, optionally followed by an enhanced status code such as 5.1.1. The SMTP specification defines the basic reply-code behavior, while enhanced status codes provide a more detailed, machine-readable diagnosis. (rfc-editor.org)

The first digit: success, temporary failure, or permanent failure

The first digit is the most important part of an SMTP reply for retry behavior:

• 2xx: successful action. For example, 250 2.0.0 OK means the receiving server accepted the message at that SMTP hop.
• 4xx: temporary failure. Queue and retry according to the sending provider's policy.
• 5xx: permanent failure for the current transaction. Do not keep retrying blindly.

A 250 acceptance is not a guarantee that the email appeared in the recipient's inbox. It confirms acceptance by the server at that point in the delivery path. The message may still be filtered to spam, quarantined, routed internally, or later fail downstream.

The enhanced code structure

Enhanced status codes use class.subject.detail format. In 5.1.1:

• 5 is the class: permanent failure.
• 1 is the subject: addressing or recipient status.
• 1 is the detail: bad destination mailbox address.

The IANA registry maintains the enhanced SMTP status-code assignments. (iana.org)

Common bounce codes developers should recognize

The literal text can vary by mailbox provider, but these examples are common and actionable:

Never map a response only from the first three digits. A 550 can mean user unknown, but it can also be used for policy and reputation blocks. The enhanced status code and remote server message often determine whether the issue belongs to one address, one domain, one campaign, or the whole sending program.

The main causes of email bounces

Most email bounces fit into a few recurring categories. Classifying by cause makes it easier to decide whether to suppress an address, retry a message, repair infrastructure, or change sending behavior.

Invalid or nonexistent recipients

Examples include typos, abandoned mailboxes, fake signups, role addresses that no longer exist, and employee addresses after a company departure. A typical signal is 550 5.1.1 with text such as “user unknown” or “no such mailbox.”

This is usually recipient-specific. Suppress the address promptly for marketing and product notifications that are not legally or operationally required. For critical account communication, consider showing an in-product prompt asking the user to update their email rather than silently continuing to send.

Invalid recipient domains and missing MX records

A recipient address can have valid-looking syntax while its domain cannot receive mail. A common failure might refer to DNS lookup failure, an invalid domain, no MX record, or an unreachable destination.

Check DNS directly:

# Show MX records for a recipient domain
dig MX recipient.example +short

# Show the A/AAAA records used if the domain falls back to its host address
dig A recipient.example +short
dig AAAA recipient.example +short

A domain may legally use its A or AAAA record when it has no MX record, so “no MX” alone does not prove it cannot receive mail. However, an MX record pointing to . explicitly declares that the domain accepts no email, and that should be treated as a permanent destination failure.

Full or disabled mailboxes

A mailbox can be temporarily full, administratively disabled, locked, or unavailable during a migration. These failures may appear as 4.2.2, 5.2.2, or provider-specific text.

Do not immediately label every storage-related code as a permanent invalid address. Retry behavior should follow the actual leading class: 4xx is temporary; 5xx is final for the attempt. If final mailbox-full errors persist across independent messages, suppressing the recipient may be reasonable for noncritical sends.

Authentication failures

Authentication problems frequently surface as 5.7.1 policy rejections. A recipient server may reject mail because SPF does not pass, DKIM signatures are missing or invalid, DMARC alignment fails, reverse DNS is absent, or the message does not meet the receiver's sender requirements.

Google's sender guidance requires all senders to Gmail to use SPF or DKIM, and requires high-volume senders to use SPF, DKIM, and DMARC, with additional infrastructure and spam-rate expectations. (support.google.com)

Authentication must be checked against the message that recipients actually see, not just against a DNS record you intended to publish. Send a test message to a mailbox you control, inspect Authentication-Results, and confirm that at least one aligned SPF or DKIM identifier supports your visible From: domain under DMARC.

Reputation, volume, and policy throttling

Mailbox providers use reputation and abuse controls to decide whether to accept, defer, filter, or reject messages. Sudden volume spikes, high complaint rates, poor engagement, a new sending domain, low-quality acquisition, and repeated messages to bouncing recipients can all contribute to rejection or deferral.

Policy-related failures often cluster by destination provider and begin around a specific deployment, campaign, list import, or sending-volume change. That pattern is more informative than any individual error string. A single 5.7.1 can be ambiguous; thousands of them at one mailbox provider after a DNS change are a strong infrastructure signal.

Message content and formatting problems

Malformed MIME, invalid headers, broken character encoding, oversized attachments, suspicious links, and misleading content can all trigger rejections. A failure may mention message content, malformed headers, spam policy, or RFC compliance.

The visible body is only one component. Review headers including From, Reply-To, Message-ID, Date, List-Unsubscribe, Content-Type, and multipart boundaries. Verify that links use domains you control and that the HTML has a useful plain-text alternative.

Sending-domain and network configuration issues

Common infrastructure causes include missing DKIM records, expired DNS changes, an incorrect SPF record, a misaligned return-path domain, TLS negotiation problems, a missing PTR record, or a sending host name that does not resolve correctly.

These failures rarely affect just one recipient. They tend to cluster across recipients, often at larger mailbox providers first. When that happens, pause broad noncritical sending until you can identify the shared cause.

DNS and authentication checks that prevent avoidable bounces

DNS cannot eliminate every email bounce, but correct DNS and authentication remove a large class of preventable policy failures. They also give receiving systems stable identifiers for evaluating your mail stream.

SPF: authorize the actual envelope sender

SPF is evaluated against the SMTP envelope sender, also called MAIL FROM or return-path—not necessarily the visible From: address. A basic SPF TXT record might look like this:

example.com. IN TXT "v=spf1 include:spf.email-provider.example -all"

The exact include: value must come from your email provider. Do not copy the placeholder above into production. If you send from more than one authorized system, include each authorized mechanism while staying within SPF's DNS-lookup limits.

A permissive record such as ~all can be useful during a migration, but it does not fix an incorrectly authorized sending source. After testing, publish the narrowest valid policy for your setup.

DKIM: publish the selector exactly as issued

DKIM signs portions of a message with a private key; recipients retrieve the public key through DNS. A record commonly resembles this:

s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA..."

Some providers use CNAME records for DKIM delegation instead:

s1._domainkey.example.com. IN CNAME s1.domainkey.provider.example.

Use the record type, host, and target or key supplied by the sending service. Do not combine a TXT DKIM record and a CNAME at the same hostname. DNS rules do not allow a CNAME to coexist with other records at its owner name.

DMARC: connect the visible From domain to authentication

DMARC evaluates whether SPF and/or DKIM pass with alignment to the domain in the visible From: header. Begin with a monitoring policy if you are still mapping all legitimate senders:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

The rua address receives aggregate reports. Strict alignment (adkim=s and aspf=s) can be valuable but requires that authenticated domains match the visible From domain exactly. Relaxed alignment is often easier during initial rollout. Move toward p=quarantine or p=reject only after confirming every legitimate service is authenticated and aligned.

Return-path and bounce-domain alignment

Many sending providers configure a custom return-path or bounce subdomain, such as bounce.example.com. This helps SPF align with the organizational domain of example.com and ensures delivery feedback can be processed.

A provider may ask you to create a CNAME similar to:

bounce.example.com. IN CNAME bounce.provider.example.

Again, use your provider's exact destination. The concept matters: the return-path is part of the envelope, carries bounces, and is relevant to SPF evaluation. It is not simply a cosmetic DNS entry. Bird's documentation describes this return-path role and its connection to bounce processing and SPF alignment. (bird.com)

Verify DNS from outside your DNS control panel

A DNS dashboard showing a saved record is not proof that public resolvers can see it correctly. Query it:

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT s1._domainkey.example.com +short
dig CNAME bounce.example.com +short

MXToolbox can help inspect MX, SPF, DKIM, DMARC, and blacklist-related signals. For a message-level test, mail-tester.com can highlight authentication, content, and formatting issues. Treat tool scores as prompts for investigation, not a substitute for actual delivery-event data from your own sending stream.

A practical bounce-handling architecture

Bounce handling belongs in application logic, not just in an email dashboard. Whether your provider sends event webhooks, exposes activity through an API, or reports failures through SMTP logs, build a durable pipeline around the events.

Capture an immutable delivery event

For every accepted submission and every downstream result, store enough data to connect the event to the originating action:

• Your application message ID and the provider message ID.
• Recipient address, normalized for lookup but retained in its original submitted form where appropriate.
• Event time and event type: accepted, delivered, deferred, bounced, complained, or suppressed.
• SMTP basic reply code, enhanced status code, and full remote diagnostic text.
• Destination domain and remote MTA when available.
• Message category, such as password reset, receipt, security alert, product notification, or marketing.
• The sending domain, return-path domain, DKIM selector, campaign or template version, and deployment version.

The full response is essential. Reducing every failure to a provider's generic “bounce” label makes future diagnosis much harder.

Make webhook processing idempotent

Delivery webhooks can be retried, arrive out of order, or be received more than once. Use a stable event ID when the provider supplies one. Otherwise, construct an idempotency key from a provider message identifier, event type, timestamp bucket, and recipient only if that combination is reliably unique.

Verify webhook signatures when offered, acknowledge quickly, and move expensive analysis to a queue. Do not call a third-party validation service synchronously inside the webhook handler. A slow dependency can cause your endpoint to time out and create duplicate delivery-event processing.

Separate recipient state from message state

A single message can fail without proving that a recipient should never be contacted again. Store both concepts:

message_delivery_status: deferred | delivered | bounced | expired
recipient_sendability: active | temporarily_paused | suppressed | opted_out

For example, a 421 4.7.0 should update the message delivery state but normally should not suppress the recipient. A clear 550 5.1.1 can update both the message state and recipient sendability.

Use conservative suppression rules

A sensible baseline policy might be:

1. Immediately suppress a recipient after a confirmed nonexistent-mailbox or invalid-address failure, such as a credible 5.1.1 or 5.1.3 response.
2. Do not suppress after a temporary 4xx response while the provider is still retrying.
3. Escalate repeated deferrals at the same destination domain as an operational alert, not as individual recipient failures.
4. Investigate 5.7.1 responses before suppressing every affected recipient, because the cause may be your authentication, content, IP, or sending domain.
5. Keep separate suppression scopes for marketing, transactional messages, and legally required communications, with clear review controls.

Never “solve” a spike in policy bounces by endlessly changing recipient addresses, rotating domains, or resubmitting the same email. Repair the underlying authentication, content, list-quality, or reputation issue.

Test bounce logic before production

Use a provider sandbox, a controlled test domain, or test recipients designed to generate delivery outcomes. Validate that your application can handle accepted, delivered, deferred, final-bounced, duplicate-webhook, and out-of-order events.

For REST API and SMTP relay implementations, review the provider's email API setup guides before testing: submission acceptance and eventual delivery are separate states. Your application should not mark an email “delivered” simply because its API request returned success or its SMTP relay accepted the message.

How to investigate a bounce spike

A bounce spike is an incident until proven otherwise, especially for transactional email. The fastest path to a diagnosis is segmentation: determine what changed and what the affected messages have in common.

Start with a time-bounded comparison

Compare the failing period with a healthy baseline. Look at bounce and deferral rate by hour, destination domain, sending domain, message category, template, deployment version, source IP or pool if available, and audience source.

Ask these questions:

• Did the spike begin immediately after a DNS, template, SDK, or infrastructure deployment?
• Is it concentrated at Gmail, Microsoft, Yahoo, one company domain, or every destination?
• Is the dominant code 5.1.1, 4.7.0, 5.7.1, or something else?
• Did a new import, signup flow, partner integration, or acquisition source change address quality?
• Did send volume increase sharply, or did a retry job accidentally resend old traffic?
• Are complaints, unsubscribes, or spam-folder reports increasing alongside bounces?

The answer directs the investigation. A spike in 5.1.1 after a form change suggests poor input validation or bot signups. A widespread 5.7.1 after a domain migration suggests authentication or policy failures. A domain-specific 4.7.0 spike often suggests throttling or reputation pressure.

Preserve samples, but protect personal data

Collect a representative sample of remote responses and message metadata. Avoid spreading raw recipient addresses and complete email bodies into broad-access incident channels. Hash or redact addresses when sharing diagnostics, while keeping a secure path to the original event for authorized investigators.

Check the message recipients received—or rejected

For a controlled mailbox at a major provider, inspect the full source of a delivered test. Confirm:

• The visible From: domain is the intended domain.
• Return-Path uses the expected envelope sender.
• SPF result is pass.
• DKIM result is pass with the intended signing domain.
• DMARC result is pass and aligned.
• The message has a valid date, message ID, MIME structure, and plain-text part.
• Links, images, and reply addresses use expected domains.

If tests pass while production traffic fails, compare the exact traffic paths. A staging domain, a different sending pool, a different API key, or a newly introduced template may be responsible.

Reducing bounce rates before sending

The best bounce workflow starts before a message is submitted. Prevention is less expensive than cleanup and protects sender reputation.

Validate address format at collection time

Basic validation should reject malformed addresses, but it should not overreach. Avoid simplistic regular expressions that reject legitimate internationalized or uncommon-but-valid addresses. At minimum, reject missing @ signs, spaces where they are not permitted, empty local parts, and clearly malformed domains.

A format-valid address is not necessarily deliverable. Combine syntax checks with confirmation flows, especially for newsletters, trials, waitlists, and accounts where an email address is central to access.

Use double opt-in for promotional lists

For marketing email, double opt-in reduces typo addresses, malicious signups, spam traps, and complaints. It also gives you evidence that the recipient controls the mailbox. Keep transactional account messages separate from promotional streams so a marketing-list issue does not disrupt password resets, receipts, or security notifications.

Verify high-risk addresses where it makes sense

Address verification can be useful for signup flows, imports, and expensive outbound campaigns, but it is not infallible. Many domains intentionally block SMTP probing, use catch-all mailboxes, or rate-limit verification attempts.

Use a free email verification tool as one input before sending, then rely on actual delivery outcomes to maintain suppression lists. Do not treat an “unknown” verification result as proof that an address is invalid.

Keep acquisition-source metadata

Record how and when an address entered your system: direct signup, invited user, checkout, sales import, support ticket, partner integration, or manual entry. When bounce rates rise, acquisition source is often the clearest way to isolate the problem.

For example, a clean organic signup channel may have a 0.3% invalid-recipient rate while an unconfirmed imported list produces 8%. Combining those populations hides the cause and can harm the reputation of the healthy stream.

Warm up changes instead of making abrupt jumps

New domains, newly configured sending infrastructure, and large audience changes deserve gradual rollout. Start with your most engaged or most recent recipients, monitor results by mailbox provider, and increase volume only when authentication, complaints, deferrals, and bounces remain stable.

The exact thresholds differ by sender type and recipient mix, so do not use a universal bounce-rate number as a pass/fail rule. A sudden rise from your own baseline is often more meaningful than an industry benchmark.

What not to do when email bounces occur

Some responses make delivery and reputation worse rather than better.

First, do not retry permanent 5xx failures from your application in a tight loop. Your provider may already have classified the result as final, and repeated submissions can generate duplicate events or increase abuse signals.

Second, do not delete the original diagnostic text. Provider categories are helpful, but remote server wording is often the only clue separating an invalid mailbox from an authentication block.

Third, do not remove a recipient solely because a single provider-side validation attempt says “unknown.” The correct response depends on whether a real delivery attempt later receives a permanent failure.

Fourth, do not treat “accepted” as “inbox delivered.” SMTP acceptance, delivery confirmation, inbox placement, opens, clicks, and conversions are different measurements.

Finally, do not use a broad campaign to test whether an authentication problem is fixed. Start with controlled seed mailboxes and small production slices. If the failure is a 5.7.1 policy problem, a large retry can amplify the damage.

Building an operational dashboard for bounces

A useful bounce dashboard is not just a single percentage. It should make failure patterns visible quickly enough to protect critical mail.

Track at least these metrics:

• Total attempted, accepted, delivered, deferred, bounced, and expired messages.
• Bounce rate and deferral rate by destination domain.
• Permanent invalid-recipient failures by acquisition source.
• 5.7.1 and other policy failures by sending domain, template, and deployment version.
• Time-to-final-outcome for deferred messages.
• Suppression additions and their reasons.
• Bounce rates separated by transactional and marketing categories.

Set alerts on significant deviation from your own baseline, not solely on a fixed global threshold. A password-reset stream that normally has near-zero permanent bounces may deserve an alert after a small absolute increase. A large marketing stream should be evaluated with volume, recipient age, list source, and destination-domain mix in mind.

When operating through a transactional provider's REST API or SMTP relay, make delivery events part of your normal observability stack. Correlate them with application deploys, DNS changes, background-job releases, template updates, and list imports. That correlation turns a generic “bounce increase” into an actionable engineering finding.

Conclusion

Email bounces are evidence, not merely failed messages. A 4xx response tells you to wait and observe retry behavior; a confirmed invalid-recipient 5xx response tells you to stop sending to that address; a cluster of 5.7.1 failures tells you to investigate authentication, reputation, content, or policy.

The durable approach is straightforward: preserve the full SMTP response, interpret enhanced status codes alongside diagnostic text, separate message state from recipient state, suppress clearly invalid addresses, retry only temporary failures through the provider's queue, and monitor patterns by destination and change history. With that foundation, bounces become one of the most useful feedback loops in your email infrastructure.

FAQ

What is the difference between a soft bounce and a hard bounce?

A soft bounce usually describes a temporary delivery problem, commonly represented by a 4xx SMTP reply, such as temporary unavailability or throttling. A hard bounce usually describes a permanent failure, commonly a 5xx reply such as 550 5.1.1 for a nonexistent mailbox. Use the actual response code and diagnostic text rather than relying only on those labels.

Should I remove every email address that bounces?

No. Suppress addresses after credible permanent recipient failures, especially invalid mailbox or invalid address responses. Do not suppress addresses for temporary deferrals, and investigate policy-related failures such as 5.7.1 before deciding the recipient is at fault.

Does a 250 SMTP response mean the message reached the inbox?

No. A 250 response means the receiving server accepted the message at that SMTP step. The message may still be filtered to spam, quarantined, routed internally, or fail later in the delivery chain.

Why do I get 5.7.1 bounce errors?

5.7.1 is a broad policy or security failure category. It can indicate missing or misaligned SPF, DKIM, or DMARC; poor sender reputation; content filtering; malformed messages; or recipient-side policy. Read the complete remote response and look for patterns by destination domain and sending configuration.

Can email verification prevent all bounces?

No. Verification can catch malformed domains and some undeliverable addresses, but it cannot reliably predict mailbox capacity, later account closures, recipient-server policy, reputation decisions, or all catch-all domains. Use verification as a preventive signal and actual delivery events as the final evidence.