B2B emails bounce because the receiving mail server refuses the message. The usual reasons are a mailbox that does not exist, a full inbox, a blocked sender or a server that is down.
Key takeaways
- Many bounces come from the list, not the copy. Addresses go stale when people change jobs or never existed.
- A hard bounce (5xx) is permanent. A soft bounce (4xx) is temporary. Suppress the first, retry the second.
- Blocks look like bounces but are your setup. A 5.7.x code points at authentication or reputation, not at the contact.
- On LeadOcean the filter is
emailStatus. Read it on the search row before you send.
What it is
A bounce is a rejection notice from the recipient's mail server, carrying a numeric code that says whether the failure is permanent, temporary or a block.
The SMTP standard (RFC 5321) defines the reply classes. A 4xx reply means a temporary failure and a 5xx reply means a permanent one (RFC 5321, September 2026). A second standard, RFC 3463, adds the dotted code such as 5.1.1 that names the reason (RFC 3463, September 2026).
Your sending tool turns those codes into the labels "hard bounce" and "soft bounce". The labels vary by tool. The codes do not.
B2B data ages with the workforce. Every job change turns a working address into a dead one, and the file in your CRM does not know.
How it works
Your message passes through several checks before it lands in an inbox. Each check can end in a bounce.
- Your tool looks up the MX record for the domain. No MX record means no mail server, and the send fails.
- It connects to that server and sends
RCPT TOfor the address. - The server checks the mailbox, your IP, your domain's SPF, DKIM and DMARC results, and its own policies.
- It replies 250 to accept, 4xx to defer or 5xx to refuse.
- Some servers accept first and bounce later. The notice then arrives after your tool already marked the send as delivered.
Worked example, with placeholders:
550 5.1.1 <jane.doe@acme.com>: Recipient address rejected: User unknownThe 550 is a permanent refusal. The 5.1.1 means the destination mailbox address is bad (RFC 3463). Jane Doe left Acme, or the address never existed. Suppress it and never send there again.
Every bounce traces back to one of five causes. Each has a different code and a different fix.
- The mailbox does not exist. Typos, guessed address patterns and people who left the company all end in 5.1.1. Expect this group in any list that is more than a few months old.
- The domain is dead. The company closed, the domain expired or it has no MX record. Code 5.1.2 marks a bad destination system.
- The mailbox cannot take mail right now. A full inbox (4.2.2) or an offline server (4.4.1) defers the message. These are soft bounces.
- The server blocks you. Code 5.7.1 means delivery was not authorized. Causes include missing SPF or DKIM, a poor IP reputation or spam-filter content rules.
- The domain accepts everything. A catch all server says yes to any address, then bounces the ones that do not exist. See catch all emails explained.
Bounce vs block vs spam folder
Teams read every failed send as one problem. The fix depends on which of these four it is.
| Hard bounce | Soft bounce | Block | Spam folder | |
|---|---|---|---|---|
| Code class | 5xx | 4xx | Usually 5.7.x | None, no bounce |
| Cause | Mailbox or domain missing | Full inbox, server down | Your IP, domain or content | Filter judged the message |
| Seen in your tool | Bounce | Bounce after retries | Bounce | Delivered |
| Retry? | Never | Yes, a few days | After you fix the setup | Not applicable |
| Fix | Suppress the address | Wait, then suppress | Fix DNS and sending practice | Improve targeting and copy |
The row that costs most is the first. Providers count permanent bounces against your sending reputation. RFC 5321 suggests a sender keep retrying a deferred message for at least four to five days before giving up (RFC 5321, September 2026). For the soft case in detail, read soft bounce email.
When it matters
Cold outbound to a purchased or old list
An old list bounces most. People change jobs and companies close, while the address in your file stays the same. Check the age of the data before you load it. Read the status per row, and drop invalid and disposable addresses outright.
Sending from a new domain
A new sending domain has no reputation. A few early bounces weigh heavily because providers have nothing else to judge you on. Send a small, verified batch first and raise the volume only while bounces stay low.
After a large pull from any data provider
A big export mixes strong and weak addresses. Split the file by email status before the first send. Send the verified group first and watch the bounce count.
When a campaign suddenly bounces
A jump in 5.7.x codes with no change in your list points at your setup. Check SPF, DKIM and DMARC records first. A jump in 5.1.1 points at the list.
How LeadOcean handles it
LeadOcean publishes email_status on every people search row, so you can split a list by risk before you send. The emailStatus filter takes the 13 values from GET /v1/enums/email_status (LeadOcean API enums, September 2026). They include verified, catch_all_valid, catch_all, risky, unknown, invalid and disposable.
By default, counts cover mailable people: verified, catch_all_valid and catch_all. Passing emailStatus replaces that default, so you pick the groups yourself. On 2026-10-01, leadocean_count_leads returned 4,726,035 people with emailStatus set to risky (worldwide, no other filters). That is a count of risky addresses, not a mailable count.
Sizing is free: send count=true as a query parameter with limit=1 (LeadOcean OpenAPI, September 2026). The calls below size the risky group for US VPs, then pull the verified group. Each person returned by the second call counts one record.
curl -X POST "https://api.leadocean.io/v1/people/search?count=true&limit=1" \
-H "x-api-key: $LEADOCEAN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"emailStatus": ["risky"], "jobLevel": ["VP"], "country": ["US"]}'
curl -X POST "https://api.leadocean.io/v1/people/search" \
-H "x-api-key: $LEADOCEAN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"emailStatus": ["verified"], "jobLevel": ["VP"], "country": ["US"], "limit": 25}'A status lowers your bounce risk. It does not remove it. LeadOcean gives no refund or credit for bounced emails, so read email_status before every send. The dataset is refreshed monthly and each record carries its own fetched_at date. The same filter works in the MCP server and in the Exports page of the app (app.leadocean.io), which shows the record price before you start.
For a step-by-step cleanup, follow how to cut your email bounce rate and bounce checker to bounce management. Pricing is two plans: Free (1,000 records, one-off, no card) and Pro at $499 a month. See pricing.
FAQ
What is the main reason B2B emails bounce?
Usually a mailbox that no longer exists. People change jobs, and the address stays in your file. We have not run a bounce test, so this page gives no rate.
Is a 550 error always a hard bounce?
Mostly yes, because 5xx is permanent by definition. The exception is a block. A 550 with a 5.7.x code points at your sending setup, not the contact. Read the dotted code before you delete anyone.
Do soft bounces hurt my sender reputation?
A single deferred message that later lands does not. Repeated soft bounces to the same address do. Suppress an address that keeps deferring after a few days of retries.
Can I stop all bounces?
No. Even a verified address can bounce if the person leaves the day before you send. You can cut them by filtering on emailStatus, splitting catch all addresses into a smaller batch and keeping your DNS records clean.
Where do I learn more about bounce rates?
Start with how to cut your email bounce rate. More guides live in the blog hub.
Filter your list by email status before the next send
Free to start. No credit card. 1,000 records to spend whenever you like.
Get your free API key →