Why do emails bounce? 9 real causes and how to fix each

• Most common cause? Invalid recipient address — accounts for roughly 60% of hard bounces in cold-outreach lists.
• Cheapest fix? Pre-send verification on the entire list.
• Hardest cause to diagnose? Receiving-side spam filtering that returns a 5xx code instead of routing to the spam folder — looks like a hard bounce, isn't.

A bounce is a delivery failure notification. When you send mail through SMTP, the receiving server either accepts the message (250 OK) or rejects it with a numeric code. The first digit of that code tells you everything:

• 2xx — Success. Mail accepted.
• 4xx — Temporary failure. Soft bounce. Retry usually works.
• 5xx — Permanent failure. Hard bounce. Don't retry.

Your ESP translates the code into a friendly category and (usually) emails you a Delivery Status Notification. The full breakdown of the soft/hard distinction is in the dedicated post on soft bounce vs hard bounce.

This is the single most common reason for hard bounces. The mailbox was never created, or the user closed the account, or the address was a typo from a manual entry. The receiving server returns 550 5.1.1 User unknown or similar.

Fix. Run pre-send verification. The free user.cleaning verifier catches non-existent addresses in 1–3 seconds via a non-sending SMTP probe. For lists, run the full file through the bulk verifier before any major campaign.

This single fix typically eliminates 60–80% of bounce volume on neglected lists.

The mailbox might or might not have ever existed — but if the domain has no MX record (or doesn't resolve at all), the mail can't be delivered. The bounce comes back as 550 5.1.2 Domain not found or DNS resolution failure.

Fix. Verifiers check MX records as part of their standard flow. The address is rejected before SMTP probe is even attempted. Same fix as above; verification catches both at the same step.

A real, valid mailbox that has hit its storage quota. The server returns 552 5.2.2 Mailbox full (hard) or 452 4.2.2 Insufficient storage (soft, depending on server). Most return soft on the first attempt and convert to hard if the mailbox stays full across retries.

Fix. This is mostly outside your control. The mailbox owner needs to clear space or the account is abandoned. After 3–5 consecutive bounces, suppress the address — an inbox that stays full for weeks is functionally dead.

The mailbox exists and accepts mail in general — but the server has decided your specific sender isn't welcome. This shows up as 550 5.7.1 Message rejected with text varying by ISP. Common subcauses:

• Your IP or domain is on a blocklist (Spamhaus, SORBS, Barracuda)
• Your authentication is failing (SPF, DKIM, or DMARC misalignment)
• Your sending volume spiked unnaturally
• Your message content tripped a content filter

This is the trickiest bounce to diagnose because the address is real and the rejection is sender-specific. Check your domain at MXToolbox blocklist lookup and your authentication at DMARC Analyzer.

Fix. Resolve authentication first (SPF, DKIM, DMARC must all align). Petition removal from any blocklists you find. Reduce send volume and warm up gradually if you spiked.

Some receiving servers temporarily reject the first attempt from any unknown sender, expecting that legitimate senders will retry while spammers won't. The bounce code is 4xx, soft, and the message usually delivers on retry within a few minutes.

Fix. Nothing on your side. Your ESP retries automatically and the message gets through. Greylisting is invisible from the sender dashboard for any well-configured ESP.

Large attachments, oversized HTML emails, or embedded base64 images can push a single message past the recipient server's per-message cap (often 25–35 MB). The bounce is 552 5.3.4 Message too big.

Fix. Strip attachments above 5 MB. Host large files externally and link to them. Compress images before embedding. For transactional mail with attachments, send a download link instead of the file itself.

Receiving servers limit how much mail they'll accept from a single sender per minute or per hour. Exceed the limit and you get 421 4.7.0 Try again later (soft). Common when sending high volume from a new IP or after a sudden volume spike.

Fix. Slow down. Most ESPs handle rate limiting transparently with retry queues. If you're sending raw SMTP, implement exponential backoff. Long term, warm up new IPs gradually — 50 messages on day 1, 100 on day 2, doubling weekly until you hit your target volume.

A spam trap is an address that exists solely to catch senders who buy lists or scrape addresses. ISPs and blocklist operators plant traps in honeypots and recycled-but-monitored mailboxes. Hitting one usually doesn't generate a bounce — it generates a blocklist entry that causes future mail to bounce or filter.

Fix. Stop sending to lists you didn't build through opt-in. Run lists through verification (most spam traps are flagged as risky or invalid). Monitor your sender score on Sender Score for sudden drops.

A practitioner on r/emailmarketing posted a thread about hitting recycled spam traps after sending to a B2B list bought from a data vendor. The bounce rate was 4%, but the deliverability damage from the trap hits was permanent until they migrated to a new sending domain.

The address is valid, your authentication is correct, your message is fine — but your domain or IP reputation has degraded enough that receiving servers reject mail wholesale. This usually shows up as 554 5.7.1 rejections across multiple recipients on the same domain.

Fix. This is a deliverability emergency, not a list problem. Pause sending. Audit your bounce rate and complaint rate over the last 30 days. If either is above safe thresholds, run the full list through verification, suppress everything risky, and resume sending at low volume to your most-engaged segment only. If reputation doesn't recover within two weeks, consider a deliverability consultant.

Action checklist when bounce rate jumps above your baseline:

1. Check the bounce-code distribution — is it mostly 5xx or mostly 4xx?
2. Group bounces by recipient domain — is it concentrated on one ISP?
3. Inspect a sample bounce message for the rejection reason text.
4. Check your domain on MXToolbox blocklist lookup.
5. Verify SPF, DKIM, and DMARC alignment with DMARC Analyzer.
6. Compare the bounce-rate spike to recent list-acquisition activity (new lead source, imported list, paid campaign).

If the spike traces to invalid addresses, the fix is verification. If it traces to authentication or blocklists, the fix is technical infrastructure. If it traces to specific recipient ISPs while others are clean, the fix is reputation rehabilitation.

Five practices, in order of impact:

1. Verify every address at signup with a real-time API call before account creation.
2. Re-verify the full list every 60–90 days — list decay is roughly 22% per year on consumer lists.
3. Implement double opt-in for marketing lists — eliminates typos and confirms the address is monitored.
4. Authenticate properly — SPF, DKIM, DMARC are now mandatory for senders >5,000 messages per day to Gmail or Yahoo, per the 2024 Gmail/Yahoo bulk sender requirements.
5. Monitor bounce rate weekly and act before it crosses 2%.

The first practice alone — pre-send verification — typically pays for itself within the first cleaning cycle on any list older than six months.