Hard Bounce Demystified: RFC 5321 Permanent 5xx Failures & In-Band Suppression Runbooks

Anatomy of an RFC 5321 Hard Bounce

A Hard Bounce represents a permanent, unrecoverable delivery failure emitted by a receiving Mail Transfer Agent (MTA). When a destination mail server returns a 5xx response code during an active SMTP session, it explicitly instructs the sending client that under no circumstances will the message ever be accepted for the requested recipient.

Hard bounces occur for definitive reasons: the target mailbox does not exist (550 User Unknown), the recipient domain has no valid MX records, or the receiving server has permanently blacklisted the sending IP address or domain.

C: MAIL FROM:<bounces@app.autosmtp.io>
S: 250 2.1.0 Sender OK
C: RCPT TO:<invalid.user.9982@example.com>
S: 550 5.1.1 <invalid.user.9982@example.com>: Recipient address rejected: User unknown in virtual mailbox table
# Destination MTA terminates transaction immediately with permanent failure.

RFC 3463 Enhanced Status Codes (5.X.X)

Standard 3-digit SMTP reply codes (such as 550, 553, 554) are too generic for programmatic routing. In 1996, RFC 1893 (superseded by RFC 3463) introduced Enhanced Mail System Status Codes in the format class.subject.detail. Permanent hard bounce codes always begin with the class digit 5:

In-Band Socket Interception vs Out-of-Band DSNs

High-performance email architectures distinguish between two distinct forms of hard bounce receipt:

• In-Band Rejection (Synchronous): The destination MX rejects the message directly across the active TCP socket during the RCPT TO or end-of-DATA phase. The sending MTA captures the exact 550 error code in real time without queuing.
• Out-of-Band Bounce (Asynchronous DSN): The destination MX accepts the message with a 250 2.0.0 OK, attempts internal downstream delivery, encounters an error, and generates a standalone RFC 3464 Delivery Status Notification sent back to the envelope Return-Path.

Automated Suppression Database Architecture

Retransmitting messages to known hard bounces is the single fastest way to destroy sender reputation. Mailbox providers (such as Google and Microsoft) monitor hard bounce ratios closely; exceeding a 2% hard bounce rate flags an infrastructure cluster as utilizing dirty, unverified contact lists or dictionary attack scrapers.

PowerMTA & KumoMTA Hard Bounce Configs

Modern enterprise MTAs feature native, high-speed bounce processors that parse in-band socket responses and automatically invoke webhooks to update suppression stores:

# Enable native accounting and bounce categorization

    move-to /var/log/pmta/archive/
    records b,d,v
    record-fields b *,bounceCat,dsnStatus,dsnDiag


# Pipe real-time hard bounces directly into Node.js / PHP ingest worker

    records b
    record-fields b timeLogged,orig,rcpt,dsnStatus,dsnDiag,bounceCat
    pipe /usr/local/bin/php /home/autosmtp/appsmtp/bin/bounce_worker.php