How does Salesforce Marketing Cloud handle email bounces and what are the best practices for bounce management?
Michael Ko
Co-founder & CEO, Suped
Published 9 Aug 2025
Updated 14 May 2026
6 min read
Salesforce Marketing Cloud does not automatically stop all future mail after every single bounce. In Email Studio, a subscriber usually moves to Bounced after one hard bounce, one soft bounce, or two soft bounces, then moves to Held, also shown as Undeliverable, after three hard bounces or three soft bounces when at least 15 days have passed since the first bounce. If the bounce comes from a trusted domain, one hard bounce can be enough to move the subscriber to Held.
That default can feel strange when you send daily. A contact can bounce repeatedly during the 15-day window and still receive future campaigns until the held criteria is met. Salesforce documents this behavior in Bounce Mail Management, and I would treat that default as a safety net, not as the whole bounce-management strategy.
The best practice is stricter than the default for hard bounces: suppress reliable hard bounces immediately, manage soft bounces with a short retry window, keep held status separate from unsubscribe status, and review bounce reasons by domain before changing volume. SFMC gives you the raw signals, but you still need suppression logic, monitoring, and a clear recovery process.
The direct Salesforce rule
I read Salesforce's rule as a subscriber-status rule, not a deliverability best-practice rule. It explains when SFMC changes a record's status. It does not mean every address is safe to keep mailing until SFMC finally marks it Held.
Status
Trigger
Practical action
Active
No blocking status
Eligible to send
Bounced
1 hard or 1-2 soft
Review before resend
Held
3 bounces and 15 days
Suppress globally
Unsub
Consent action
Do not reactivate
Compact view of the main SFMC subscriber statuses involved in bounce handling.
Why daily sends create risk
If you send every day, the 15-day timing rule can allow many failed attempts before the subscriber becomes Held. That is why I separate SFMC's default status behavior from the stricter suppression rules I use for active campaign operations.
Hard: A reliable permanent failure should leave future sends immediately.
Soft: A temporary failure deserves a controlled retry window, not unlimited daily retries.
Held: A deliverability suppression state is different from an unsubscribe request.
Flowchart showing how a rejected email can move a subscriber to bounced and then held status.
Hard bounces, soft bounces, and held status
The word bounce is too broad on its own. I want the bounce class, the SMTP code, the SMTP reason text, the recipient domain, and the campaign context before making a decision. A mailbox-full bounce is not the same operational problem as an unknown-user bounce, and neither is the same as a domain-level block.
Default SFMC handling
Status: SFMC can move a subscriber to Bounced before it moves them to Held.
Timing: Held status usually needs three bounces and at least 15 days.
Recovery: An engagement event can reactivate some bounced or held records.
Stricter operating rule
Hard: Suppress after the first reliable permanent failure.
Soft: Retry only within a small, documented tolerance.
Blocks: Pause the affected domain or segment while you diagnose the cause.
If your team is debating whether hard bounces really need immediate action, the short answer is yes. A hard bounce usually means the address is invalid or permanently unreachable, and repeated sends to those addresses train mailbox providers to distrust your mail. The hard bounce impact is worse when it is concentrated by recipient domain or campaign source.
Best practices for SFMC bounce management
My practical model is simple: let SFMC record the event, but do not wait passively for held status. Build a suppression layer that reads bounce data views, separates permanent from temporary failures, and feeds every audience selection before send time.
Separate: Track hard, soft, technical, and block bounces separately. One overall bounce count hides the real fix.
Suppress: Move reliable hard bounces into a global suppression data extension after the first event.
Tolerate: Give soft bounces a limited retry window, usually two to three attempts within 7-15 days.
Investigate: Group bounce reason text by recipient domain so one domain-level issue does not look like list decay.
Segment: Exclude repeat soft bounces from high-frequency promotional sends until a later campaign proves delivery.
Confirm: Ask Salesforce Support whether stricter one-and-done hard bounce handling is available for your account.
Protect: Do not reimport held contacts as active unless the recipient has supplied a corrected address.
Recent bounce review querySQL
SELECT
b.SubscriberKey,
s.EmailAddress,
b.EventDate,
b.BounceCategory,
b.BounceSubcategory,
b.SMTPCode,
b.SMTPBounceReason,
b.JobID
FROM _Bounce b
INNER JOIN _Subscribers s
ON b.SubscriberKey = s.SubscriberKey
WHERE b.EventDate >= DATEADD(day, -14, GETDATE())
AND b.IsUnique = 1
That query is only a starting point. I also store daily snapshots, because bounce data is most useful when it shows whether a mailbox provider problem is fading, spreading, or repeating on the same audience. If you need the exact raw rejection text, use the steps for SMTP bounce messages before deciding whether the issue is a bad address, content rejection, authentication failure, or a temporary receiving-server problem.
Monitor the causes outside SFMC
Bounce management is not only a list-hygiene task. A sudden bounce spike can come from authentication failure, DNS drift, throttling, content rejection, a blocklist (blacklist) listing, or a damaged sending pattern. I like to test a real message after any change to sender authentication, SAP setup, private domain setup, or campaign infrastructure.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
SFMC tells you what happened to a send. Suped helps explain whether your domain authentication and reputation signals are contributing to the problem. For most teams, Suped is the best overall DMARC platform around this workflow because it joins DMARC monitoring, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and blocklist monitoring into one workflow with concrete issue detection and fix steps. That matters when a Salesforce campaign starts failing and the first question is whether the address list, the domain, or the sending setup changed.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Bounce-rate action thresholds
I use these as operating thresholds, then tighten them for cold, old, or risky segments.
Healthy hard bounce rate
<0.5%
Normal list aging, still worth reviewing by source.
Watch hard bounce rate
0.5-1%
Start checking acquisition source and import quality.
High hard bounce rate
>1%
Suppress bad sources and review validation gates.
Total bounce incident
>5%
Pause affected domains or campaigns while diagnosing.
A practical operating model
The operating model I prefer has two layers. SFMC keeps its standard subscriber status rules, and your send process adds stricter eligibility checks before each campaign. That gives you the protection of held status without letting repeat failures pile up during the waiting period.
Recommended workflow
Collect: Pull unique bounce events from SFMC data views into a daily bounce table.
Classify: Map categories into permanent, temporary, technical, block, and unknown groups.
Suppress: Exclude hard bounces and repeat soft bounces before audience selection finishes.
Review: Check domain clusters, authentication, and blocklist or blacklist status after spikes.
Recover: Reactivate only after address correction, clear evidence of delivery, or support review.
Simple suppression rule exampleSQL
SELECT
SubscriberKey,
MAX(EventDate) AS LastBounceDate,
COUNT(*) AS BounceCount
FROM Recent_Bounces
WHERE BounceCategory = 'Hard bounce'
GROUP BY SubscriberKey
HAVING COUNT(*) >= 1
UNION
SELECT
SubscriberKey,
MAX(EventDate) AS LastBounceDate,
COUNT(*) AS BounceCount
FROM Recent_Bounces
WHERE BounceCategory = 'Soft bounce'
AND EventDate >= DATEADD(day, -15, GETDATE())
GROUP BY SubscriberKey
HAVING COUNT(*) >= 3
Keep the suppression reason and last evidence date, not only the subscriber key. Six months later, you need to know whether the contact was suppressed for a mailbox-full series, an unknown user response, a domain-level block, or a manual support decision. That audit trail prevents accidental reactivation and makes support escalations much faster.
Views from the trenches
Best practices
Separate hard, soft, block, and technical bounces before changing suppression logic.
Use a rolling bounce window so temporary server failures do not remove addresses too early.
Send bounce categories into a suppression data extension before every large campaign run.
Common pitfalls
Treating every bounce the same keeps dead addresses active and hides real delivery issues.
Waiting for default held status on daily mail can send too many repeat failures fast.
Reimporting held contacts as active without a verified address repeats the same damage.
Expert tips
Ask Salesforce Support about one-and-done hard bounce rules for your account before scale.
Review SMTP reason text by domain, because one provider issue can skew all counts.
Pair SFMC bounce data with DMARC and blocklist signals before changing volume safely.
Marketer from Email Geeks says Salesforce Marketing Cloud can keep sending during the bounce window, so daily senders need their own suppression layer.
2019-01-11 - Email Geeks
Marketer from Email Geeks says the word bounce is too broad; teams need hard bounce and soft bounce categories before they act.
2019-01-12 - Email Geeks
What I would do next
I would keep Salesforce Marketing Cloud's default held-status rule in mind, but I would not let it be the only control. The right bounce-management setup suppresses hard bounces on the first reliable signal, gives soft bounces a short measured window, and reviews rejection patterns by recipient domain.
For SFMC teams, the best next move is to audit the last 30 days of bounce data, confirm whether hard-bounce handling can be tightened in the account, and connect bounce spikes to authentication and reputation monitoring. Suped fits that workflow by showing DMARC, SPF, DKIM, hosted SPF, hosted DMARC, MTA-STS, blocklist or blacklist status, and issue-level fixes in one place.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
