Blog · Deliverability
Why Corporate Mail Servers Soft-Bounce Your Email and How to Read the Bounce Code
Corporate recipients soft bounce more than consumer recipients because their gateways are stricter, their mailboxes have quotas and get disabled when staff leave, and their policy engines reject mail that Gmail and Yahoo quietly deliver. The bounce itself tells you which of those it is, but only if you read the code instead of filing every 4.x as "soft bounce". The code is three numbers. The second number is the one that matters.
Here is the concrete case that makes this worth a full answer. A MailerLite list with 11,000 subscribers running since 2012 logged 14 soft bounces in a single day and zero hard bounces. Almost every bounce came from a corporate domain. Gmail and Yahoo returned next to nothing. No amount of list cleaning would have fixed that ratio, because the addresses were valid and the messages were acceptable to the consumer providers. The corporate gateways had their own opinions.
What a soft bounce actually is
In SMTP (RFC 5321) every reply is three digits and a space. The first digit decides everything:
| First digit | Meaning | What the sender should do |
|---|---|---|
| 2xx | Accepted | Nothing |
| 4yz | Transient negative completion | Try again |
| 5yz | Permanent negative completion | Do not repeat the same request |
A soft bounce is the 4yz case. The server did not accept the message, the condition is temporary, and the sender keeps delivery responsibility.
There is one detail here that surprises people. Once a server accepts your message at DATA and then returns a 4yz, it is required to make no further attempt to deliver that message. The retry is now your job, not the receiving server's. If your sending platform gives up after one attempt, a mail that would have succeeded on the second try is lost with no notification.
RFC 5321 also sets the pace: the sender must wait after a failed attempt, and the retry interval should be at least 30 minutes. Most platforms retry on a schedule measured in hours, and keep the message in the queue for a few days before giving up. Some keep it far longer. The interval is a platform setting, not a protocol rule, and it is worth knowing yours.
The three numbers in a bounce code
The bare 4yz reply line ("451 4.2.2 Mailbox full") is not very useful on its own. RFC 3463 defines the standard structure underneath it:
class.subject.detail
- First digit: success or failure. 2, 4 or 5.
- Second digit: the probable source of the problem.
- Third digit: the precise condition.
The second digit is the useful one, and senders rarely look at it. The subject values you will actually meet:
| Subject | Area | Typical corporate example |
|---|---|---|
| 0 | Other or undefined | 4.0.0, unhelpful on its own |
| 1 | Addressing | Recipient rejected before delivery |
| 2 | Mailbox | Full, disabled, over message length limit |
| 3 | Mail system | Mailbox or transport problem |
| 4 | Network or routing | No answer from host |
| 5 | Protocol | Protocol-level failure |
| 6 | Media | Attachment or content problems |
| 7 | Security or policy | Refused by a policy filter |
Read the second digit before you do anything else. It tells you whether you are looking at a mailbox, a network, or a policy, and those three need three completely different fixes.
The codes that matter at corporate mailboxes
These are the ones that fill a corporate bounce report:
Codes below are defined in RFC 3463 except 4.7.12, which is a vendor extension used by Exchange-family servers for rate limiting.
| Code | Meaning | What it looks like in practice | What to do |
|---|---|---|---|
| 4.2.0 | Other or undefined mailbox status | Mailbox exists, something about it triggered the bounce | Read the human-readable text that follows the code |
| 4.2.1 | Mailbox disabled, not accepting messages | Employee left, account disabled, mailbox on hold | Retry first. RFC 3463 calls this transient or permanent depending on the mailbox state |
| 4.2.2 | Mailbox full | Per-mailbox quota hit | Nothing to fix on your side. The user deletes mail and the retry lands |
| 4.2.3 | Message length exceeds administrative limit | Recipient limit below your size | Permanent. Reduce size or stop mailing this address |
| 4.4.1 | No answer from host | Gateway busy, firewall dropping, VPN mail gateway asleep | Retry. Corporate mail paths go down over weekends |
| 4.7.0 | Other or undefined security status | Policy filter with no specific code | Read the text. This is the catch-all for refusals |
| 4.7.1 | Delivery not authorized, message refused | Sender not authorised by per-host or per-recipient filtering | Fix the authorisation or the authentication behind it |
| 4.7.12 | Rate limited (vendor extension) | Too many messages in a given window | Slow down or stagger. Big broadcast patterns trip this on hosted mail |
Two of those deserve emphasis. 4.2.2 is not your fault and is not a reason to suppress the address. RFC 3463 classes it as a persistent transient failure precisely because the recipient can free space. Suppressing on a 4.2.2 loses a real subscriber over a full inbox.
4.7.1 is the one people skip. It means the message was refused, and the most common reason at corporate gateways is that the sender failed an authentication policy. That is a problem you can fix, and it is covered further down.
Why corporate bounces outnumber consumer bounces
Five reasons, in rough order of how often they show up.
Stale addresses from staff turnover. When an employee leaves, the mailbox is usually disabled or deleted by the IT department, sometimes with a grace period. The address stays in your list for years. Consumer mailboxes are personal and rarely deleted on a schedule.
Per-mailbox quotas. Corporate environments cap mailbox storage, and the caps are real. A user who stops cleaning their inbox starts generating 4.2.2 bounces that have nothing to do with you.
Greylisting. Many corporate gateways accept a connection but defer the first message from an unfamiliar sending host. The usual delay is minutes to a few hours, though badly configured systems defer far longer. The second delivery usually succeeds. This is the classic case where suppressing on first sight is exactly wrong.
Rate limiting. Exchange Online and comparable hosted platforms document inbound throttling per mailbox, and large broadcast patterns from a single sending IP can trip it. The bounce arrives as a 4.7.x with rate-limit text, often concentrated in one company's domain.
Stricter policy. Corporate gateways run content filters, sender reputation checks and authentication policy that consumer providers are more forgiving about. Microsoft announced in 2025 that Outlook.com and Exchange Online would begin rejecting inbound mail that fails DMARC, in stages through the year. Corporate tenants got that enforcement earlier and harder than most senders expected.
The pattern to notice: the same underlying problem can arrive twice. A gateway that greylists a message may defer it once with a 4.7.x and refuse it later with a 5.7.x. If you only look at hard bounces, you have already lost the early warning.
The fix for each code class
Group the codes first, then act. Four groups cover almost everything.
4.2.x, mailbox condition. 4.2.2 is the recipient's storage. 4.2.1 is usually a person who no longer works there, though the same code also covers a mailbox that is only temporarily disabled. Do not suppress on first bounce. Keep the address through the full retry window your platform offers. If it comes back 4.2.1 after every retry, suppress it then, and record it as an address cleanup rather than a deliverability problem.
4.4.x, network or routing. Retry with the standard backoff. If one company keeps returning 4.4.1 over weeks, it is usually a mail gateway that only routes during business hours or a VPN appliance that is off. That is a recipient-side outage, not a reputation problem, and suppressing the domain punishes you for it.
4.7.x, security or policy. This is the class where you have work to do. Read the text after the code. Greylisting looks different from a rate limit, which looks different from an authentication refusal. Fix the specific cause, then watch whether the same code keeps coming back.
4.0.x and anything with no useful second digit. Go back to the raw SMTP reply, not the dashboard label. Most bounce tools collapse codes into a single soft-bounce bucket and throw away the part that told you what happened.
When the bounce is really an authentication failure
Here is the part that ties back to email security. RFC 3463 subject 7 is security or policy, and at corporate gateways the most common permanent cause inside that subject is a sender that failed SPF, DKIM or DMARC.
The problem is that the bounce code tells you the gateway refused you, not which of your sending sources was the problem. A single sending domain may use six or seven ESPs, a CRM, a billing system and a support desk. Each one signs differently, or not at all. A 4.7.1 from one corporate customer cannot tell you which of those broke.
That is where DMARC reporting earns its place. Your aggregate reports are a per-sending-source view of what receivers actually saw: which sources passed DMARC, which failed on alignment, and which are sending with no DKIM at all. When a corporate customer starts returning 4.7.x, you check the reports, find the source that is failing, and fix that source instead of guessing. DMARCFlow's job here is exactly that: surfacing which of your sending domains or ESPs are failing DMARC, so the bounce code you received becomes traceable to a specific sender. It does not read bounce codes for you. Nothing does that better than reading the raw SMTP reply yourself.
The same reports also tell you when the problem is not authentication. If every source passes DMARC and the 4.7.x keeps coming, the answer is somewhere in the recipient's filter, and no amount of DNS work will change it. That two-minute check is worth doing before the first bounce, because it turns a guessing game into a lookup. Tools built for this, DMARCFlow among them, exist to answer one question: which of my senders is failing, and where.
A 10-minute routine for any bounce report
- Group by code, not by recipient. Two hundred bounces across thirty codes is a list problem. Twelve bounces sharing one code is one gateway and one cause. Fourteen soft bounces spread across fourteen companies is normal. Fourteen from one company is a single gateway, and probably a single policy.
- Read the second digit. 2 is a mailbox, 4 is a network, 7 is a policy. That single digit tells you which team owns the problem.
- Use the right denominator. Corporate recipients as a share of what you actually sent to them, not as a share of your total list. Fourteen bounces from corporate addresses look alarming against a consumer-heavy list and unremarkable against a corporate-heavy one.
- Check the text, not the bucket. Most dashboards label everything 4.x as "soft bounce". The human-readable line after the code is where "mailbox full", "not authorised", "greylisted" and "rate limited" are actually different problems.
- Wait out the retry window before suppressing. A deferral that clears on retry is a working address. Suppressing early costs you subscribers and teaches you nothing.
- Check DMARC reports for any 4.7.x cluster. If the refusals are authentication, your reports name the source, and a tool like DMARCFlow shows you the failing sender without you exporting XML by hand. If they are not, the reports rule that out in a minute.
Frequently asked questions
Is a 4.2.2 soft bounce a problem?
Usually not. It means the recipient's mailbox is over quota. RFC 3463 treats it as a persistent transient failure because the user can free space, and the retry lands later.
Why do my bounces come from company domains and not Gmail?
Corporate gateways apply quotas, disable mailboxes when staff leave, greylist unfamiliar senders, throttle large broadcast patterns, and run stricter policy filters. Consumer providers do some of this too, but far more leniently.
Should I retry or suppress a 4.x bounce?
Retry. A 4yz means temporary by definition, and the protocol expects the sender to try again with a delay. Suppress only after the full retry window, or on a 5.x.
How long do senders retry a deferred message?
That is platform specific. RFC 5321 only sets the floor: at least 30 minutes between attempts. Most platforms retry over several days, some for weeks. Check your own setting, because if your platform stops after one attempt, every greylisted recipient is silently lost.
Does a soft bounce mean my SPF or DKIM is broken?
Not on its own. Authentication problems usually show up in the 4.7.x and 5.7.x codes. A 4.2.2 is a full mailbox. Read the second digit before you start rewriting DNS.
What does 4.7.1 delivery not authorized mean?
The sender was not authorised to deliver to that destination, usually by a per-host or per-recipient filter. Greylisting, reputation blocks and failed authentication policy checks all land here. Read the text after the code and check your DMARC reports for the source.
One more thing about suppression
Bounce-driven suppression feels like housekeeping and quietly becomes data loss. Every 4.x you suppress on sight removes an address that the protocol told you to try again. Keep the raw SMTP replies. In six months, when someone asks why their address stopped receiving mail, the code in the log is the only answer you will have.