Email Bounces Explained: Hard vs. Soft Bounces and What to Do
An email bounce means the receiving system did not accept or could not deliver a message. The useful question is not simply “Did it bounce?” but “Was the failure permanent, temporary, recipient-specific, domain-wide, or caused by the sender?”
Understanding that difference prevents two costly mistakes: repeatedly retrying an address that will never work and permanently removing an address because of a short-lived server problem.
Hard bounces are permanent failures
A hard bounce indicates that retrying the same message to the same destination is unlikely to succeed.
Common causes include:
- the mailbox does not exist
- the domain does not exist or has no mail service
- the address is malformed
- the receiving server permanently rejects the sender or message by policy
SMTP responses in the 5xx family generally represent permanent failures, but the enhanced status code and response text matter. A permanent policy rejection and a nonexistent mailbox require different operational fixes even though both are hard failures.
Sendrealm can suppress addresses after a hard bounce so future attempts do not repeatedly send into the same permanent failure.
Soft bounces and delays are temporary
A soft bounce or delivery delay indicates a condition that may resolve.
Examples include:
- a full mailbox
- temporary server unavailability
- rate limiting or greylisting
- a message that exceeds a recipient limit
- a transient DNS or network problem
- sender reputation controls that defer rather than reject
SMTP 4xx responses generally mean temporary failure. Delivery systems may retry them according to a bounded schedule. More retries are not always better: if the receiver keeps deferring traffic, aggressive retrying can make the problem worse.
The hard/soft label is only the first layer
Classify bounces along three additional dimensions.
Recipient-specific or domain-wide?
If one address fails while others at the same domain deliver, inspect the mailbox. If many addresses at one domain fail together, investigate that domain's server response, rate limits, and sender reputation.
Content-specific or sender-wide?
A message-size or content-policy failure may affect one template. An authentication or reputation problem may affect every message from a domain.
New or recurring?
A one-time delay during a provider outage is different from a recurring pattern after every campaign. Repetition changes the appropriate response.
What bounce rate can and cannot tell you
Bounce rate is usually calculated as bounced recipients divided by attempted or sent recipients for a defined period. Always confirm the denominator used by the reporting system before comparing platforms.
A higher rate can indicate:
- a stale or purchased list
- form-entry errors
- a migration that lost suppression history
- a sudden change in sending domain or infrastructure
- recipient-provider blocking
- a campaign sent to a long-inactive cohort
The overall rate can hide concentration. Segment by acquisition source, import date, recipient domain, campaign, and message type.
How to investigate a bounce in Sendrealm
- Open Messages → Emails.
- Select the message and recipient.
- Read the event timeline in order.
- Capture the bounce or failure explanation.
- Check whether the address is now suppressed.
- Compare with other recipients from the same source and domain.
Do not reallow a suppressed address merely because a customer wants another attempt. First confirm the address is correct and the original cause no longer applies. A complaint should not be overridden without clear evidence that reallowing is appropriate.
Recommended actions by failure type
| Signal | Likely meaning | Recommended action |
|---|---|---|
| Mailbox does not exist | Permanent recipient failure | Correct the address or stop sending |
| Domain does not resolve | Permanent or configuration failure | Verify the domain before retrying |
| Mailbox full | Temporary recipient condition | Allow bounded provider retry; monitor recurrence |
| Rate limited | Receiver is slowing traffic | Reduce rate and increase gradually |
| Message too large | Content-specific rejection | Reduce HTML and attachment size |
| SPF, DKIM, or DMARC rejection | Authentication or alignment problem | Fix DNS and sender alignment |
| Policy or reputation block | Sender/content issue | Review response, reputation, consent, and content |
| Suppressed before send | Prior hard bounce or complaint | Inspect suppression history; do not loop retries |
Prevent bounces before they happen
Validate at acquisition
Catch obvious syntax errors at the form, but do not treat format validation as proof that a mailbox exists or that the person consented.
Use confirmed opt-in where appropriate
Confirmation prevents many typos, bots, and malicious subscriptions from entering a marketing list. It also establishes a clearer expectation with the recipient.
Preserve suppression during migrations
Do not import only active-looking contacts and leave historical bounces behind. A migration that forgets suppression can resend to addresses the previous provider already proved invalid.
Start with engaged recipients
When launching a new sending domain or moving providers, begin with recent, permission-based recipients. Sudden volume to a stale database creates both bounce and complaint risk.
Keep messages reasonably sized
Large HTML bodies and attachments can hit recipient limits, slow processing, and complicate rendering. Link to authenticated downloads when sending a large file is unnecessary.
Authenticate the domain
SPF, DKIM, and DMARC do not eliminate bounces, but they prevent avoidable authentication failures and make sender identity clearer to receiving systems.
What not to do
- do not repeatedly retry permanent failures
- do not delete bounce evidence before understanding the source
- do not reimport a suppressed address as a workaround
- do not blame content for a list-quality problem without segmenting the data
- do not treat a temporary delay as a confirmed hard bounce
- do not assume a valid-looking address belongs to a consenting recipient
Turn bounce handling into a feedback loop
A healthy process connects the event back to its source. If a form produces typos, improve the form. If one imported list produces hard bounces, quarantine that source. If a recipient domain defers a sudden volume spike, adjust the ramp. If authentication fails, fix the sending configuration before resuming.
Sendrealm provides recipient events and suppression history so the team can stop guessing and take the action that fits the actual failure.
Learn how Sendrealm suppression lists protect deliverability.