Bounce Codes: SMTP Error Code Reference, Meanings & Fix Guide

When an email cannot be delivered, the receiving server does not just fail silently—it sends back a structured error message that explains exactly why delivery failed. That error message contains a bounce code: a three-digit SMTP status number and, in most cases, an extended sub-code that specifies the failure category and reason with enough precision to determine the correct response. Treating all bounces identically—removing every bounced address permanently—wastes valid contacts whose delivery failed for temporary reasons. Retrying every bounce—including permanent failures—accumulates negative sender reputation signals that degrade inbox placement for every future send. Reading bounce codes correctly and responding to each code type with the right automated action is the operational skill that separates email programs that maintain high deliverability over time from programs that gradually lose inbox access.

How SMTP Bounce Codes Are Structured: The Three-Digit System

Every SMTP bounce code follows the same structure defined in RFC 5321, the core specification governing email transmission. The code has three digits. The first digit classifies the response type: 2 means success, 4 means temporary failure, and 5 means permanent failure. The second digit classifies the subject area: 0 is a general or undefined category, 1 relates to addressing, 2 relates to the mailbox, 3 relates to the mail system, 4 relates to the network, and 5 relates to the mail delivery protocol. The third digit provides specific detail within the category established by the second digit.

For bounce handling purposes, the first digit is the most critical classification. A code beginning with 4 (a 4xx code) signals a temporary failure—the receiving server is saying it cannot accept the message right now, but the problem may resolve. The sending system should queue the message and retry after a delay, typically 15 minutes to 24 hours, depending on the specific sub-code. A code beginning with 5 (a 5xx code) signals a permanent failure—the receiving server is saying it will never accept this message. The sending system should suppress the address immediately and not retry.

Most modern mail servers supplement the three-digit code with an enhanced status code in the format X.Y.Z (defined in RFC 3463), which provides more specific failure information than the basic three-digit code alone. For example, a server returning “550 5.1.1” is providing both the SMTP code (550, permanent rejection) and the enhanced code (5.1.1, bad destination mailbox address—meaning the specific email address does not exist on that domain). The Salesforce email bounce reason glossary entry covers how Salesforce captures and surfaces these codes in the Email Bounce Reason field on Contact and Lead records.

Permanent Bounce Codes (5xx): Addresses to Suppress Immediately

5xx codes indicate permanent failures that require immediate address suppression. Retrying a 5xx bounce wastes sending resources, accumulates negative reputation signals with inbox providers, and in some cases triggers rate limiting or blocklisting from servers that log repeated delivery attempts to invalid or rejected addresses.

550 is the most common permanent bounce code, indicating that the receiving server has rejected delivery because the recipient address does not exist, has been disabled, or the server policy refuses email from the sending domain. The accompanying enhanced code specifies which: 5.1.1 (bad destination mailbox—address does not exist), 5.1.2 (bad destination system—domain not found), 5.7.1 (delivery not authorized—message blocked by policy, often a reputation or spam filter rejection). All three require immediate suppression, but 5.7.1 additionally warrants investigation of sender reputation, authentication setup, and content flags that may have triggered the policy block.

551 indicates the user is not local, and the server does not support forwarding—the address was valid on a previous mail server that has since migrated or decommissioned. Suppress and attempt to source an updated email address through other channels.

552 indicates the message was rejected because the recipient’s mailbox storage limit was exceeded—but when returned as a 5xx code (rather than 4.2.2), it indicates a permanent over-quota condition rather than a temporary full-mailbox state. Suppress and treat as a hard bounce.

553 indicates the recipient address violates the receiving server’s syntax or policy rules—often a malformed address, a prohibited character, or a local-domain address being sent externally. Suppress and flag the record for data quality review. 554 indicates the transaction failed due to policy—typically a content or reputation-based rejection. Unlike 550 5.7.1, which signals a specific policy block, 554 is a broader catch-all that warrants investigation of both the specific address and the sending domain’s reputation. The Salesforce email bounce glossary entry covers how to build Salesforce suppression workflows that automatically set HasEmailBounced and HasOptedOutOfEmail when 5xx codes are received.

Temporary Bounce Codes (4xx): Addresses to Retry, Not Suppress

4xx codes indicate temporary failures where the delivery problem may resolve without any change to the address or the sending configuration. The key operational principle is that 4xx codes should trigger a retry queue, not a suppression action—removing an address after a 4xx bounce discards a potentially valid contact who experienced a temporary server condition.

421 indicates the receiving service is temporarily unavailable—the server exists, the domain is valid, but the mail service is not accepting connections at this moment. Retry after 15–60 minutes. This code frequently appears during scheduled maintenance windows or unexpected server overload events at the receiving domain.

450 indicates the requested mailbox action was not taken because the mailbox is temporarily unavailable—the address exists, but the server is experiencing a transient condition. Retry after one to four hours. This is distinct from 452, which indicates insufficient storage on the receiving server at a system level rather than a mailbox-specific condition.

4.2.2 (typically returned as “452 4.2.2”) is the most common temporary bounce code for legitimate active addresses: mailbox full. The recipient’s email storage quota is currently exceeded. This is a soft bounce that resolves when the recipient clears inbox space. Standard practice is to retry for up to 72 hours before treating a sustained 4.2.2 as a potential permanent problem worth flagging for review.

4.4.1 indicates a connection timeout—the sending server could not establish a connection to the receiving server within the timeout window. This typically indicates a network routing issue, a firewall rule, or a temporary DNS propagation problem rather than an address-level failure. Retry after one hour; escalate to infrastructure review if the timeout persists across multiple retry attempts for a specific domain.

The critical risk with 4xx codes is treating all temporary bounces as permanent when bounce reporting lacks code-level granularity. An email platform that reports only “bounce count” without distinguishing 4xx from 5xx codes causes list hygiene errors in both directions: keeping invalid addresses (mistaking 5xx for 4xx) and removing valid addresses (mistaking 4xx for 5xx). MassMailer captures specific bounce codes and writes them to Salesforce records, enabling Flow Builder automations that apply the correct handling logic for each code class.

Provider-Specific Bounce Codes: Gmail, Outlook, and Yahoo Extensions

Major inbox providers supplement standard SMTP codes with provider-specific diagnostic strings that contain additional context not captured in the numeric code alone. Reading these strings correctly accelerates diagnosis and determines whether a bounce is an address-level problem, a reputation problem, or a content problem.

Gmail returns bounce messages that include both the standard SMTP code and a descriptive reason string. A Gmail 550 with the string “The email account that you tried to reach does not exist” is a clean address-not-found hard bounce requiring suppression. A Gmail 550 with “Our system has detected that this message is likely suspicious” is a reputation-based rejection requiring sender reputation investigation, not address suppression—the address is valid, but Gmail has blocked delivery due to a signal about the sending domain or the message content. Google’s Postmaster Tools provides domain-level reputation and deliverability data that contextualizes Gmail-specific bounce patterns across large sending volumes.

Microsoft Outlook and Exchange return bounce codes using the “X-Microsoft-Status” diagnostic header alongside standard SMTP codes. The Microsoft-specific code 550 5.4.1 indicates the recipient address has been rejected by the receiving domain’s policy—often meaning the address exists in Active Directory, but external email delivery has been blocked by an admin rule. This is distinct from 550 5.1.1 (address does not exist) and should be treated as a soft block pending investigation rather than an immediate permanent suppression. Microsoft’s SMTP error reference provides the complete catalog of Exchange Online non-delivery report codes and their recommended resolutions.

Yahoo and AOL return bounce codes that often include rate-limiting messages alongside address-level failures. A Yahoo 421 with the string “[TS01] Messages from your IP address have been temporarily blocked” is a reputation-based rate limit—not an address failure—and requires sending volume reduction and sender reputation review rather than any address suppression action. The Salesforce email deliverability glossary entry covers how to investigate and resolve provider-specific rate-limiting blocks that surface as 4xx bounce codes.

Automating Bounce Code Handling Inside Salesforce

Manual bounce code review—reading individual bounce messages and deciding what to do with each address—does not scale beyond a few dozen bounces per send. A Salesforce database running high-volume email sequences can generate hundreds of bounce events per campaign; automated handling that applies the correct suppression or retry logic based on bounce code class is the operational requirement for maintaining list health at that volume.

The foundational automation is a Record-Triggered Flow on the Contact and Lead objects that fires when the HasEmailBounced field changes to True. For 5xx hard bounces, the Flow sets HasOptedOutOfEmail to True, removes the contact from all active campaign memberships, and creates a data review task. For 4xx soft bounces, the Flow sets a custom field—Soft_Bounce_Count__c—and increments it on each retry event. When Soft_Bounce_Count__c exceeds three within a 72-hour window, the Flow treats the condition as a potential hard bounce and applies the same suppression logic as a 5xx code, pending manual data review. The Salesforce email automation glossary entry covers Record-Triggered Flow configuration for bounce-triggered suppression workflows.

MassMailer writes the specific bounce code—both the three-digit SMTP code and the extended status code—directly to the Salesforce Email Bounce Reason field, enabling Flow Builder decision elements that branch on code class (4xx versus 5xx) and on specific codes (5.7.1 reputation blocks routed to a separate investigation queue, distinct from 5.1.1 invalid address suppressions). This code-level granularity prevents the two most common bounce handling errors: retrying permanent failures and suppressing temporary ones. The OCP Capital podcast covers how a financial services organization automated bounce handling inside Salesforce to maintain clean contact data across high-volume sending without manual list management overhead.

Bounce Code Thresholds: When Rates Signal a Deliverability Problem

Individual bounce codes diagnose individual delivery failures. Bounce rate metrics across a sending program diagnose systemic deliverability problems. Knowing both dimensions—what each code means and what aggregate rates signal—provides a complete picture of list health and sending infrastructure integrity.

A hard bounce rate (5xx codes) above 2% on any campaign send triggers inbox provider spam routing adjustments. Gmail and Outlook both use aggregate bounce rate data from their feedback loops to adjust delivery routing for sending domains; a domain that consistently produces hard bounce rates above 2% is classified as a poor list manager and receives progressively more aggressive spam folder routing. Target hard bounce rate is below 0.5% per campaign.

A sustained pattern of 5.7.1 (policy rejection) codes across multiple domains—rather than individual address-level failures—indicates a sender reputation problem rather than a list quality problem. If 5.7.1 codes are appearing for addresses at Gmail, Outlook, and Yahoo simultaneously in the same campaign, the issue is the sending domain’s reputation or the message content triggering spam filters—not the validity of the addresses. The Salesforce email analytics glossary entry covers how to build Salesforce reports that segment bounce events by code class to distinguish list quality problems from reputation problems.

A high rate of 4.2.2 (mailbox full) codes concentrated in a specific import batch or lead source indicates either a stale purchased list (addresses that haven’t been used in years tend to accumulate over-quota conditions) or a honeypot list (where addresses were never actively used). Investigating the source of 4.2.2 concentrations often reveals data quality problems at the list acquisition level that pre-send validation can prevent going forward. The Salesforce email verification glossary entry covers how verification flags addresses likely to produce soft bounce patterns before they enter the sending queue.

Stop Guessing Which Bounces to Fix—Get Full SMTP Code Visibility and Automated Suppression Inside Salesforce

MassMailer captures the specific SMTP bounce code for every delivery failure—hard and soft—writes it to the Salesforce Email Bounce Reason field, and enables Flow Builder automations that apply the correct handling logic for each code type automatically. Schedule a call to see how bounce handling works in your Salesforce org.

Key Takeaways

• SMTP bounce codes are three-digit structured error codes returned by receiving servers when email cannot be delivered. The first digit is the critical classifier: 4xx codes signal temporary failures requiring a retry; 5xx codes signal permanent failures requiring immediate address suppression.
• The most important 5xx codes are 550 5.1.1 (address does not exist—suppress immediately), 550 5.7.1 (policy or reputation block—investigate sender reputation, do not just suppress), and 554 (transaction failed—investigate both address and sending domain). Treating 5.7.1 as an address problem when it is a reputation problem misdiagnoses the failure and leaves the root cause unresolved.
• 4xx codes require retry, not suppression. 421 (service unavailable), 450/452 (mailbox temporarily unavailable), 4.2.2 (mailbox full), and 4.4.1 (connection timeout) all indicate conditions that may resolve without any change to the address. Removing contacts after 4xx bounces discards valid addresses and degrades list quality in the wrong direction.
• Major providers add diagnostic strings to standard SMTP codes that specify whether a 550 rejection is an address failure (5.1.1), a reputation block (Gmail spam detection), or a policy rule (Microsoft 5.4.1). Reading the full bounce message—not just the numeric code—determines whether the correct response is address suppression, reputation investigation, or content review.
• Automated Salesforce bounce handling requires code-level granularity: a Flow that increments a Soft_Bounce_Count__c field for 4xx codes and applies hard suppression only after three retries within 72 hours; a separate branch that routes 5.7.1 codes to a reputation investigation queue rather than a standard address suppression workflow.
• A hard bounce rate above 2% per campaign triggers spam routing by Gmail and Outlook. A pattern of 5.7.1 codes across multiple providers signals a sender reputation problem, not a list problem. A concentration of 4.2.2 codes in a specific import batch signals stale or purchased list data. Each pattern points to a different root cause requiring a different fix.