Hard bounce vs soft bounce: what to do with a failed email
Read the actual delivery error, distinguish temporary failures from permanent or policy blocks, and decide whether to wait, correct, or stop sending.
In this guide
A hard bounce is a delivery failure your sending service treats as permanent. A soft bounce is usually temporary, such as a mailbox being full or a receiving server being unavailable.
But those two labels are only the start. Read the actual error before resending or removing anyone. A permanent policy block is not proof that the person’s address is wrong, and a temporary failure is not a reason to send the same message repeatedly yourself.
This guide is for a website owner checking an existing, legitimate email—not for testing random addresses or reviving unsubscribed contacts.
Find the full delivery error
Open your sending provider’s report or transactional delivery log, select the failed message, and read the reason, timestamp, and status code. In a mailbox bounce notice, expand the diagnostic details rather than relying only on the subject “Delivery failed.”
Look for the recipient and the specific attempt you intended to check. A delayed report from yesterday can describe a different message. If you share an error with support, remove recipient addresses, message bodies, and account credentials first.
SMTP replies beginning with 4 usually indicate a temporary failure; those beginning with 5 indicate a permanent failure for that attempt. Enhanced status codes such as 4.2.2 or 5.1.1 add more detail. Your provider’s hard/soft label may also depend on its retry and suppression policies.
Choose the action from the reason
These are illustrative error patterns; the full text and your provider’s interpretation still matter.
| Error or reason | What it suggests | Sensible next action |
|---|---|---|
5.1.1 — destination mailbox does not exist | Address is invalid or mailbox was removed | Stop sending; confirm the address through an existing legitimate contact channel |
4.2.2 — mailbox full | Recipient may need to clear space | Let the provider follow its retry policy; avoid manual duplicate sends |
4.4.1 — no answer from destination host | Receiving system could not be reached | Check the provider's queued/retry status and wait within its documented window |
5.7.1 — delivery not authorized / policy rejection | Authentication, reputation, or recipient policy may block the message | Read the diagnostic and check sender configuration; do not assume a typo |
“Permanent” describes the response to that delivery attempt. A configuration problem may later be repaired, but repeating the unchanged message is not the repair.
For a hard bounce, preserve the sending block
Many providers put a hard-bounced address on a suppression list: a list that prevents future sends to that address. Brevo, for example, describes automatically blocklisting hard bounces.
Do not remove the block just to try again. First establish the cause:
- Confirmed typo in an address you are authorized to use: obtain the correct address from the person. Do not invent likely alternatives and send to them.
- Mailbox no longer exists: stop using it. Deleting a customer record from your business system is a separate decision; suppression does not require erasing your history.
- Sender-policy rejection: check the provider’s diagnostic and support guidance. If it identifies SPF, DKIM, or DMARC, use the authentication guide to understand the checks before changing records.
An unsubscribe or spam complaint is a different kind of sending restriction. Correcting a technical issue never overrides that person’s choice. Keep those restrictions in place.
For a soft bounce, check whether a retry is already queued
Your provider may retry automatically. Find its current message status before creating another send. There is no universal “retry after ten minutes” rule for every service.
If the temporary condition clears, inspect the final delivery status. If attempts eventually expire or repeat failures cause the provider to suppress the address, follow its documented policy rather than resetting the contact repeatedly.
For an important service message, use another already authorized channel if appropriate. Do not add the recipient to a marketing list to work around a failed transactional email.
Verify a resolution without creating more noise
After the actual cause is corrected, follow your provider’s documented recovery procedure. If a controlled test is necessary, use an address you own or a recipient who has agreed to that test. Check the delivery record and actual receipt.
“Delivered” normally means the receiving system accepted the message. It does not guarantee that it appeared in the inbox instead of Spam. “Opened” is not a reliable substitute for asking whether a specific permissioned test arrived.
If the diagnostic is unclear, send the provider a sanitized copy of the code and reason, plus the attempt time or internal message ID. Ask which condition must change before another send. A new email provider is not the first fix for one unexplained bounce.
Sources and useful links
- RFC 3463: enhanced status codes — explains temporary and permanent status classes and detailed reasons.
- RFC 5321: SMTP — reference for SMTP replies and retry behavior.
- Brevo’s bounce explanations — illustrates how a sending provider labels failures and suppresses hard-bounced addresses.