Hard bounce vs. soft bounce in cold email

A bounce is a delivery status notification generated after a receiving system cannot accept or deliver a message. Some failures happen during the SMTP conversation; others arrive later from a mailer-daemon or postmaster address. Reliable handling uses the status code, failed recipient, original message identifier, and diagnostic text together.

A hard bounce indicates a permanent failure, such as a recipient address that does not exist or a domain that cannot receive mail. Mark that address as suppressed and stop future campaign steps. Repeatedly sending to a permanent failure wastes capacity and harms list-quality signals.

• Set a terminal lead status.
• Clear scheduled follow-ups.
• Store the provider code and diagnostic reason.
• Suppress the address from future campaign imports where appropriate.

A soft bounce can indicate a full mailbox, a temporary server problem, throttling, or a message that is too large. Retry only when the provider classifies the problem as temporary, apply backoff, and cap the number of attempts. A temporary failure that repeats should eventually become a stop condition.

Authentication failures, reputation blocks, and provider policy rejections are different from an invalid recipient. Stopping one lead does not fix them. Pause or reduce the affected sending stream, inspect SPF, DKIM, DMARC, reputation, volume, and message practices, then confirm the correction before resuming.

Prefer the original Message-ID or provider correlation data over extracting an arbitrary address from human-readable text. Delivery reports can contain the sender, failed recipient, forwarding addresses, and quoted message headers. Store the raw diagnostic safely, normalize message identifiers, and make processing idempotent so the same bounce cannot change state twice.

A bounce should normally stop future steps for the affected lead, not terminate every other lead in the campaign. Campaign-wide pausing makes sense when failure patterns indicate a sender-domain, mailbox, authentication, or provider-policy problem. That decision should be based on aggregated failures, not a single invalid address.