Guides

Hard bounce vs soft bounce: what each one is telling you

Last updated 2026-09-07

A hard bounce is a refusal. The receiving server answered with a code starting 5, and your server gave up on that message. A soft bounce is a delay. The receiver answered with a code starting 4, and your server put the message back in its queue to try again later.

That's the distinction, and it's less useful than it sounds. What you actually need from a bounce is who owns the fix. Sometimes that's the recipient's admin, sometimes it's you, and the hard or soft label doesn't say which. The code does.

Does a soft bounce fix itself? Sometimes. If the receiver keeps saying 4xx, your server gives up after a few days and the final notice looks exactly like a hard bounce.

What to do with any bounce

1. Find the reply line. It starts with a three-digit code and usually carries a dotted status like 5.7.26 after it. Where to find the reason line in Gmail, Outlook and a raw notice.
2. Read the first digit. A 5 means the receiver refused and your server stopped. A 4 means it's still trying, or it tried for days and then stopped.
3. Read the middle digit of the dotted status. A 1 or 2 is about the recipient's address or mailbox. A 7 is about policy: authentication, reputation or content.
4. Match it in the table below. An address error goes to the person you wrote to. A policy error comes back to you.

Hard bounce: a 5xx reply and your server stops

The receiving server answered a command with a 5xx reply. RFC 5321 calls that a permanent negative completion. Your server takes it at its word and doesn't retry. It writes you a delivery status notification instead, with the receiver's reply quoted inside it.

Permanent means permanent for that message. Send it again unchanged and you get the same reply. Fix the cause first, whether that's the address or your DNS, and then send once.

Soft bounce: a 4xx reply and your server retries

The receiver answered 4xx. RFC 5321 calls that a transient negative completion, and your server treats it as an invitation to try later. Postfix keeps trying for five days by default. Gmail and Microsoft 365 run similar windows. Nothing may reach your inbox at all during that time, or you get a notice with the subject line Delay and the word delayed in the Action field.

Some 4xx replies clear on their own. A full mailbox gets emptied, a busy server comes back, greylisting lets the second attempt through. Others never clear, because the receiver is using 4xx as a polite no. Gmail's rate limit, 421-4.7.28, is the common one. Your server retries the same message into the same limit for days, then gives up and sends a failure notice.

So from where you sit, a soft bounce that never clears ends the same way as a hard bounce. The final notice says failed. The difference is that the original reply is buried under days of retries, and the code inside it is still the thing to read.

Hard and soft are your platform's words

The mail protocol has 4xx and 5xx. It doesn't have hard or soft. Those labels come from the sending platforms, the Mailchimps and SendGrids, which need a rule for when to stop sending to an address. Each one draws the line where it wants to. A 5xx spam block might count as soft on one platform, because the address itself is fine, and as hard on another.

That's why two platforms can disagree about the same address. It's also why the label in a dashboard isn't a diagnosis. When a platform tells you an address hard-bounced, open the bounce and read the code before you delete anyone.

The dotted status code says whose problem it is

Most replies carry a second code, three numbers with dots, from RFC 3463. The first number repeats the class, 4 or 5. The middle number is the one worth reading. It says what kind of thing went wrong.

Status	What it's about	Who fixes it
X.1.x	The address. It doesn't exist, or the domain has no mail server.	You, if it's a typo. Otherwise the recipient's admin.
X.2.x	The mailbox. Disabled, full, or over a limit.	The recipient or their admin.
X.3.x	The receiving system. Out of storage, or not accepting mail.	The receiving admin.
X.4.x	The network. Timeouts, routing, a connection the receiver dropped.	Usually clears. If it doesn't, one of the two admins.
X.5.x	The protocol. A command the receiver didn't accept.	Your server's admin.
X.6.x	The content. An attachment type or size.	You.
X.7.x	Policy. Authentication, reputation, spam filtering, a rule the recipient set.	Mostly you.

Two of those rows carry nearly all bounce traffic. The 1s and 2s are about the person you wrote to. The 7s are about you.

Bounces that mean the recipient is gone

These come back hard, and the fix is on the other end. Check the spelling, drop the address from any cached autocomplete, and ask the person another way. No DNS record on your side changes the answer.

• 550 5.1.1: the mailbox doesn't exist. Typo, or a person who left.
• 550 5.2.1: the mailbox exists and is disabled or inactive.
• 552 5.2.2 or 452 4.2.2: the mailbox is full. Wait, or call.
• 550 5.4.1: Microsoft's version of no such recipient, worded as access denied.

Bounces that mean your authentication is broken

These are the ones this site exists for. The address is fine. The receiver looked at who sent the message, checked it against the DNS records for your domain, and refused. Every message from that sending system to that receiver is failing the same way, whether or not you've seen the bounces yet.

• 550-5.7.26: Gmail found no SPF pass and no DKIM pass, or applied your DMARC reject.
• 550 5.7.1 naming DMARC: any receiver that enforced your own p=reject.
• 550 5.7.515: Microsoft refused a high-volume sender with no authentication.
• 550 5.7.509: Microsoft applied your DMARC policy.
• 550 5.7.23: Microsoft failed SPF for the connecting server.
• SPF permerror: your record needs more than 10 lookups, so SPF fails for everyone.

The fix is a DNS change, and it's the same change no matter which recipient bounced. Put the sending service in your SPF record, turn on its DKIM signing, and make sure the domain in the visible From matches one of them. Alignment is the part people get wrong. Then send one test message and read the reply before you send the rest.

Bounces that mean reputation or content

Also 5.7, also yours to fix, and harder. The authentication passed and the receiver still didn't want the message.

• 554 5.7.1: the receiver's spam filter rejected the message or the connecting IP.
• 421-4.7.28: Gmail is rate-limiting the sending IP or domain. Soft, and it stays soft until your volume or your spam rate drops.
• 550 5.7.350: Microsoft's content filter.

A blocklist listing lands here too. The reply usually says which list and gives a URL to look yourself up on. Fix what got you listed before asking to be removed, because a second listing is harder to clear than the first.

The bounces you never get

The worst case is silence. Most big receivers accept a message they distrust and then file it in spam or quarantine, because refusing it would tell a spammer what to change. You get nothing. The recipient gets nothing. Under your own DMARC p=quarantine, that's what your policy asked for.

The only sender-side view of that is the DMARC aggregate reports receivers send to the address in your record. They list each server that sent as your domain, whether it passed, and what the receiver did with it. Quarantine has its own page, and reading a report by hand shows the rows to look for. Our weekly digest reads those reports for you and lists every sender that failed, and on a paid plan we email you the day an unfamiliar one first fails. Your first domain is free.

DomainCanary is a DMARC monitoring service that turns your domain's aggregate reports into one weekly email.