Learn how to classify hard and soft email bounces, choose retry or suppression actions, investigate patterns, and improve list hygiene reporting.
A bounce means a receiving mail system did not accept or deliver a message, but not every bounce calls for the same response. The practical difference between a hard bounce and a soft bounce is whether the failure appears permanent or temporary. That distinction should drive retry, suppression, investigation, and reporting decisions.
Hard bounce vs soft bounce: the operational difference
A hard bounce is a failure that appears permanent for the specific address. Common causes include a nonexistent mailbox, an invalid domain, or an address rejected because it cannot receive mail. These failures are often represented by SMTP enhanced status codes beginning with 5, such as 5.1.1, but the code alone is not always conclusive.
A soft bounce is a failure that may be temporary. Examples include a full mailbox, a receiving server that is temporarily unavailable, rate limiting, or a transient connection problem. These often use codes beginning with 4, such as 4.2.2 or 4.7.1.
Treat those code families as signals rather than universal truth. Providers use different wording, and some systems return permanent-looking policy blocks after an initial temporary rejection. Use the structured event type, enhanced status code, diagnostic text, and later delivery events together. Your email service provider's final classification can help, but your own action rules should remain explicit.
Match common bounce categories to an action
Turn each category into a documented disposition instead of placing every failed address into one generic bounced state.
Nonexistent mailbox or invalid recipient: Suppress the exact address immediately. Do not retry it in the same or a later campaign.
Invalid or nonexistent domain: Suppress the address and review its source. Multiple invalid domains from one form, vendor, or import can indicate a collection or data-quality problem.
Mailbox full: Retry on a limited schedule. If failures continue beyond your threshold, stop mailing and suppress the address as persistently undeliverable.
Temporary server or connection failure: Allow bounded retries, then stop. The sending platform may handle delivery-queue retries before it reports the final event.
Rate limit or deferral: Slow sending to that domain and inspect reputation, authentication, and traffic volume before attempting more mail.
Policy, spam, or reputation block: Pause the affected campaign, stream, or receiving domain. Repeated retries can worsen the problem and are not a substitute for diagnosis.
Unknown or malformed response: Avoid automatic repeated sending. Preserve the event for review and classify it once enough evidence is available.
For broader benchmarks and calculation rules, use the bounce rate guide alongside these address-level decisions.
Set bounded retry and suppression rules
Retries should have an endpoint. For example, an internal policy might allow two or three attempts over 24 to 72 hours for a temporary mailbox or server failure. That is a starting framework, not a universal schedule: align it with your provider's queue behavior, message urgency, and the receiving system's response.
Do not create extra application-level retries if your email provider is already retrying the same message. That can produce duplicate deliveries if the original attempt eventually succeeds. Instead, distinguish between an in-queue deferral and a final soft-bounce event.
Suppress hard bounces as soon as the failure is confirmed. For repeated soft bounces, define both a maximum attempt count and a time window. Once either limit is reached, move the address to an undeliverable suppression state.
Keep bounce suppression separate from unsubscribe suppression. An opted-out person must remain opted out even if someone later corrects, reimports, or re-verifies the address. If an apparently mistyped address is corrected, preserve the old address's suppression record and treat the corrected address as a separate contact requiring an appropriate permission basis.
Investigate patterns, not just individual addresses
One hard bounce usually calls for address-level suppression. A cluster of failures calls for investigation. Group events by receiving domain, campaign, sending stream, list source, signup date, and bounce code.
A sudden concentration at one mailbox provider may indicate throttling, authentication trouble, reputation damage, or a provider-specific policy. A concentration from one acquisition source may indicate stale records, form-entry errors, or poorly controlled imports. A gradual rise across many domains may point to list aging.
Check SPF, DKIM, and DMARC alignment when policy failures appear. Compare recent changes in sending volume, cadence, message type, and infrastructure. Review raw diagnostic text, but avoid treating inconsistent provider wording as a perfect taxonomy.
When source quality is the problem, follow a documented process to clean an email list. An Email Verifier can identify some invalid or risky addresses before sending, but verification does not establish consent, guarantee delivery, or override an unsubscribe.
Report bounce outcomes without hiding the problem
Report initial failures and final outcomes separately. At minimum, track messages attempted, accepted, delivered when that event is available, hard bounces, soft bounces, later deliveries after deferral, and addresses newly suppressed.
Do not remove bounced recipients from the denominator merely to make the campaign appear healthier. Keep a stable definition for each metric and state whether the report counts messages, campaigns, or unique recipients. For a recurring program, also monitor the share of active addresses that become suppressed over time.
Segment reports by mailbox provider and acquisition source when volume is sufficient to make the comparison useful. This connects operational bounce handling to the broader email campaign metrics used by marketing, support, and compliance teams.
A concise review checklist is:
Confirm whether the event is temporary, permanent, policy-related, or unknown.
Check whether the provider has already retried the message.
Suppress confirmed hard bounces and expired soft bounces.
Pause domain-level or source-level spikes for investigation.
Record the final disposition without rewriting historical results.
Respect permission, opt-outs, and data minimization
A deliverable address is not automatically a lawful or appropriate address to contact. Before outreach, confirm that you have valid consent or another applicable basis, such as documented legitimate interest where the relevant law permits it. Record the source, purpose, date, and any required balancing assessment.
Honor opt-outs promptly and globally where required. Never reactivate an unsubscribed contact simply because the address passes verification or later delivers successfully.
Retain only the suppression data needed to prevent future sending and demonstrate the decision, such as an address or suitable privacy-preserving identifier, reason, and timestamp. Restrict access and avoid keeping full SMTP transcripts or unrelated contact attributes longer than operational, security, or legal requirements justify.
In conclusion, hard bounces normally require immediate address suppression, while soft bounces justify limited retries followed by a clear stopping rule. Policy blocks and clustered failures require investigation rather than repeated sending. Consistent classification, durable opt-out controls, and transparent reporting turn bounce data into safer deliverability decisions.
Apply this guidance to your business context and the rules that govern your recipients. Keep consent or legitimate-interest records, honor opt-outs, and minimize stored contact data.