Why Are My Emails Bouncing? A Diagnostic Walkthrough

A bounce report that's suddenly red usually has a single underlying cause, and the SMTP response code attached to each bounce tells you which one. Most senders look at the bounce-rate number, conclude "list quality is bad," and run a verification pass, which sometimes fixes it and sometimes doesn't, because the bounces weren't actually about list quality.

This is the diagnostic walkthrough. Pull your bounce report, look at the response codes, and trace the root cause. The fix at the end depends on what the codes are telling you, not on what your intuition says.

(If you want the broader "how do I reduce bounce rate over time" treatment with all 7 ranked fixes, that's a separate post: how to reduce email bounce rate. This post is the "my bounces look bad RIGHT NOW, what's the cause" diagnostic.)

01Step 1: get the SMTP codes from your bounce report

Every credible ESP exposes the per-bounce SMTP response code. The path varies:

• Mailchimp: Reports → Bounce report → click any row to see the SMTP code
• Klaviyo: Analytics → Reporting → Bounce report → click "View details"
• ActiveCampaign: Reports → Campaign report → Bounces tab → SMTP response visible per row
• SendGrid: Activity feed → filter for "Bounced" → expand for SMTP response
• Mailgun: Logs → filter for "failed" → details panel shows the full reply
• Postmark: Servers → Activity → click any bounce to see the full SMTP transaction

If your ESP doesn't expose SMTP codes (some don't surface them in the UI but include them in webhook payloads), check the webhook integration or the API export. The codes are always there at the protocol layer; getting at them is the question.

02Step 2: classify by code

The leading digit and the enhanced status code (the X.Y.Z part) tell you the bounce class.

4xx = soft bounce (temporary, may retry) 5xx = hard bounce (permanent)

Within 5xx, the enhanced status code narrows it further:

Now group your bounces by code. Most senders find one or two codes dominate. The dominant code tells you the root cause.

03Step 3: act on what the codes say

Four broad diagnoses based on what dominates the report:

Diagnosis A: dominated by 550 5.1.1, 550 5.1.2, 550 5.2.1

This is a list-quality problem. The receiving servers are telling you the mailboxes don't exist or have been disabled. Verification before sending is the fix.

The mechanism: an SMTP probe (the same protocol move the receiver did to bounce your message) would have returned the same 550 5.1.1 before you sent. Pre-send verification catches these addresses and lets you drop them.

Action:

1. Re-verify the entire list immediately (MailCull's Verify List or equivalent)
2. Drop everything marked undeliverable
3. Segment everything marked risky (catch-all, contradictory M365 signals): send to your highest-trust segment first to rebuild reputation
4. For future sends, verify any list older than 90 days or any newly-imported list before the first send

Expected reduction: 4-6% bounce rate to under 1%.

Diagnosis B: dominated by 550 5.7.1, 550 5.7.x, 554

This is a reputation or content problem. The receiving servers are accepting the recipient but rejecting your message specifically: they don't trust the sender or the content matched a spam pattern.

The mechanism: 5.7.x codes are the "we don't trust this sender" family. They fire when your IP / domain / authentication doesn't pass the receiver's bar.

Action:

1. Check your SPF / DKIM / DMARC are all set up and passing: see SPF / DKIM / DMARC setup guide. Most reputation rejections trace back to incomplete authentication.
2. Check Google Postmaster Tools and Microsoft SNDS for your sender reputation. If either shows "low" or "bad," you have a multi-week recovery ahead.
3. Audit recent content for spam triggers: heavy image-to-text ratio, link-only messages, suspicious link shorteners (bit.ly, ow.ly), all-caps subject lines, multiple exclamation marks.
4. If you're sending from a new domain or IP, you may need to slow down and warm up. Abrupt volume increases trip reputation systems.

Re-verification won't help here. The addresses are fine; the sender is the problem.

Diagnosis C: dominated by 550 5.4.1 on Microsoft 365 corporate domains

This is the EOP rate-limiting problem. Microsoft's Exchange Online Protection is throttling your probe source. Specifically common for: senders using shared IPs that EOP doesn't recognize, senders new to a corporate-heavy domain mix, or campaigns sent in rapid succession to large M365 segments.

The mechanism: EOP doesn't trust unfamiliar probe IPs and 550 5.4.1s them as an anti-abuse measure, even when the underlying mailbox exists. Recovery is slow.

Action:

1. If using a shared sending IP, ask your ESP to investigate the IP's M365 reputation. May need to migrate to a different IP pool.
2. If you have a dedicated IP, warm it up against M365 specifically: slow ramp over 2-4 weeks, segmenting your largest M365 tenants for last.
3. Send to your most-engaged subscribers first; engagement signals are what rebuild EOP trust.
4. Recognize that some of the 5.4.1s are NOT bounces in the address-quality sense: the addresses are real, the messages would deliver from a different source. Don't suppress them aggressively or you'll lose real subscribers.

Verification helps somewhat (you'll see some risky M365 cascade results that hint at the issue), but the underlying fix is sender-side, not list-side.

Diagnosis D: dominated by 4xx codes

This is usually transient and recovers on retry. Most ESPs retry soft bounces automatically for 24-72 hours before escalating to hard.

Action:

• Check whether your ESP's retry policy is reasonable (usually yes, by default)
• If 4xx rate is unusually high (above 2-3%), look at WHICH receiving domains are deferring. Concentrated 4xx from a single domain often means that one domain is greylisting you (anti-spam), which usually resolves on retry
• If the deferrals come from many domains evenly, the issue is more likely on your sending side (rate limiting hitting your account's per-server send caps)

Often these resolve themselves without intervention. Watch the retry results before treating soft bounces as a real problem.

04Step 4: confirm the fix

After acting on the diagnosis:

1. Send a small test campaign: 100-500 addresses, ideally to your most-engaged segment
2. Check the bounce report on the test send: should be under 1%
3. If bounce rate stays high on the test, the diagnosis was wrong or incomplete. Re-pull the codes and re-classify.
4. If bounce rate drops on the test, scale back to normal volume gradually (don't immediately blast the full list).

This confirmation step matters because some senders run a verification pass, assume the problem is fixed, and immediately mail the full list, sometimes discovering the actual problem was authentication, not list quality, only after the next campaign also bounces.

05The five mistakes to avoid

Quick anti-patterns I see often:

1. Skipping the SMTP code lookup. Treating bounce rate as a single number with a single cause. The codes are the diagnostic; reading them takes 5 minutes and saves wasted intervention.
2. Re-verifying when the codes say reputation/auth. A verification pass on a list that's not the problem won't fix anything and burns credits.
3. Mailing immediately after the fix without a test send. Discovering the fix didn't work via another bad campaign is expensive.
4. Suppressing 5.4.1 EOP rate-limit "bounces" as hard bounces. These are often real addresses being rate-limited. Suppressing them loses real subscribers.
5. Conflating soft and hard bounces in the rate calc. Most ESPs report a single bounce rate that includes both; the soft rate usually self-resolves, so the hard-bounce rate is the actionable signal.

06What MailCull does on the bounce-cause front

Every verification we run surfaces the SMTP reply text in the evidence chain: the exact response the receiving server would give to a real send. If your bounce report shows 550 5.1.1 on a set of addresses, you can run those same addresses through MailCull pre-send and confirm the verdict matches (it will, with the same smtp_rejected flag). The pre-send check is faster, cheaper, and won't damage your sender reputation the way an actual send will.

Start free: 500 credits/month, no credit card. Run your bounced segment through Verify List and see the SMTP replies for each row. If the codes match what you saw post-send, you've confirmed the list-quality diagnosis and can act on it. If they don't, the bounces aren't about the addresses. Look at authentication or sender reputation instead.

To see all five deliverability signals for your domain at once (MX, SPF, DKIM, DMARC, and blacklist status), run the free deliverability scan.