Email Bounce Handling: Hard vs Soft Bounces

Every email program produces bounces. Some addresses no longer exist, some mailboxes are full and some receiving servers turn messages away for policy reasons. What separates healthy senders from struggling ones is email bounce handling: reading each bounce, deciding what it means and acting on it quickly so that you stop mailing addresses that will never accept your messages. This guide explains the difference between hard and soft bounces, how to read the codes, how to process bounce notifications automatically and how to keep your CRM and sending tools in agreement about who should no longer receive mail.

What a bounce actually tells you

A bounce is a delivery status notification sent back when a message cannot be delivered. It usually includes a three-part enhanced status code alongside the older SMTP reply code. RFC 3463, which defines these enhanced codes, gives the first digit a broad meaning: 2 for success, 4 for a persistent transient failure and 5 for a permanent failure (RFC 3463).

The RFC describes a persistent transient failure as one where the message as sent is valid, but some temporary condition has caused delay or abandonment, so sending in the future may succeed. A permanent failure is one that is not likely to be resolved by resending the message in its current form.

That distinction is the basis of every bounce handling rule.

Hard and soft bounces

In everyday terms:

• Hard bounces are permanent. The address does not exist, the domain cannot receive mail or the message was rejected outright. Continuing to send is pointless and harms your sender reputation.
• Soft bounces are temporary. The mailbox may be full, the receiving server may be busy or the message may have been deferred. A later attempt may work.

Sending services classify bounces for you. Amazon SES, for example, labels each bounce as Undetermined, Permanent (hard) or Transient (soft), and its documentation says that when you receive a Permanent bounce you should immediately remove the address from your mailing lists, warning that continued sending to addresses that hard bounce can harm your reputation as a sender (Amazon SES: Notification contents).

Treat soft bounces with a rule, not a guess

Soft bounces need a policy, because a soft bounce that repeats every time is effectively permanent. A practical approach:

• Let your sending service retry a soft bounce for its normal period. SES, for instance, notes that it attempts to redeliver after a soft bounce for a certain period before giving up.
• Count soft bounces per address over a rolling window.
• After a set number of consecutive soft bounces across separate campaigns, suppress the address and flag it for review.

The exact threshold is a business decision. Write it down so that marketing, sales and engineering apply the same rule.

Automate email bounce handling

Manual bounce handling does not survive volume. Most sending services can send bounce events to an endpoint or queue in near real time. Build a small consumer that:

1. Receives each bounce event and stores the raw payload.
2. Reads the bounce type, sub-type, status code and recipient address.
3. Applies your rules: suppress immediately for hard bounces, increment a counter for soft bounces.
4. Writes the outcome to a central suppression list and to the contact record in your CRM.

Store the raw payloads. When a rule misfires, or a provider changes its wording, you will want to replay events through corrected logic.

Keep one suppression list for every tool

Bounce handling breaks down when each tool keeps its own list. A contact that hard bounced in your marketing platform may still be mailed by a sales sequencing tool or a transactional sender. The fix is a single suppression list that every sending tool checks before sending, or a sync that pushes suppressions into each tool. Our guide to the email suppression list covers how to keep opt-outs and bounces consistent across systems.

Prevent bounces before they happen

Handling bounces well is necessary, but avoiding them is better. Bounces often start with poor data at the point of capture: mistyped addresses on forms, purchased lists or contact records that have not been checked for years. Validating syntax at entry, confirming addresses with double opt-in where it suits your audience and re-checking old records before a campaign all reduce the volume. Our guide to email verification explains how MX and SMTP checks work and where they fall short.

Worked example: a bounce rules table

The table below is a hypothetical rule set for a company that sends marketing, sales and transactional email. It shows how codes map to actions; adapt the thresholds to your own programme.

Bounce signalExampleActionWhere it is recordedPermanent, mailbox does not exist5.1.1 user unknownSuppress at onceSuppression list and CRM contactPermanent, domain cannot receiveNo mail server for domainSuppress at onceSuppression list and CRM account notePermanent, policy rejection5.7.x blocked or unauthenticatedDo not suppress yet; investigate sender setupDeliverability incident logTransient, mailbox fullMailbox full sub-typeCount; suppress after repeated failuresBounce counter on contactTransient, general deferral4.x.x try again laterAllow provider retries; count if finalBounce counter on contactUndeterminedNot enough detailReview sample manuallyReview queue

Notice the third row. A policy rejection can mean the problem is on your side, such as failing authentication, rather than with the address. Suppressing those addresses would hide a sender problem instead of fixing it.

Watch your bounce rate by source

Track bounces as a rate, broken down by list source, campaign and sending tool. A spike tied to one import or one form usually points to a data quality problem at that source. A spike across everything at once usually points to a sending problem, such as a blocklisting or an authentication change. Seeing both views quickly is what turns bounce handling from cleanup into diagnosis.

Make bounce status visible to sales

Sales teams often work from the CRM, not the sending platform. If a prospect's address hard bounced, show that clearly on the contact record so that a salesperson does not copy it into a personal email or another sequence. Add a field for email status and the date it last changed, and make it read-only for most users so that it cannot be overwritten casually.

Review the rules regularly

Providers change bounce wording, and your sending mix changes over time. Review a sample of bounces each quarter, check that the classification still matches reality and look for addresses that were suppressed in error. A short review keeps your rules honest and stops valid contacts from being lost permanently.

Frequently Asked Questions

What is the difference between a hard and a soft bounce?

A hard bounce is a permanent failure, such as a non-existent address, and the address should be suppressed. A soft bounce is temporary, such as a full mailbox, and a later attempt may succeed.

Should I remove addresses that soft bounce?

Not after a single soft bounce. Suppress an address when soft bounces repeat across several separate sends, according to a written threshold.

Why should email bounce handling feed into the CRM?

So that sales and other teams see the address is undeliverable and do not keep mailing it from other tools, which would continue to harm your sender reputation.

Can a bounce mean my own setup is wrong?

Yes. Rejections for policy or authentication reasons can point to problems with SPF, DKIM, DMARC or sending reputation rather than with the recipient address.

Get bounces under control

We build bounce processing, shared suppression lists and CRM updates so that every sending tool respects the same data. See our cold outreach and deliverability service, or talk to us about bounce handling.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.