A hard bounce is an email that the receiving mail server rejects permanently, with no prospect that resending the same message to the same address will succeed. The usual cause is that the mailbox does not exist: a typo at signup, an employee who left, a consumer account the provider closed. The term exists because sending systems need a binary instruction. Some failures are worth retrying for days; others are worth acting on at once, because each further attempt tells mailbox providers the sender is not maintaining its list. Hard bounce is the label for the second category, and in almost every commercial sending platform it triggers automatic and often irreversible suppression.

The classification starts inside the Simple Mail Transfer Protocol (SMTP), which moves mail between servers. The sending server names each recipient with an RCPT TO command, and the receiving server answers with a three-digit reply code. Codes beginning with 4 signal a temporary problem and invite a retry. Codes beginning with 5 signal a permanent one. RFC 5321, the current SMTP specification published in October 2008, is explicit that a reply starting with 5 means the command failed and that resending the message unchanged produces the same result.

Three digits carry little diagnostic weight. RFC 3463 noted that SMTP offers roughly a dozen codes useful for delivery reports, each overloaded with several distinct meanings, and defined a second layer to sit alongside them: enhanced status codes in a class.subject.detail form. A real rejection therefore reads as something like 550 5.1.1, where 550 is the SMTP reply and 5.1.1 is the enhanced code.

The detail is where the marketing consequence lives. RFC 3463 defines X.1.1 as a bad destination mailbox address, meaning the portion left of the @ sign does not exist, and states that the code is useful only for permanent failures. X.1.2 covers a destination system that does not exist or cannot accept mail, the failure mode of a misspelled domain. X.1.3 covers syntactically invalid addresses. X.1.6 covers a mailbox that was once valid but no longer accepts mail. Mailbox status codes sit in the X.2 range, where 5.2.1 signals a disabled mailbox and the pairing of 4.2.2 and 5.2.2 shows the same condition, a full mailbox, expressed as temporary in one case and permanent in the other.

Two structures carry these codes back. A rejection at RCPT TO happens inside the live SMTP session, and the sending platform records it directly. When a server accepts a message and only later finds it cannot deliver, it generates a delivery status notification, the bounce message format defined in RFC 3464, carrying Status and Diagnostic-Code fields. Asynchronous bounces of that kind arrive minutes or hours later, which is why bounce figures keep moving after a campaign closes.

Neither hard bounce nor soft bounce appears in any RFC. Both are vendor vocabulary layered on top of the codes, and the mapping differs by platform.

Amazon Simple Email Service sorts every bounce into three values in its notification payload: Permanent, Transient or Undetermined. Permanent is the hard bounce. Subtypes narrow it further, with NoEmail for an address that does not exist, General for an unspecified permanent rejection and Suppressed for an address Amazon already knows bounces. That last case is unusual. Amazon accepts the message, declines to send it, returns a Permanent bounce carrying a 5.1.1 status, and counts the event against both the bounce rate and the daily quota. The global suppression list behind it cannot be queried; the bounce notification is the only signal an address is on it.

Klaviyo suppresses a profile after a single hard bounce, or after seven consecutive soft bounces within two years, and deliverability suppressions cannot be reversed by the account holder. It also flags addresses that have hard bounced anywhere on its infrastructure as suspicious and skips them, so one advertiser's data quality problem propagates into another's send.

Mailchimp moves hard-bounced addresses to a status it calls cleaned, which receives neither campaigns nor transactional messages and which a contact can escape only by opting in again through a signup form. Its soft bounce ceiling is graduated: seven for an address with no subscriber activity, up to fifteen for a contact with prior activity, before the record converts to a hard bounce.

Adobe's Marketo Engage splits the category in two. One class of hard bounce sets an Email Suspended flag and pauses sending for 24 hours; the other sets Email Invalid and stops sending permanently, clearable only by a manual edit. Adobe Campaign quarantines undeliverable hard bounces and notes that a hard bounce may be ignored where the cause is unknown.

Bounce thresholds are enforced by sending platforms rather than by mailbox providers. Amazon publishes the strictest numbers in common use: a bounce rate at or above 5% places an account under review, and 10% or above can pause sending. The rate runs on a representative volume of recent sending rather than a fixed window, so a single large send to an unverified file can move it. The parallel complaint thresholds are 0.1% recommended and 0.5% for a pause.

Google sets no published bounce ceiling. Its sender guidelines, mandatory since 1 February 2024 for domains sending more than 5,000 messages a day to personal Gmail accounts, are built around authentication, one-click unsubscribe and a spam rate reported in Postmaster Tools that must stay below 0.30% and ideally below 0.10%. The link to bounces is indirect but real: hard bounces proxy for list quality, and list quality drives the complaint rate that is measured. Validity, which operates the Sender Score reputation system, treats hard bounce rates above 0.3% to 0.5% as a signal of inaccurate data.

The permanent-versus-temporary distinction is as old as internet mail. RFC 821, published in August 1982, established the 4xx and 5xx reply classes. The machine-readable apparatus arrived in January 1996, when the IETF published four related specifications: RFC 1891 for the delivery status notification extension, RFC 1892 for the multipart report content type, RFC 1893 for enhanced status codes and RFC 1894 for the notification message format. Those four were replaced in January 2003 by RFC 3461 through RFC 3464. RFC 5248 later moved the enhanced code list into an extensible registry, and RFC 5321 restated SMTP itself in 2008.

Hard bounce and soft bounce entered the vocabulary from the commercial sending industry that grew alongside those documents, as a customer-facing shorthand for the retry decision the queues were already making. The absence of a standard definition is why two platforms fed identical bounce messages can reach opposite conclusions.

The most persistent problem is false positives. A message blocked for policy or content reasons frequently returns 5.7.1, delivery not authorized, which is permanent in the protocol sense but says nothing about whether the address exists. Platforms that treat every 5xx as a hard bounce suppress live subscribers on the basis of a spam filter's opinion. Marketo's documentation warns directly that spam filters sometimes create hard bounces and that these false positives do not indicate an invalid address. Mailchimp maintains a help article on valid addresses that hard bounce.

The reverse error also occurs. Domains configured to accept mail for any local part answer RCPT TO positively and reject later, or discard silently, defeating both bounce-based hygiene and pre-send verification.

Recycled spam traps complicate the picture further. Mailbox providers deactivate abandoned accounts and return hard bounces to anyone still sending, then reactivate a subset as traps that accept mail silently. Estimates of the interval diverge sharply: Validity has described a gravestoning period of 30 to 90 days before reactivation while elsewhere putting the inactivity window at roughly 9 to 18 months, and Adobe's documentation states an address can become recycled within 30 days. The mechanism is not disputed. The hard bounce is the warning, and a sender that ignores it eventually stops receiving one.

Irreversibility is the third dispute. Suppression the account holder cannot undo protects the shared sending reputation of everyone on the same infrastructure, but it also removes any route to correcting a bounce caused by a DNS error rather than a dead address.

Soft bounce. A temporary failure returned with a 4xx code and retried, commonly for up to 72 hours. Repeated soft bounces convert to hard bounces at thresholds each vendor sets.

Bounce rate in web analytics. An unrelated metric describing single-page sessions on a website. The word is shared; nothing else is.

Spam complaint. A recipient action, recorded through feedback loops, reporting a delivered message as unwanted. Complaints and bounces are separate metrics with separate thresholds.

Suppression list. The destination rather than the event. A hard bounce is one of several reasons an address lands there, alongside unsubscribes, complaints and manual removals.

Enforcement of the Gmail sender requirements escalated during late 2025, as non-compliant traffic moved from temporary 4.7.x deferrals toward permanent 5.7.x rejections and the legacy Postmaster Tools dashboard gave way to a pass or fail compliance view. That shift turns an authentication misconfiguration into a hard bounce on every message, a different failure mode from a stale list and a different fix.

Address supply is also contracting. Google updated its inactive account policy in May 2023, with Ruth Kricheli, vice president of product management, stating that personal accounts unused for at least two years could be deleted from December 2023 onward. Deleted Gmail addresses hard bounce.

Bounce handling has meanwhile become programmable infrastructure. Iterable streams platform events including emailBounce to external systems as JSON, making the bounce webhook the point where suppression, customer records and paid audience uploads are meant to stay in sync.

• August 1982: RFC 821 defines SMTP and the 4xx and 5xx reply code classes
• January 1996: RFC 1891, 1892, 1893 and 1894 introduce delivery status notifications and enhanced mail system status codes
• January 2003: RFC 3461 through RFC 3464 obsolete the 1996 documents; RFC 3463 defines 5.1.1 as bad destination mailbox address, useful only for permanent failures
• June 2008: RFC 5248 establishes an extensible IANA registry for enhanced status codes
• October 2008: RFC 5321 replaces RFC 821 as the SMTP specification
• May 2023: Google announces a two-year inactivity policy for personal Google accounts
• 1 December 2023: earliest date on which Google begins deleting inactive accounts
• 1 February 2024: Gmail and Yahoo sender requirements take effect for senders of more than 5,000 messages a day to personal accounts
• May 2025: Microsoft applies comparable authentication requirements to high-volume senders on its consumer domains
• October 2025: Google retires the legacy Postmaster Tools dashboard in favour of a pass or fail compliance view
• November 2025: Gmail enforcement moves from temporary deferrals toward permanent SMTP-level rejection

• BVDW's email marketing guide tackles AI agents and a 376-billion daily inbox sets out the German industry association's measurement framework, including an open rate formula whose denominator is recipients minus bounces.
• Explaining Klaviyo covers the B2C platform whose profile and event model governs how a bounce becomes a suppressed record.
• Explaining Braze describes the cross-channel engagement category and prices deliverability support as a separate contract line.
• Explaining Iterable documents the system webhooks, including emailBounce, that carry delivery events out of the platform.

Who. Receiving mail servers issue hard bounces. Email service providers, marketing automation platforms and transactional sending services classify and act on them. Advertisers, lifecycle marketers and deliverability specialists carry the consequences.

What. A permanent delivery failure, signalled by a 5xx SMTP reply and an enhanced status code such as 5.1.1, that triggers automatic and usually irreversible suppression of the recipient address.

When. The underlying reply codes date to 1982 and the machine-readable status codes to 1996, revised in 2003. Enforcement pressure intensified from February 2024, when Gmail and Yahoo sender requirements took effect, and again from late 2025 as rejection replaced deferral.

Where. In the SMTP transaction between sending and receiving servers, surfaced to marketers through campaign reports, suppression lists, reputation dashboards and bounce webhooks.

Why. Repeated sending to addresses that do not exist is one of the clearest signals mailbox providers have that a sender is not maintaining its list. Acting on the first permanent failure protects inbox placement for every other address on the file.