Hard bounce, soft bounce: SMTP codes and removal rule

Gmail returns the same full mailbox under two opposite codes: a temporary 452 4.2.2, and a permanent 552 5.2.2 when the account is also inactive (Google Workspace documentation, checked in October 2026). The first is a soft bounce, the second a hard bounce, for one and the same full mailbox depending on whether it is active or inactive. A hard bounce is a permanent refusal: the message will not be delivered until the address or the message changes. A soft bounce is a temporary failure that your email service provider retries. The removal rule: delete the address at the first hard bounce and remove it at the 3rd consecutive soft bounce, across 3 sends spread over at least 14 days. The rest of this guide takes an NDR apart line by line and ties every numeric threshold to its source.

Hard bounce vs soft bounce: point-by-point comparison

The values in the “Retry” row come from RFC 5321 (sections 4.2.1 and 4.5.4.1). Each provider then sets its own give-up period, which you can find in its documentation.

Which SMTP codes separate a hard bounce from a soft bounce?

A 4xx code announces a temporary failure (soft bounce) and a 5xx code a permanent one (hard bounce): the first digit of the SMTP reply sets the class.

The detail sits in the enhanced status code, defined by RFC 3463 (January 2003). It has three fields separated by dots: class, subject, detail. The class is 2 (success), 4 (persistent transient failure) or 5 (permanent failure). The subject names the area at fault. A 1 points to the address, a 2 to the mailbox, a 3 to the mail system, a 4 to the network, a 5 to the protocol, a 6 to the content, a 7 to security and policy.

So 5.1.1 reads like this: permanent failure (5), address problem (1), invalid part before the @ sign (1). The RFC reserves this code for permanent failures. The full catalog of replies is in the guide to SMTP reply codes. The 550 5.4.1 and 552 cases are covered one by one in SMTP error codes.

Reading an NDR line by line: the 550 5.1.1 example

The NDR (non-delivery report) is a message in DSN format, described by RFC 3464, sent back to the sender. The example below is reconstructed: the fields follow RFC 3464 and the diagnostic reuses the text Google documents for 550 5.1.1. The addresses and the sending host are fictional.

Reporting-MTA: dns; smtp.example.com
Final-Recipient: rfc822; first.last@gmail.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550 5.1.1 The email account that you tried to reach does not exist.

• Reporting-MTA names the server that writes the report: here, your email service provider.
• Final-Recipient gives the failing address. It is the key for matching against your list.
• Action: failed says delivery failed for good.
• Status: 5.1.1 is the enhanced status code: the 5 classes the failure as permanent, and 1.1 points to a mailbox that does not exist.
• Remote-MTA identifies the server that refused, here Gmail’s MX entry.
• Diagnostic-Code copies the server’s raw reply: the SMTP-layer 550, then the 5.1.1, then the readable text. Google suggests checking for a typo or an extra space.

The same report for a mailbox that is filling up changes three lines, based on Google’s text for 452 4.2.2:

Action: delayed
Status: 4.2.2
Diagnostic-Code: smtp; 452 4.2.2 The recipient's inbox is out of storage space.

A delayed report warns that the provider is still retrying. One detail changes how you read a dashboard. A final notification can show Action: failed with Status: 4.2.2. RFC 3463 defines class 4 as a transient condition that caused the delivery to be abandoned or delayed. The provider gave up after its attempts, with no permanent refusal from the server. This case counts as an exhausted soft bounce.

Decision table: from code to action

The wording comes from Google Workspace’s documentation on Gmail SMTP errors and from the RFC 3463 definitions.

The last row is the most expensive one to misread. According to Google, a 5.7.26 means the message is blocked because authentication (SPF or DKIM) is missing or because the domain’s DMARC policy rejects it. The address is valid: your domain is the one failing. Deleting those contacts empties the list without fixing the cause. Greylisting belongs to the 4.7.x row: the server deliberately refuses the first attempt from an unknown sender. The second one goes through.

Synchronous and asynchronous bounces: when the refusal arrives

A synchronous refusal lands during the SMTP session. The server answers 550 5.1.1 to the RCPT TO command (or at the end of DATA): your provider knows the outcome before closing the connection, and there is no NDR to wait for.

The asynchronous bounce takes another route. The server first answers 250 and accepts the message. If delivery then fails internally, RFC 5321 (section 6.1) requires it to write a notification. It goes to the return address with an empty sender: the MAIL FROM command then contains <> (section 3.6.3), which prevents notification loops. This NDR lands in your domain’s bounce mailbox, sometimes several days after the send, in the DSN format described above. For your list the consequence is direct: an asynchronous bounce does not show up in the immediate send report. It attaches to the address through the Final-Recipient field, then follows the same rules as a synchronous refusal: hard bounce, immediate removal. A provider that does not read this return mailbox leaves those addresses in circulation and inflates the bounce rate of the next campaign.

Depending on their configuration, catch-all domains produce this second case: they accept any address during the SMTP session and sort the mail afterwards. A nonexistent address can then come back as a delayed NDR or vanish without any reply. No code received during the session lets you predict it. So only lock in a campaign’s bounce rate after your provider’s give-up window has passed. Also treat the silence of a catch-all domain as incomplete information. Undeliverable emails gathers these edge cases, with a way to sort them.

Reading traps: the 5xx to keep and the suppression cache

The first digit classes the bounce and says nothing about whether the address is valid. The 5.7.x families described above often carry a 5 on valid contacts.

Two other traps skew the reading. An auto-reply proves the message reached the mailbox, so it does not count as a bounce. Filing it as a soft bounce would push an active contact out. The suppression cache works the other way: an address placed in your provider’s internal suppression list is no longer sent to, even if the mailbox was recreated in the meantime. A contact who swears they receive nothing while their address is valid should be looked for in that list first. The same reflex applies after fixing a typo: the new address is unknown to the provider and goes through. The old, misspelled one stays suppressed. It will never come out of a bounce export, since it is no longer sent to and so can no longer bounce. Match the two rows before concluding that a contact was lost.

Removal rule: how many sends, over what period

For a hard bounce, the delay is zero. Klaviyo suppresses these profiles automatically. Mailchimp cleans the address from the audience (help pages checked in October 2026). The 5.7.x codes are the exception: they target your configuration. A typo at collection is fixed at the source, with a double opt-in.

For a soft bounce, apply four rules:

• Count one bounce per send. Retries from a single provider, spread over several days, count as one.
• Remove the address at the 3rd consecutive soft bounce, on distinct sends.
• We recommend at least 14 days between the first and the third bounce, to tell a mailbox that is out of service for good from a passing outage at the recipient. This delay is an editorial choice: no standard requires it.
• Reset the counter to zero as soon as a send is delivered.

Example: an address that returns 452 4.2.2 on the October 2 and 9 campaigns and again on the 23rd leaves the list on the 23rd. With three campaigns sent between October 2 and 4, it stays: three bounces in 2 days come from one outage, and the address has not yet crossed the required 14 days.

This removal rule is an editorial recommendation. Providers publish different thresholds. In its bounce guide, MailerLite says an address that bounces 3 times in a row is converted to a hard bounce and becomes inactive. Mailchimp converts a soft bounce to a hard bounce after 7 bounces for an address with no subscriber activity. For a contact with earlier activity, the limit rises to 15. The address is then cleaned (Mailchimp’s official help, checked in October 2026). Klaviyo applies a higher threshold: according to its “Suppressed profiles” help page (updated March 30, 2026), the profile is suppressed after more than 7 consecutive soft bounces. Only those from the past 2 years count. The same address can therefore survive 7 bounces in one tool and drop out at the 3rd in the other. In a permissive provider, take the address out yourself with an exclusion segment.

The duration also depends on your sending pace. The count is per send: a weekly campaign reaches the 3rd bounce in 3 weeks, a monthly one in 3 months. A low sending frequency therefore delays removal: at one send a month, a dead address stays on the list for a quarter.

Bounce thresholds: what each percentage measures

The thresholds to remember are 2% and 5% for bounces, and 0.3% for reported spam. They do not measure the same thing.

The first, 2%, is an industry benchmark for the bounce rate (MailerLite). The second, 5%, is a contractual limit: MailerLite’s anti-spam policy reserves the right to suspend an account and investigate beyond 5% bounces or 0.2% complaints.

The third, 0.3%, comes from Google and measures something else: the spam rate shown in Postmaster Tools, meaning the share of messages that recipients report as unwanted. Since February 1, 2024, all senders to Gmail must keep it under 0.3%. Google recommends staying under 0.10%.

Bounces and spam reports are two separate measures: your provider counts the former, Postmaster Tools the latter. A list can show 1.5% bounces, under the 2% mark, with 0.05% spam and cross no threshold. The reverse exists too: 0.4% spam with 0.2% bounces breaks Google’s rule. The 2% threshold applies to a campaign’s average: on 10,000 sends, it means 200 bounces in total. A single wave of hard bounces on an old list is enough to cross it. To bring a high bounce rate back under the 2% mark, see managing your bounce rate.

Bounces, sender reputation and blocklists

A send to an old list brings 5.1.1 errors up in the campaign report. Each 5.1.1 proves an address was collected and never rechecked: the campaign report is then an inventory of what the list has lost since collection. To read the trend, compare the number of 5.1.1 errors per send over three successive campaigns. A rising curve signals an aging list, a flat curve a one-off import problem. Tracking goes through Postmaster Tools on the Gmail side (the spam rate is compared there with the 0.3% ceiling) and through Sender Score monitoring for the IP address’s rating.

On a new IP that is ramping up, every 5.1.1 weighs more: Google asks you to start with engaged recipients, which an uncleaned list contradicts. The method is described in warming up an IP.

Spam traps (booby-trapped addresses) hide in old or purchased lists and can lead to blocklists. Spam traps and honeypots are explained separately. Once you are on Spamhaus or another list, getting off means a request to the operator, with the steps laid out for getting delisted from a blocklist. The split between blocklists to monitor or ignore shows which ones deserve an alert.

Upstream causes to fix at collection

Purchased lists concentrate invalid addresses and traps: the first send produces a spike of hard bounces, hence a bounce rate that overshoots every benchmark. Double opt-in eliminates typos and fake emails at sign-up. An expired domain name, or one with no MX record, produces a 5.1.2. The 5.7.x authentication refusals are fixed on the SPF, DKIM and DMARC side, and DKIM2, being standardized in the IETF DKIM working group (datatracker.ietf.org, checked in October 2026), aims to improve the value of delivery status notifications. Content or an email subject line judged suspicious triggers the same kind of policy refusal, with the address not at fault.

Frequently asked questions about bounces

Should you delete an address after a single soft bounce?

No. An isolated soft bounce often comes from a full mailbox or a passing outage. Count it in your rule: removal at the 3rd consecutive bounce, on sends spread over at least 14 days. The counter goes back to zero as soon as a message is delivered.

Can a hard bounce become valid again?

Yes, in rare cases: a recreated mailbox or a corrected typo. The provider keeps the address suppressed and no longer tries. Take it off that list case by case, once the contact confirms.

How long does a provider retry a soft bounce?

RFC 5321 recommends at least 30 minutes between attempts and a give-up period of at least 4 to 5 days. Each provider applies its own duration: check it in its documentation before calculating a final bounce rate.

Verify the list before sending

Filtering after the fact amounts to sending once to every dead address: the hard bounce is already counted in the campaign when the provider suppresses the profile. Verification upstream removes those addresses before the first send. A verifier checks the domain and whether the mailbox exists, which is exactly what the 5.1.1 and 5.1.2 punish after the fact. The email verification tools are compared in a guide. Regular upkeep of a clean database keeps the list from losing again what it has gained.

Before your next campaign, run a sample of the list through CaptainVerify’s email list verification tool and compare the result with your current hard bounce rate.