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.

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

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.comhard, 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.infosoft, 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.comhard, 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.comsoft, 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.comhard, 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.bizhard, 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

Related articles

12 comments

8 comments

  1. femi.adeyemi
    Does engagement-based segmentation help during warmup? E.g. only sending to the most-engaged 20% during week 1?
    1. admin
      suppression list import via csv captures all opt-outs including preference-center ones if you exported with the right field set. the export filter defaults exclude some — check the 'include unsubscribed' checkbox on mailchimps export wizard.
  2. sobrien.kw
    For very low-volume senders (< 5k/month), does warmup even matter? Or just send and let the provider's shared pool absorb the trickle? anyway
    1. admin
      That config is exposed in 5.2+. For older versions you'll need to edit the config file directly. We'll add a version-matrix in the article...
  3. lucas.bernard.…
    Bookmarked. Going to share with the team — we've been winging warmup and it shows in the numbers. 👀
  4. tranminh.devop…
    Confirming the Postmaster Tools data lag — sometimes 48 hours, sometimes longer. Don't make decisions on a single day's data
    1. admin
      thanks for the detail — adding the kernel-reboot edge case to the article on the next update.
  5. phuong.mai.hn
    If you're warming a new IP after a known issue, consider seeding with transactional mail first (password resets, order confirmations). Higher engagement rate per send than marketing — helps the reputation ramp. 👀
  6. emma.whitaker
    we warmed up a dedicated ip last fall. the 2-week ramp this article describes is on the aggressive side — gmail in particular punishes anything faster than ~3-4 weeks. we did 4 weeks and had a clean ramp...
  7. nadia.r.cl
    this is the clearest IP warmup schedule I've found. The volume table at the top is what I'm referencing daily.
  8. sofia.costa.pt
    We hit a Spamhaus listing once. Self-service delisting was actually fast (< 24h) but the reputation recovery took weeks. Not the listing itself that hurt — the user complaints that caused it.
    1. admin (edited)
      Thanks for sharing. The pattern you describe is exactly the use case we built that feature for — glad it landed for you.

More in Sending & Deliverability