A hard bounce is a permanent delivery failure, usually because the address or domain doesn’t exist, and the fix is to stop sending to that address. A soft bounce is a temporary failure, such as a full mailbox, a server outage, or throttling, and the fix is to let retries run and only suppress the address if it keeps failing. The SMTP code tells you which one you have: 5xx codes are permanent and 4xx codes are temporary.

That’s the textbook answer. In practice, some hard bounces have nothing to do with the recipient, and some soft bounces are dead addresses in disguise. This guide covers the causes behind each type, the fixes that actually work, and the gray areas where the label leads people astray.

The core difference between hard and soft bounces

Both definitions come from the SMTP standard. RFC 5321 says a 4yz reply means the error is temporary and the request may be tried again, while a 5yz reply means the client should not repeat the exact request. RFC 3463 adds the enhanced status codes (4.x.x for persistent transient failures, 5.x.x for permanent failures) and a subject digit that tells you where the problem is.

	Hard bounce	Soft bounce
Code class	`5xx` / `5.x.x`	`4xx` / `4.x.x`
Meaning	The receiver will not accept this message	The receiver can’t accept it right now
Retry?	No	Yes, automatically
Effect of ignoring it	Repeated failures damage reputation	Usually none, unless it repeats for weeks
Default action	Suppress immediately	Retry, then suppress after a threshold

ESPs use the same split. Amazon SES labels bounces Permanent (hard) or Transient (soft) and tells senders to remove permanently bounced recipients from their lists immediately, according to its notification documentation.

Hard bounce causes and fixes

1. The mailbox doesn’t exist

Codes you’ll see: 550 5.1.1, Yahoo’s 554 ... This user doesn't have a yahoo.com account, Microsoft’s 5.1.10 Recipient not found.

Why it happens: a typo at signup, an employee who left the company, an account deleted for inactivity, or an address that was never real.

Fix: suppress the address permanently. Yahoo’s SMTP error code page says not to retry and to remove the address from your list. If the contact matters (a customer, a deal in progress), reach them another way and ask for a current address. Our deep dive on 550 5.1.1 User Unknown covers this one in detail.

2. The domain doesn’t exist or doesn’t accept mail

Codes you’ll see: Gmail’s 553 5.1.2 We weren't able to find the recipient domain (Google), or 556 5.1.10 for a domain that publishes a null MX record.

Why it happens: misspelled domains (gmial.com, yaho.com), companies that shut down or rebranded, or domains that were only ever used for a website. RFC 7505 lets a domain publish a “null MX” (a single MX record of 0 .) to say outright that it accepts no email, and senders reject such addresses with 556 5.1.10.

Fix: suppress the address. Domain-level failures are also the easiest to prevent, because a simple DNS lookup at signup catches them. See common email typos for the domain misspellings that show up most.

One wrinkle: Amazon SES classifies a domain that doesn’t exist as a soft bounce at first and retries it for an extended period before reporting a failure, per its sending process documentation. The end result is still a failure. It just arrives later.

3. The mailbox has been disabled

Codes you’ll see: Gmail’s 550 5.2.1 The email account that you tried to reach is inactive.

Why it happens: the provider has disabled the account. RFC 3463 notes that x.2.1 can be permanent or temporary, depending on whether the mailbox is ever re-enabled.

Fix: treat a 5.2.1 as a hard bounce for marketing mail. For transactional mail to a known customer, flag the account and ask them to update their address next time they sign in.

4. Your message was blocked (policy rejection)

Codes you’ll see: 550 5.7.1 (“This message is likely unsolicited email”), 550 5.7.26 (failed DMARC), and 550 5.7.25 (missing PTR record), all listed in Google’s SMTP error reference.

Why it happens: the receiver rejected your mail because of authentication, reputation, content, or a blocklist listing. The address may be perfectly valid.

Fix: don’t delete the recipient. Fix the cause: set up SPF, DKIM, and DMARC, check blocklists, review content, and slow down. This is the most common gray area, covered below.

Soft bounce causes and fixes

1. Mailbox full

Codes you’ll see: Gmail’s 452 4.2.2 The recipient's inbox is out of storage space and, for an inbox that is full and inactive, 552 5.2.2 (Google).

Fix: let retries run. If the same address returns “mailbox full” across several campaigns spread over weeks, treat it as abandoned. Full details in “Mailbox Full” Bounces: Should You Remove the Address?

2. Server temporarily unavailable

Codes you’ll see: 421 4.7.0 Try again later, closing connection, 451 4.3.0 ... temporarily rejected this message.

Fix: nothing, usually. Your MTA or ESP retries on a schedule. RFC 5321 suggests waiting at least 30 minutes between retries and continuing for at least 4 to 5 days in general. Transactional mail often needs a much shorter window. Our post on retry schedules explains why.

3. Rate limiting and throttling

Codes you’ll see: 450 4.2.1 The user you are trying to contact is receiving email too quickly, 421 4.7.28 Gmail has detected an unusual rate of email (Google).

Fix: slow down for that provider. Google’s sender guidelines advise reducing sending volume when messages start bouncing or getting deferred, until the error rate drops. Throttle per destination, not globally.

4. Greylisting

What you’ll see: a generic 4xx on the first attempt from an unknown sender, then success on retry.

Fix: none needed if your sending server retries correctly. The M3AAWG Sender Best Common Practices point out that some receivers temp-fail a first message specifically to see whether the sender follows the RFCs and retries, which spammers often don’t.

5. Message too large or content rejected

What you’ll see: Amazon SES subtypes MessageTooLarge, ContentRejected, and AttachmentRejected are all classed as transient (AWS).

Fix: shrink the message, host large files instead of attaching them, and remove file types that receivers commonly block. Retrying the same message unchanged won’t help, even though the bounce is labeled “soft.”

The gray areas: when the label misleads you

The hard/soft split was designed for mail servers, not marketers. The M3AAWG document says as much: the numeric codes tell the sending server what to do, but they don’t say whether an address should be removed from a list. You have to read the descriptive text.

Here are the cases where blindly following the label goes wrong.

Hard bounces that aren’t the recipient’s fault

A 5.7.x rejection is permanent for that message, but the recipient is fine. If your platform auto-suppresses every 5xx, a single authentication mistake can wipe thousands of valid contacts from your list in one send. Before suppressing, check the subject digit:

5.1.x (addressing): suppress
5.2.x (mailbox): usually suppress
5.7.x (policy and security): fix your setup, keep the address
5.4.x (routing): investigate; it may be the domain or a temporary DNS problem

Soft bounces that are really dead addresses

An address that returns “mailbox full” every week for two months is not coming back. Neither is a mailbox the provider has shut down for inactivity. Yahoo, for example, says a mailbox that isn’t accessed for 12 months becomes inactive and stops receiving new email (Yahoo Help).

That’s why every serious platform converts repeated soft bounces into suppressions. Mailchimp allows 7 soft bounces for an address with no subscriber activity and up to 15 for contacts with previous activity before converting a soft bounce to a hard bounce (Mailchimp). M3AAWG’s guidance is to remove an address that bounces consecutively at least two times over two weeks or more.

The 552 exception

RFC 5321 (section 4.5.3.1.10) notes that some older servers return 552 when a message has too many recipients, when the correct code is 452, and says clients should treat a 552 in that case as temporary. If you send to many recipients per message, watch for this.

A decision table you can use

What the bounce says	Type	Action
`5.1.1`, “user unknown”, “no such user”	Hard	Suppress now
`5.1.2`, `5.1.10`, domain not found or null MX	Hard	Suppress now
`5.2.1`, account disabled or inactive	Hard	Suppress (marketing); flag (transactional)
`5.7.x`, policy, DMARC, spam, blocklist	Block	Keep address; fix authentication or reputation
`4.2.2` / `5.2.2`, mailbox full	Soft	Retry; suppress after repeated failures over weeks
`421`, `450`, `451`, busy, try later	Soft	Let the MTA retry
`4.2.1`, `4.7.28`, rate limited	Soft	Slow down for that provider
Size, content, or attachment rejected	Soft	Change the message, then resend

If you’re building the automation behind this table, the existing guide on bounce classification covers how classification should feed suppression and retries, and what belongs on a suppression list covers how long each entry should stay there.

How to prevent both kinds of bounces

You can’t prevent every soft bounce, since full mailboxes and busy servers are outside your control. You can prevent most hard bounces:

Validate at the point of capture. Check syntax, confirm the domain has MX records, and catch typo domains before the address is saved.
Confirm new signups. Double opt-in proves the address works and that its owner wanted your mail.
Re-check old lists before sending. Addresses decay as people change jobs and providers close inactive accounts.
Never buy lists. Amazon SES warns that rented or purchased lists can contain large numbers of invalid addresses and spam traps (AWS).
Authenticate your domain. Proper SPF, DKIM, and DMARC prevent the 5.7.x policy rejections that look like hard bounces.

For step 1 and step 3, you can run addresses through the free email verifier on this site. It checks syntax, domain and MX records, disposable and role-based addresses, free-provider domains, and common typos. It doesn’t connect to the recipient’s mailbox, so it won’t catch a well-formed address at a real domain where the user has left. That’s the kind of hard bounce that only sending, or a full SMTP-level check, will reveal.

FAQ

Is a soft bounce bad for deliverability?

A single soft bounce isn’t. It’s a normal part of sending email, and your server retries automatically. Repeated soft bounces to the same address are a problem, because they suggest an abandoned mailbox, and continuing to mail it adds failures to your record.

Should I delete hard bounced contacts from my CRM?

Suppress them rather than delete them. Keeping the record with a “bounced” flag stops someone from re-importing the same address from an old spreadsheet and bouncing it again. Delete only if your data retention policy requires it.

Why did a valid address hard bounce?

Usually because the bounce was a policy block, not an addressing error. Check the code: a 5.7.x code points to authentication, reputation, or content. Fix that problem and the address will likely accept mail again.

How many soft bounces before I remove an address?

There’s no single standard. Mailchimp converts a soft bounce to a hard bounce after 7 soft bounces for inactive contacts and up to 15 for previously active ones, while M3AAWG suggests removing an address that bounces consecutively at least twice over two weeks or more. Pick a rule that combines a count with a time window so one bad week at the receiver doesn’t cost you a good subscriber.

Hard Bounce vs Soft Bounce: Causes and Fixes