Email Bounce Backs Explained: Types, Causes, and Solutions

When an email cannot be delivered, the receiving server sends back a Non-Delivery Report (NDR), commonly called a bounce. Bounces contain SMTP status codes and diagnostic text that explain why delivery failed. Understanding bounce types, reading the error codes, and acting on the information is critical for maintaining sender reputation and list hygiene.

Hard Bounces vs. Soft Bounces

Hard Bounces (5xx Errors)

A hard bounce is a permanent delivery failure. The receiving server has determined that the message cannot be delivered now or in the future. Hard bounces use 5xx SMTP status codes.

Common hard bounce codes:

Action required: Remove hard-bounced addresses from your mailing list immediately. Continuing to send to invalid addresses damages your sender reputation. Gmail, Outlook, and Yahoo all track bounce rates as a key reputation signal.

Soft Bounces (4xx Errors)

A soft bounce is a temporary delivery failure. The receiving server could not accept the message right now but may accept it later. Soft bounces use 4xx SMTP status codes, and the sending server will typically retry delivery over a period of hours or days.

Common soft bounce codes:

Action required: Do not remove soft-bounced addresses immediately. Monitor them. If an address soft-bounces consistently across multiple campaigns (e.g., five consecutive attempts over several weeks), reclassify it as a hard bounce and remove it.

Anatomy of a Bounce Message (NDR)

A Non-Delivery Report is a structured email sent by the receiving or intermediate MTA back to the sender. It follows the format defined in RFC 3461 (DSN) and RFC 3464 (delivery status notification format). A typical NDR contains:

1. Human-readable explanation: A text description of what went wrong.
2. Delivery status fields: Machine-readable status codes including the Status field (e.g., 5.1.1), Diagnostic-Code, Remote-MTA, and Reporting-MTA.
3. Original message headers: The headers (and sometimes body) of the undeliverable message.

Example diagnostic line:

Diagnostic-Code: smtp; 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown

Common Causes of Bounces

Recipient Does Not Exist (550 5.1.1)

The most common hard bounce. The email address is misspelled, the account has been deleted, or it never existed. Typos during signup (gmial.com instead of gmail.com) are a frequent cause.

Mailbox Full (552 5.2.2 / 452 4.2.2)

The recipient's mailbox has exceeded its storage quota. Some providers treat this as a temporary error; others issue a permanent rejection after the mailbox has been full for an extended period.

Blocked by Policy (550 5.7.1)

The receiving server rejected the message due to a policy rule. This could be triggered by:

• Sender IP on a blocklist (DNSBL).
• Failed SPF, DKIM, or DMARC authentication.
• Content filtering (spam score too high).
• Recipient domain has a restrictive inbound policy.

Run your domain through the InboxTooling SPF Check and DKIM Verify to rule out authentication issues.

Greylisting (451 4.7.1)

Greylisting is an anti-spam technique where the receiving server temporarily rejects the first delivery attempt from an unknown sender. Legitimate mail servers will retry; most spam bots will not. The message usually delivers on the second or third attempt.

DNS Issues

If the recipient domain's MX records are misconfigured, missing, or unresolvable, the sending server cannot determine where to deliver the message. This results in a bounce. Check MX records for any domain using the InboxTooling MX Lookup.

Message Too Large

Some servers impose size limits on incoming messages. A message exceeding the limit (commonly 25 or 50 MB) will be rejected with a 552 error.

How Bounces Affect Sender Reputation

Mailbox providers track your bounce rate as a percentage of total messages sent. High bounce rates signal that you are sending to unverified or stale lists, which is a hallmark of spammers.

Industry guidelines:

• Keep your hard bounce rate below 2% of total sends.
• Gmail's postmaster guidelines recommend keeping bounce rates as low as possible and explicitly penalize senders with high rates.
• A sudden spike in bounces (e.g., after importing an old list) can trigger immediate throttling or blocking.

Reducing Your Bounce Rate

1. Use double opt-in. Require new subscribers to confirm their email address before adding them to your list.
2. Validate on entry. Check email syntax and MX record existence at the point of signup. The InboxTooling MX Lookup can verify a domain has valid mail servers.
3. Clean your list regularly. Remove hard bounces after every send. Sunset addresses that have not engaged in 6-12 months.
4. Authenticate your email. Proper SPF, DKIM, and DMARC configuration prevents policy-based rejections. Run a comprehensive check with the InboxTooling Full Report.
5. Monitor bounce reports. Parse NDRs programmatically (or use your ESP's bounce analytics) to categorize and act on bounces systematically.
6. Warm up new IPs and domains. Do not send full volume from a new IP or domain on day one. Gradually increase volume to build reputation.

Provider-Specific Behavior

• Gmail: Uses 550 5.1.1 for non-existent recipients. May temporarily reject with 421 when rate-limiting a sender.
• Outlook/Microsoft 365: Returns 550 5.7.1 for blocklist-related rejections. Provides a sender support form for delisting.
• Yahoo: Returns 553 5.3.0 for some reputation-based rejections. Monitors complaint rates closely via feedback loops.

Understanding what bounce codes mean and responding appropriately is one of the most effective ways to protect deliverability over the long term.

Stay on top of your email infrastructure. Sign up for the InboxTooling newsletter for deliverability tips, tool updates, and best practices.