# Hard Bounce vs Soft Bounce — Reading the Bounce Log

> A hard bounce is permanent; a soft bounce is temporary. AcelleMail records them in the campaign bounce log and treats them differently — hard bounces blacklist the address, soft bounces are left alone for the receiving server to retry. This guide walks the bounce log, the DSN codes, and what each type means for your list.

- Canonical URL: https://acellesend.com/kb/articles/understanding-email-bounce-types
- Author: Lena Hart, Email Deliverability Editor
- Category: Sending & Deliverability — SMTP setup, bounce handling, sender reputation, IP warmup, throttling
- Content type: tutorial · Difficulty: beginner
- Tags: Acellemail
- Published: 2026-05-24 · Last updated: 2026-08-15
- Reading time: 9 min
- Publisher: AcelleMail Knowledge Base, https://acellesend.com/kb

---

## What this is for

Some of the emails you send come back. The receiving mail server rejects them and sends a little notice — a *bounce* — explaining why. AcelleMail collects those notices in a **Bounce log** on every campaign report.

This article shows you how to read that log, tells the difference between a **hard bounce** (permanent — the address is dead) and a **soft bounce** (temporary — try again later), and explains exactly what AcelleMail does on its own when each one comes back.

## The two categories of bounce

Every bounce carries a status code from the receiving server. The first digit is all you need to tell the two categories apart:

**Hard bounce — codes that start with 5 (5.x.x)**
A permanent failure. The address doesn't exist, the domain doesn't exist, or the message was rejected outright. Sending again won't help. AcelleMail **blacklists** the address (more on that below) so you stop wasting sends on it.

**Soft bounce — codes that start with 4 (4.x.x)**
A temporary failure. The mailbox is full, the server is busy, or you've been greylisted. The receiving server usually accepts the message on a later attempt. AcelleMail records the soft bounce but **takes no action on the address** — it leaves the retrying to the sending server, which is where retries belong.

That single rule — first digit 5 = permanent, first digit 4 = temporary — is how AcelleMail itself classifies every bounce it processes. If a bounce notice has no readable status code, AcelleMail files it as **unknown**.

## Open the bounce log

From a campaign report, open the **Sending logs** menu in the report nav and choose **Bounce log**.

![Campaign bounce log showing recipient, bounce type, reason and date columns](https://acellesend.com/plugins/acelle/landing/images/help/kb/campaign-delivery/02-campaign-bounce-log.png)

At the top you'll see a one-line reminder: *"Emails that bounced back — hard or soft bounces from recipient servers."* Each row has four columns:

- **Recipient** — the subscriber that bounced. Click the email to jump straight to that subscriber's detail page.
- **Bounce type** — a small badge reading **hard**, **soft**, or **unknown** (the value AcelleMail classified the bounce as). All three use the same badge style — the text is what matters, not the colour.
- **Reason** — the receiving server's response. When the bounce notice carries a clean status line, you'll see the code right up front (e.g. `550 5.1.1 The email account that you tried to reach does not exist`). Click the text to read the full message if it's truncated.
- **Date** — how long ago the bounce was recorded.

There's a search box above the table — type a recipient address to filter the log down. Most bounces explain themselves: the reason text tells you what happened in plain language right after the code.

## Common DSN codes and what they mean

The codes in the Reason column are **DSN** (Delivery Status Notification) codes. Here are the ones you'll see most often.

### Hard bounces (5.x.x — permanent)

| Code | What it means | What it tells you |
|---|---|---|
| **5.1.1** | The mailbox doesn't exist | Typo at signup or a deleted account. The single most common hard bounce. |
| **5.1.2** | The domain has no DNS / no MX records | The whole domain is dead — usually a mistyped domain at signup. |
| **5.2.1** | Mailbox disabled or unavailable | The mailbox was turned off or suspended. |
| **5.7.1** | Message rejected (often by a spam/content filter or as unauthenticated) | Frequently a *your-side* problem — check your authentication, not the recipient. |
| **5.7.x** | Other security/authorization failures | Usually points at SPF/DKIM/DMARC or an IP block. Investigate before bulk-deleting addresses. |

### Soft bounces (4.x.x — temporary)

| Code | What it means | What it tells you |
|---|---|---|
| **4.2.2** | Mailbox over quota / full | The recipient's inbox is full right now. May clear up, may not. |
| **4.3.x** | Receiving mail system problem | The receiver is having trouble — out of your hands. |
| **4.4.1** | Connection timeout | The receiving server was slow or overloaded at that moment. |
| **4.7.0 / 4.7.1** | Greylisted / rate-limited / "try again later" | A common anti-spam tactic — the receiver defers your first attempt on purpose and accepts the retry. Usually clears on its own. |

A code starting with **5** that mentions authentication or spam filtering (the 5.7.x family) is the one to slow down on. Those bounces are very often about *your* setup — broken DKIM, an SPF mismatch, or a damaged sending reputation — not a bad recipient address. If you see 5.7.x across many recipients at once, that's a deliverability problem to fix, not a list to clean.

## Reading real rows

Look at the rows in the screenshot above and you can read each one like a sentence — the **type** badge tells you permanent vs temporary, the **reason** tells you the specific cause:

- `moorevanessa@navarro.com` — **hard**, `550 5.1.1 The email account that you tried to reach does not exist`. A dead mailbox. AcelleMail has already blacklisted it.
- `clayton61@molina.info` — **soft**, `552 5.2.2 The email account that you tried to reach is over quota`. The inbox is full right now. AcelleMail recorded it and left it alone; the receiving server can deliver on a retry.
- `conleyricky@day.com` — **hard**, `550 5.7.1 Message rejected as spam by Content Filtering`. This one's worth investigating on your side before assuming the address is bad.
- `mindy49@hodges.com` — **soft**, `451 4.7.0 Recipient server is rate-limiting your IP. Retry recommended`. The receiver is deferring you on purpose — normal, no action needed.
- `damon34@taylor.com` — **hard**, `550 5.1.2 The domain has no DNS / no MX records`. A dead domain — likely a typo when the contact signed up.
- `dustin40@reeves.biz` — **hard**, `550 5.7.7 Message failed DMARC alignment for the From: domain`. An authentication problem on your side, not a bad address.

The pattern is always the same: the badge gives you the category, the reason gives you the cause. Read both.

## What AcelleMail does automatically

| What bounced | What AcelleMail does |
|---|---|
| **Hard bounce (5.x.x)** | Records a bounce log row, sets the subscriber's status to **Blacklisted**, and adds the email to your **Blacklist** so future campaigns skip it everywhere. |
| **Soft bounce (4.x.x)** | Records a bounce log row only. **No change to the subscriber** — the receiving/sending server handles any retry. |
| **Bounce with no readable code** | Recorded as type **unknown**. No subscriber change. |
| **Spam complaint** (a separate signal, not a bounce) | Sets the subscriber's status to **Spam-reported** so future campaigns skip them. This comes from a feedback loop, not the bounce log — see the Feedback log and the article linked below. |

There is **no "bounced" status** in AcelleMail and no built-in soft-bounce retry queue. A hard bounce flips the subscriber to **Blacklisted** — that's the status you'll see on the subscriber and in your blacklisted count. Soft bounces are recorded for your visibility and nothing more.

> **Why blacklist instead of just unsubscribe?** A hard bounce means the address is dead globally, not just unhappy with one list. Blacklisting suppresses it across all your lists at once, which is what protects your sending reputation.

## Common issues and what to do

| What you see | What to do |
|---|---|
| **5.1.1 spikes on the first send to a freshly imported list** | The import source is bad (often a purchased or very old list). Stop sending, run **Email verification** on the list, and only keep verified addresses. |
| **5.7.1 across most of a campaign** | This is your side. Check your sending domain's DKIM/SPF — open **Sending domains** and confirm the DNS records verify. |
| **5.7.x to one specific recipient domain only** | That one receiver is blocking you. Investigate that domain specifically rather than cleaning the whole list. |
| **4.7.0 / 4.7.1 (greylisted / rate-limited) on a chunk of sends** | Normal. The receivers are deferring you on purpose; the retry generally succeeds. No action needed. |
| **4.2.2 (over quota) creeping up over time** | Stale list with abandoned mailboxes. Clean it periodically — see the list-hygiene article below. |
| **A hard bounce on someone who normally opens your emails** | Probably a temporary glitch (DNS hiccup, locked account that recovered). If they re-engage, you can remove them from the Blacklist — see below. |

## When an address was blacklisted by mistake

Because a hard bounce blacklists globally, the way to undo it is to remove the address from your **Blacklist**, not to "un-bounce" it:

1. Open **Blacklist** from the sidebar (under the Sending section).
2. Find the address and remove it.
3. Only do this when you have a genuine reason to believe the mailbox is live again (the person re-confirmed, or replied asking to keep getting your emails).

Don't bulk-remove blacklisted addresses without that evidence. Re-sending to addresses that already bounced hard is exactly the behavior that damages your reputation with receiving servers — the damage compounds with each campaign.

## DSN codes, decoded

If you want to read codes you don't recognize, every DSN code has the same three-part shape:

```
X . Y . Z
│   │   │
│   │   └─ Detail — the specific status (e.g. 1 = mailbox doesn't exist)
│   └───── Subject — the status class (e.g. 7 = security/policy)
└───────── Class — 5 = permanent, 4 = temporary, 2 = success
```

The **Subject** digit (the middle one) groups the cause:

| Middle digit | Status class |
|---|---|
| 1 | Addressing — bad mailbox or address |
| 2 | Mailbox status — exists but can't accept right now |
| 3 | Mail system — the receiving server itself |
| 4 | Network/connection |
| 5 | Mail protocol (SMTP-level) |
| 6 | Message content (body/MIME) |
| 7 | Security — authentication or policy block |

So `5.1.1` reads as *permanent · addressing · bad mailbox* — a dead address. `4.7.0` reads as *temporary · security · policy* — typically greylisting or rate-limiting. The code tells you the category; the reason text next to it tells you the specifics. Read both.

## What to do after

- If hard bounces are high on a list, run [Email list hygiene](https://acellesend.com/kb/articles/email-list-hygiene-clean-your-list-for-better-deliverability) and verify the list before your next campaign.
- If you're seeing 5.7.x or authentication-flavored bounces, work through the [delivery diagnostic checklist](https://acellesend.com/kb/articles/debugging-common-email-delivery-issues).
- Want the full code-by-code reference? See [Decoding bounce messages](https://acellesend.com/kb/articles/decoding-smtp-error-codes-and-bounce-messages).

## Related articles

- [Decoding SMTP error codes and bounce messages](https://acellesend.com/kb/articles/decoding-smtp-error-codes-and-bounce-messages)
- [Email delivery issues — diagnostic checklist](https://acellesend.com/kb/articles/debugging-common-email-delivery-issues)
- [Sender reputation monitoring](https://acellesend.com/kb/articles/sender-reputation-monitoring)
- [Email list hygiene — clean your list for better deliverability](https://acellesend.com/kb/articles/email-list-hygiene-clean-your-list-for-better-deliverability)
- [Feedback loops (FBL) setup](https://acellesend.com/kb/articles/feedback-loops-fbl-setup)

---

## Related articles

- [Feedback Loops (FBL) — Setup + Wire in AcelleMail](https://acellesend.com/kb/articles/feedback-loops-fbl-setup): When a recipient clicks "Mark as Spam" on a Microsoft / Yahoo / AOL / Comcast mailbox, those ISPs send you the complaint via Feedback Loop. AcelleMail processes it automatically — unsubscribes the complainer, updates the complaint stats. This guide walks the setup.
- [How to Set Up Amazon SES with AcelleMail](https://acellesend.com/kb/articles/configuring-amazon-ses-with-acellemail): Create an IAM user and access key in AWS, connect Amazon SES to AcelleMail, share your verified domains with users, and let them verify their own.
- [Amazon SES Sending Limits — Cookbook for AcelleMail Operators](https://acellesend.com/kb/articles/ses-sending-limits-cookbook): SES starts at 200/day sandbox, scales to 50k+/day in production, $0.10 per 1,000 emails. This guide is the practical cookbook: how to grow from sandbox to scale, region-by-region orchestration, what AcelleMail does at each tier.
- [Multiple Sending Servers in AcelleMail — Add, Mix, Route](https://acellesend.com/kb/articles/configuring-multiple-sending-servers): Spread your volume across several SMTP and API senders for failover, reputation isolation, and headroom past any single vendor's cap. This guide walks the real screens: the type picker, the connect form, the per-campaign "Use all servers" toggle, and the admin pool view.
- [IP Warmup Schedule — Ramping a New Sending Server in AcelleMail](https://acellesend.com/kb/articles/ip-warmup-schedule-for-new-sending-servers): A fresh sending IP has zero reputation. Send 50,000 emails on day one and every major mailbox provider routes you to spam. AcelleMail's Warmup Strategies grow your volume gradually using one of three presets. This guide walks the admin UI plus a realistic ramp plan.