Articles

SMTP Bounce Handling: Process Hard and Soft Bounces (2026)

April 18, 2026 7 min read

SMTP bounce handling is more about managing expectations than it is about fixing broken pipes.

Let’s see what this looks like in practice. Imagine we’re sending an email to test@example.com.

2023-10-27 10:30:00.123 [12345] DEBUG: Connecting to smtp.example.com:25
2023-10-27 10:30:00.456 [12345] INFO: EHLO client.mydomain.com
2023-10-27 10:30:00.789 [12345] INFO: MAIL FROM:<sender@mydomain.com>
2023-10-27 10:30:01.112 [12345] INFO: RCPT TO:<test@example.com>
2023-10-27 10:30:01.445 [12345] DEBUG: Sending data
2023-10-27 10:30:01.778 [12345] INFO: DATA
2023-10-27 10:30:02.111 [12345] INFO: Subject: Test Email
2023-10-27 10:30:02.444 [12345] INFO: From: Sender <sender@mydomain.com>
2023-10-27 10:30:02.777 [12345] INFO: To: Test User <test@example.com>
2023-10-27 10:30:03.110 [12345] INFO: .
2023-10-27 10:30:03.443 [12345] DEBUG: Received response from server
2023-10-27 10:30:03.776 [12345] INFO: 250 2.0.0 Ok: queued as ABCDEF12345
2023-10-27 10:30:04.109 [12345] DEBUG: QUIT
2023-10-27 10:30:04.442 [12345] INFO: 221 2.0.0 Bye

This looks like a successful delivery. But what happens when it’s not? The SMTP protocol has built-in mechanisms for the receiving server to tell the sending server why an email couldn’t be delivered. These are the bounce messages.

There are two main types of bounces: hard and soft.

Hard Bounces

A hard bounce signifies a permanent delivery failure. The email address is invalid, the domain doesn’t exist, or the recipient’s mail server has permanently blocked mail from your server. These are the addresses you absolutely want to remove from your mailing lists.

Here’s what a hard bounce might look like in your mail server logs (or a bounce processing service):

From: MAILER-DAEMON@mail.recipient-domain.com
To: sender@mydomain.com
Subject: Failure Notice

This is an automatically generated Delivery Status Notification.

Delivery to the following recipient failed permanently:

    test@example.com
    Reason: 550 5.1.1 <test@example.com>: Recipient address rejected: User unknown in virtual mailbox table

The key here is the 550 5.1.1 code. This is a permanent rejection.

Common Causes and Fixes for Hard Bounces:

  1. Recipient Address Does Not Exist (550 5.1.1): This is the most common hard bounce. The user account test@example.com simply doesn’t exist on example.com.

    • Diagnosis: Look for 550 5.1.1 or similar "user unknown" error codes in your bounce notifications.
    • Fix: Immediately remove test@example.com from your active mailing lists. Your sending system should have a mechanism to automatically flag and suppress these addresses for future sends.
    • Why it works: By removing the invalid address, you prevent future attempts to send to a non-existent recipient, which would only result in more bounces and potentially damage your sender reputation.

  2. Unknown Domain (550 5.4.1 or 550 5.1.2): The domain example.com itself is not recognized or doesn’t have valid MX (Mail Exchanger) records.

    • Diagnosis: Search for 550 5.4.1 (no MX records) or 550 5.1.2 (host unknown) in bounce messages.
    • Fix: Verify the domain name for typos. If it’s a legitimate domain but you’re seeing this, it’s likely a DNS issue on the recipient’s side. You might flag this email address for a one-time retry, but if it persists, consider it a hard bounce.
    • Why it works: This addresses potential typos in the domain name or indicates a more fundamental problem with the recipient’s email infrastructure that makes delivery impossible.

  3. Mailbox Full (552 5.2.2): While often a temporary issue, some servers treat a consistently full mailbox as a permanent problem if it’s not cleared.

    • Diagnosis: Look for 552 5.2.2 or messages like "mailbox full."
    • Fix: If this happens repeatedly for the same recipient, treat it as a hard bounce and remove them. Otherwise, it might be a soft bounce.
    • Why it works: If a user’s mailbox is perpetually full, they are effectively unreachable, making the address functionally invalid for ongoing communication.

  4. Policy/Security Rejection (550 5.7.1): The recipient’s server has blocked your email due to anti-spam policies, blacklisting, or other security measures.

    • Diagnosis: Look for 550 5.7.1 and messages indicating "blocked," "rejected," or "policy violation."
    • Fix: Investigate why your IP or domain might be blocked. Check your IP against blacklists (e.g., using tools like MXToolbox). Ensure your sender authentication (SPF, DKIM, DMARC) is correctly configured. If you believe the block is an error, contact the recipient’s mail administrator. If it’s a persistent block you can’t resolve, treat the address as a hard bounce.
    • Why it works: This addresses issues that prevent your mail from ever reaching the intended inbox due to security or policy enforcement by the receiving mail server.

Soft Bounces

Soft bounces are temporary delivery failures. The recipient’s mailbox might be full, the server might be down, or the message might be too large. These addresses might be deliverable later.

Here’s an example of a soft bounce:

From: MAILER-DAEMON@mail.recipient-domain.com
To: sender@mydomain.com
Subject: Delivery Status Notification (Delayed)

This is an automatically generated Delivery Status Notification.

The following recipient(s) could not be reached:

    test@example.com
    Reason: 451 4.2.2 <test@example.com>: Recipient mailbox exceeded storage limit.
    Diagnostic-Code: smtp; 451 4.2.2 <test@example.com>: Recipient mailbox exceeded storage limit.

The key here is the 451 4.2.2 code. The 4xx series indicates a temporary failure.

Common Causes and Fixes for Soft Bounces:

  1. Mailbox Full (451 4.2.2): The recipient’s inbox has reached its storage capacity.

    • Diagnosis: Look for 451 4.2.2 or messages like "mailbox full," "quota exceeded."
    • Fix: Most modern sending systems will automatically retry sending soft bounces for a period (e.g., 24-72 hours) before giving up. If the bounce persists after multiple retries, then you should treat it as a hard bounce.
    • Why it works: By retrying, you give the recipient time to clear space in their inbox, allowing the email to be delivered successfully later.

  2. Server Temporarily Unavailable (451 4.4.2 or 451 4.7.1): The recipient’s mail server is temporarily offline, overloaded, or refusing connections.

    • Diagnosis: Look for 451 4.4.2 (connection timed out), 451 4.7.1 (temporary rejection), or messages indicating server issues.
    • Fix: Again, rely on your sending system’s retry mechanism. If the server remains unavailable for an extended period (e.g., more than 72 hours), you may need to investigate if it’s a persistent issue with that mail provider.
    • Why it works: Temporary network or server issues are common and usually resolve themselves. Retries ensure your email is delivered once the recipient’s mail infrastructure is back online.

  3. Message Too Large (552 5.3.4 or 452 4.3.1): The email, including attachments, exceeds the size limit set by the recipient’s server.

    • Diagnosis: Search for 552 5.3.4 or 452 4.3.1 and messages indicating "message too large."
    • Fix: If this is a consistent issue for a recipient, advise them to reduce the size of their attachments or inform them of your sending limits. If it’s a temporary block (4xx), retries might help if the recipient’s server temporarily increases its limit or if the sender resends a smaller version. If it’s a permanent block (5xx) for exceeding limits, the recipient’s address is effectively unusable for your message size.
    • Why it works: This addresses a mismatch in message size capabilities between sender and receiver, requiring either size adjustment or policy changes.

  4. Greylisting (451 4.7.1): A security measure where the receiving server temporarily rejects mail from an unknown sender IP, expecting the sending server to retry.

    • Diagnosis: Often shows up as a 451 4.7.1 with a message like "Please try again later" or "Service unavailable."
    • Fix: This is expected behavior for greylisting. Your sending system should retry. After a few successful retries, the receiving server will typically whitelist your sending IP for that recipient, and subsequent emails will be delivered immediately.
    • Why it works: Greylisting is a spam-fighting technique that capitalizes on the fact that legitimate mail servers will retry delivery, while many spam bots won’t. By retrying, you prove you’re a legitimate sender.

The next hurdle you’ll encounter is understanding how to aggregate and act on these bounce notifications at scale, rather than just processing them one by one.

Want structured learning?

Take the full Smtp course →