# Hard bounce vs soft bounce: what's the difference and what should you do? URL: https://iblockspam.com/blog/hard-bounce-vs-soft-bounce Last updated: 2026-10-09 Published: 2026-10-09 Topic: Running email day to day Author: iBlockSpam Team > The difference between hard and soft email bounces, how RFC 3463 status codes classify them, when to retry or remove an address, and how to keep lists clean. ## Short answer A hard bounce is a permanent failure, usually a 5.x.x status code such as 5.1.1 for an address that doesn't exist; stop mailing that address. A soft bounce is a temporary failure, a 4.x.x code such as a full mailbox or a busy server; let your server retry. Policy rejections (5.7.x) need a fix on your side instead. When an email can't be delivered, the receiving server answers with a status code. Senders sort those failures into two buckets: hard bounces, which are permanent, and soft bounces, which are temporary. The difference decides what you do next: retry, remove the address, or fix something on your side. This guide explains how the codes map to each, and how to handle them without damaging your list or your reputation. ## What is the difference between a hard and soft bounce? "Hard" and "soft" aren't terms from the email standards. They're industry shorthand, and the [M3AAWG Sender Best Common Practices](https://www.m3aawg.org/sites/default/files/doc_files/m3aawg-sender-best-common-practices-aug-27-2026.pdf) define them: - **Hard bounce:** delivery failed "due to a permanent failure such as the email address no longer exists or has never existed, or the domain no longer exists or has never existed." - **Soft bounce:** delivery failed "due to a temporary failure such as a full mailbox, a connection problem, a technical issue at the provider, or throttling" of the sending IP. The standards behind them are SMTP reply codes in [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html) and enhanced status codes in [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html). ## How do status codes tell you which kind of bounce it is? A rejection usually carries two codes, for example `550 5.1.1`. The first is the SMTP reply code. The second is the enhanced status code, written as class.subject.detail. ### The class: first digit RFC 3463 defines three classes: | Class | RFC 3463 meaning | What your server does | |---|---|---| | 2.X.X | Success | Nothing; the message was delivered | | 4.X.X | "Persistent transient failure": the message is valid, but a temporary condition delayed or stopped delivery | Keeps the message and retries later | | 5.X.X | "Permanent failure": not likely to be resolved by resending the message in the current form | Stops and returns a bounce | RFC 5321 gives a rule of thumb for the reply codes: a reply is 4yz if the same command could succeed if repeated without any change. A 5yz reply means the client "SHOULD NOT repeat the exact request." ### The subject: second number The middle number tells you what went wrong: | Subject | RFC 3463 name | Typical cause | |---|---|---| | X.1.X | Addressing status | The address or domain doesn't exist | | X.2.X | Mailbox status | Mailbox full, disabled or over a limit | | X.3.X | Mail system status | Receiving system problem, message too big for the system | | X.4.X | Network and routing status | Routing failures, delivery time expired | | X.5.X | Mail delivery protocol status | Protocol errors | | X.6.X | Message content or media status | Content conversion problems | | X.7.X | Security or policy status | Blocked sender, failed authentication, policy rejection | The subject matters as much as the class. A 5.1.1 and a 5.7.1 are both permanent, but they call for opposite actions. ## Which bounces mean you should remove the address? Here's how common codes sort out in practice. Each link goes to our reference page for that code. | Code | What it means | Type | What to do | |---|---|---|---| | [550 5.1.1](https://iblockspam.com/smtp-errors/550-5-1-1) | Mailbox doesn't exist | Hard | Remove the address now | | [550 5.1.10](https://iblockspam.com/smtp-errors/550-5-1-10) | Recipient not found (Microsoft 365) | Hard | Remove the address now | | [556 5.1.10](https://iblockspam.com/smtp-errors/556-5-1-10) | Domain publishes a null MX; it accepts no mail | Hard | Remove the address now | | [Yahoo 554 user not found](https://iblockspam.com/smtp-errors/yahoo-554-dd-user-not-found) | No Yahoo account at that address | Hard | Remove the address now | | [552 5.2.2](https://iblockspam.com/smtp-errors/552-5-2-2) | Mailbox full | Soft in practice | Retry; remove if it persists | | [421](https://iblockspam.com/smtp-errors/421) or [451 4.7.1](https://iblockspam.com/smtp-errors/451-4-7-1) | Server busy, rate limit or a temporary policy deferral | Soft | Let your server retry | | [550 4.4.7](https://iblockspam.com/smtp-errors/550-4-4-7) | Microsoft 365: retries ran out and the message expired | Soft that became final | Check why it never delivered | | [552 5.3.4](https://iblockspam.com/smtp-errors/552-5-3-4) | Message too big | Permanent for that message | Resend smaller; keep the address | | [550 5.7.26](https://iblockspam.com/smtp-errors/550-5-7-26) | Gmail: message failed authentication | Policy | Fix SPF, DKIM or DMARC; keep the address | | [550 5.7.1 client host blocked](https://iblockspam.com/smtp-errors/550-5-7-1-client-host-blocked) | Microsoft 365: your sending IP is on a blocklist | Policy | Fix reputation or delisting; keep the address | ### Why "mailbox full" is a special case RFC 3463 says the mailbox-full code X.2.2 "should be used as a persistent transient failure," which means a 4.2.2. In practice many servers send `552 5.2.2` with a permanent 5 class. The RFC's intent is clear: a full mailbox can be emptied, so it's a soft condition. Don't remove the address on the first one. ### Why policy rejections aren't list problems M3AAWG notes that "many types of 5xx codes indicate a policy violation according to the descriptive text," and that the text might show the sender's IP "is on a blocklist/blacklist." The address may be perfectly valid. The receiver objected to your server, domain or message. Removing the recipient hides the problem instead of fixing it. Check the IP with the [Blacklist Checker](https://iblockspam.com/tools/blacklist-checker) and the [PTR Lookup](https://iblockspam.com/tools/ptr-lookup), and test authentication with the [Email Deliverability Test](https://iblockspam.com/tools/deliverability-test). ## What happens to a soft bounce over time? Your mail server handles soft bounces for you. It keeps the message in its queue and retries. RFC 5321 says the "give-up time generally needs to be at least 4-5 days." If every retry fails, the server finally returns a bounce, often with the delivery-time-expired code X.4.7. RFC 3463 describes it as a message "considered too old by the rejecting system." M3AAWG stresses that senders must not treat temporary failures as permanent, "because some receivers will tempfail or greylist an initial message to see if the sender is following the RFCs correctly, as spammers generally do not do so." Bounces also arrive in two ways. Most are synchronous: the receiver rejects the message during the SMTP conversation, and your server or platform records it at once. Some are asynchronous: the receiver accepts the message, then sends a bounce message to your Return-Path address, sometimes hours or days later. M3AAWG notes that B2B mail "may have a higher rate of asynchronous bounces." Your system needs to process both. If you're receiving bounces for messages you never sent, that's backscatter, not a delivery problem with your mail. See our guide on [backscatter bounce messages](https://iblockspam.com/blog/backscatter-spam-bounce-messages). ## What about bounces from everyday business email? Bounces aren't only a newsletter problem. When a colleague emails a customer and gets a non-delivery report back, the same logic applies: - **5.1.1 or 5.1.10** usually means a typo or an address that no longer exists. Check the spelling, then ask the contact for their current address. - **5.2.2, mailbox full,** means the message may get through later. Wait, then try again or use another channel. - **5.7.x** means the receiver refused your organization's mail. Pass the full bounce to whoever manages your email, because other people's messages are probably failing too. Our guide to [reading email headers](https://iblockspam.com/blog/how-to-read-email-headers) helps when you need to trace where a message went. ## Why do bounces matter for deliverability? Receivers read a high bounce rate as a sign of a careless sender. M3AAWG says "many times a receiver will penalize a sending IP for too many messages that end up bouncing with permanent failures," and that large volumes of hard bounces "are too often indicative of a poorly managed registration process or an old or misapplied mailing list." The providers say the same in their own words: - Yahoo's [best practices](https://senders.yahooinc.com/best-practices/) tell senders to "monitor hard and soft bounces as well as inactive recipients" and to remove invalid recipients promptly. - Microsoft's [sender guidance](https://learn.microsoft.com/en-us/defender-office-365/external-senders-mail-flow-troubleshooting) says invalid addresses that produce non-delivery reports "put your outbound email at risk for further scrutiny by email filtering services." - Google's [sender guidelines](https://support.google.com/mail/answer/81126) say that if messages start bouncing or being deferred, "reduce the sending volume until the SMTP error rate decreases." ## How do you keep your list clean? 1. **Suppress hard bounces at once.** A "user unknown" or "domain doesn't exist" reply means stop. M3AAWG: "it is very important this message not be retried and the email address be suppressed from future mailings." 2. **Track soft bounces per address.** M3AAWG says "generally it is considered a best practice to remove an address from the list if it bounces consecutively at least two times over two weeks or more." 3. **Read the text, not just the code.** M3AAWG notes the numeric codes "do not clearly state whether or not the address should be removed." The descriptive text tells you whether it's the address or your setup. 4. **Separate policy bounces.** Route 5.7.x rejections to whoever runs your email setup, not to list cleanup. 5. **Confirm addresses at sign-up.** Google advises confirming each recipient's address before subscribing them. A confirmation step stops typos and fake addresses entering your list. 6. **Share one suppression list** across every tool that mails the same people. 7. **Watch for sudden jumps.** A spike in hard bounces after importing contacts means the import was bad. Stop and clean it before the next send. If you're bringing a new domain or IP online, bounces are one of the first signals to watch; see [how to warm up a new domain or IP](https://iblockspam.com/blog/email-warm-up-new-domain-ip). ## Next steps 1. Look up any bounce code you don't recognize in the [SMTP Error Code Lookup](https://iblockspam.com/tools/smtp-error-codes). 2. Set your sending platform to suppress hard bounces immediately and soft bounces after repeated failures. 3. For 5.7.x rejections, check your IP with the [Blacklist Checker](https://iblockspam.com/tools/blacklist-checker) and your authentication with the [Email Deliverability Test](https://iblockspam.com/tools/deliverability-test). 4. If mail is delivered but lands in junk, read [why your emails are going to spam](https://iblockspam.com/blog/why-are-my-emails-going-to-spam). Browse more guides on [running email day to day](https://iblockspam.com/blog/topic/operations). ## Frequently asked questions ### Is a full mailbox a hard bounce or a soft bounce? Treat it as soft. RFC 3463 says the mailbox-full code X.2.2 should be used as a persistent transient failure, although some servers send it as 552 5.2.2 with a permanent 5 class. Let your server retry, and only remove the address if it keeps bouncing across several sends over a couple of weeks. ### How many soft bounces before I remove an address? There's no standard number. M3AAWG says it's generally considered good practice to remove an address that bounces consecutively at least two times over two weeks or more. That window allows for temporary problems at the receiving server. Many sending platforms apply a similar rule automatically. ### Should I remove an address after a 550 5.7.1 rejection? Usually not. Codes in the 5.7.x group are security or policy rejections. They often mean the receiver refused your server, domain or content, for example a blocklisted IP or failed authentication. The address itself may be fine. Read the text, fix the cause on your side, then send again. ### Why did a bounce arrive days after I sent the message? Your server kept retrying after temporary failures and finally gave up. RFC 5321 says senders should keep trying for at least four to five days. When that time runs out, the message bounces with a delivery-time-expired error such as 4.4.7. Some receivers also accept a message and send a bounce later. ### Do hard bounces hurt sender reputation? Yes. M3AAWG says receivers may penalize a sending IP for too many permanent failures, and that large volumes of hard bounces often point to a poorly managed sign-up process or an old list. Microsoft also says addresses that produce non-delivery reports put your outbound mail at risk of more scrutiny. ## Sources - [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html) - [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html) - [M3AAWG Sender Best Common Practices, Version 4.0 (August 2026)](https://www.m3aawg.org/sites/default/files/doc_files/m3aawg-sender-best-common-practices-aug-27-2026.pdf) - [Gmail Help: Email sender guidelines](https://support.google.com/mail/answer/81126) - [Yahoo Sender Hub: Sender best practices](https://senders.yahooinc.com/best-practices/) - [Microsoft Learn: Troubleshooting mail sent to Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/external-senders-mail-flow-troubleshooting) ## Free tools for this guide - [SMTP Error Code Lookup](https://iblockspam.com/tools/smtp-error-codes): Paste a bounce or type a code like 550 5.7.26: plain-English meaning, likely causes and fixes, with sources. - [Email Deliverability Test](https://iblockspam.com/tools/deliverability-test): Send one email and see its SPF, DKIM and DMARC results, reverse DNS, blocklists, TLS and spam verdict. - [Blacklist Checker](https://iblockspam.com/tools/blacklist-checker): Check an IPv4 or IPv6 address, or your mail servers, against public spam blocklists, with policy and delisting links. - [Reverse DNS (PTR) Lookup](https://iblockspam.com/tools/ptr-lookup): Check PTR records, forward-confirmed reverse DNS and generic-looking host names. --- Source: iBlockSpam, https://iblockspam.com/blog/hard-bounce-vs-soft-bounce (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt