Soft bounce vs hard bounce: what each means and what to do

How the options were evaluated

The categories and actions below were checked against first-party provider documentation and SMTP standards on August 12, 2026.

• Protocol evidence: The three-digit SMTP reply, enhanced status code, receiving host, and exact diagnostic text.
• Provider interpretation: The sending platform's classification, retry handling, reporting, or suppression treatment.
• Action safety: Whether the evidence supports a retry, address review, domain-control check, or provider-specific investigation.
• Scope: Whether the failure is isolated to one recipient, affects a recipient domain, or appears across multiple messages.
• Unknowns: A provider's unpublished mapping or threshold remains unknown. Missing documentation does not prove that a feature or behavior is absent.

Mailchimp's soft and hard bounce treatment

Mailchimp's soft and hard bounce guidance describes a soft bounce as a temporary delivery problem and a hard bounce as a permanent delivery problem within Mailchimp's service.

• Best fit: A Mailchimp user interpreting Mailchimp's own bounce labels and deciding whether a contact needs further review.
• Relevant evidence: Mailchimp documents soft and hard bounce terminology and its own account treatment. The label is useful operational evidence inside Mailchimp.
• Tradeoff: Mailchimp's classification and account handling are product-specific. They do not convert every similar SMTP reply from another provider into the same category or action rule.

A temporary label calls for the retry behavior that Mailchimp documents for that sending path. It does not establish that the recipient mailbox will accept a later message.

Twilio SendGrid's bounce and block classifications

Twilio SendGrid's bounce and block classifications document an operational classification layer for receiver responses used in reporting and action.

• Best fit: A Twilio SendGrid operator who needs to interpret a SendGrid bounce, block, or related event in the context of SendGrid reporting.
• Relevant evidence: SendGrid documents classifications that group response outcomes for its platform.
• Tradeoff: A SendGrid classification is an interpretation of the sending event. It does not replace the remote receiver's SMTP reply or reveal a mailbox provider's private filtering decision.

Palisade for the public-domain control branch

Palisade is relevant only when the bounce evidence identifies a public domain control, such as SPF, DKIM, DMARC, MX, or another DNS-published email configuration. In that case, the Email Security Score can inspect the public configuration for the affected domain.

• Best fit: An operator whose bounce evidence points to a public email-authentication or routing control that needs a point-in-time domain check.
• Relevant evidence: The tool checks public DNS evidence for the controls it reports. It can help narrow a DNS or authentication branch before a same-path message retest.
• Tradeoff: A public-domain scan cannot validate recipient existence, reproduce a private receiver policy decision, explain every provider suppression rule, or guarantee that a retried message will be accepted.

How to choose

Start with the raw response, then use the narrowest action the evidence supports.

• Choose a bounded retry when the receiver returns a 4yz response and the provider documents retry behavior for that situation.
• Choose address verification and stop unchanged retries when a 5yz response specifically identifies an invalid recipient address.
• Choose a recipient-domain routing investigation when the response points to domain or MX problems.
• Choose a public-domain check when the bounce names SPF, DKIM, DMARC, MX, or DNS. A DKIM signature verification failure needs message-header and signing-path evidence in addition to any public DNS result.
• Choose the sending provider's dashboard and raw message evidence when the response is vague, policy-specific, or grouped under an unpublished classification.

bounce_evidence:
  recipient: "redacted@example.net"
  smtp_reply: "550"
  enhanced_status: "5.1.1"
  diagnostic_text: "Recipient address rejected"
  provider_label: "hard bounce"
  first_seen: "2026-08-12T12:00:00Z"
  repeat_count: 1
decision:
  action: "stop unchanged retries and verify the address through an authorized source"
  verification: "send one new message through the same production path after the cause is corrected"

This example is illustrative only. Do not place a real recipient address, message content, or unredacted customer data in a shared incident record.

Do not repeatedly send an unchanged message after a permanent failure. Repetition does not correct an invalid address or a receiver's stated rejection condition.

For Gmail-specific deferrals, Google's sender guidance recommends pausing, testing with a single message, and increasing volume gradually after successful delivery. That guidance applies to Gmail traffic. It is not a universal retry schedule.

Check public controls when the bounce names them

If the diagnostic names SPF, DKIM, DMARC, MX, or DNS, inspect the affected sending domain with the Email Security Score before changing policy. Compare the public result with a fresh message sent through the same production path.

The check does not prove why an individual receiver rejected a message, validate a recipient mailbox, monitor later changes, or guarantee future placement. It only helps inspect the public-domain configuration branch of this bounce investigation.