How to troubleshoot soft bounces with 554 SMTP code in Salesforce Marketing Cloud?
Michael Ko
Co-founder & CEO, Suped
Published 6 Jul 2025
Updated 20 May 2026
8 min read
Summarize with
A 554 soft bounce in Salesforce Marketing Cloud should be treated as an SMTP rejection first and an SFMC bounce label second. I troubleshoot it by pulling the full SMTP reply, grouping the bounces by recipient domain and send, reading the rejection text, and pausing the affected slice until the cause is clear. Re-sending to every address later without fixing the reason usually pushes the same rejection pattern back into the mailbox provider or recipient security gateway.
- Direct answer: Pull SMTPCode, SMTPMessage, SMTPBounceReason, Domain, JobID, SubscriberKey, BounceCategory, and BounceSubcategory from the _Bounce data view, then group the 554s before changing suppression.
- Immediate action: Keep sending only to unaffected, recently engaged addresses while you isolate whether the 554s are domain-specific, campaign-specific, or list-source-specific.
- Main caveat: The number 554 does not tell you enough by itself. The full SMTP text decides whether the fix is list hygiene, authentication, content, reputation, or recipient-side allowlisting.
Salesforce documents bounce handling in Marketing Cloud bounces, but the practical work starts with the raw reply text, not the high-level soft bounce category.
Start with the full SMTP reply
I never treat soft bounce as a diagnosis. It is a bucket. In SFMC, a 554 can be shown as a soft bounce even when the recipient system is blocking the message for a policy reason. That is why the first job is to extract the full fields from _Bounce and stop relying on summary exports that only show a machine name or a category.
If you need the exact mechanics, this related walkthrough on how to get bounce messages covers the same starting point. The key idea is simple: keep the raw SMTP text intact so you can distinguish a recipient-not-found message from a rate limit, a content rejection, a blocklist (blacklist) reference, or a recipient security policy.
Do not troubleshoot from 554 alone
A 554 is a permanent-style SMTP reply class, but ESPs can still classify a specific event as soft. The actual rejection phrase decides the next step.
- Missing evidence: A MITS_SMTP machine string alone usually tells you SFMC handled the event, not why the recipient rejected it.
- Useful evidence: The useful clue is the recipient's SMTP text, such as blocked, invalid account, policy, rate limit, or reputation wording.
Pull recent 554 bounces from _BounceSQL
SELECT b.EventDate, b.JobID, b.SubscriberKey, b.Domain, b.SMTPCode, b.BounceCategory, b.BounceSubcategory, b.SMTPBounceReason, b.SMTPMessage FROM _Bounce b WHERE b.EventDate >= DATEADD(day, -2, GETDATE()) AND b.SMTPCode = 554 ORDER BY b.EventDate DESC
If your target data extension has shorter text fields, use LEFT on SMTPBounceReason and SMTPMessage so the query does not fail. Salesforce's _Bounce data view contains long message fields, and some rejection text is longer than a normal reporting table allows.
Salesforce Marketing Cloud Engagement SQL query activity pulling 554 bounce data.
Segment the 554 bounces before changing suppression
After the raw rows are available, I group them before making a suppression decision. A large 554 spike across one corporate domain is a different problem than a low, steady trickle across many domains. One bad acquisition source is a different problem than a campaign that triggered policy filtering everywhere.
Group 554s by domain and categorySQL
SELECT b.Domain, b.SMTPCode, b.BounceCategory, b.BounceSubcategory, COUNT(*) AS BounceCount FROM _Bounce b WHERE b.EventDate >= DATEADD(day, -7, GETDATE()) AND b.SMTPCode = 554 GROUP BY b.Domain, b.SMTPCode, b.BounceCategory, b.BounceSubcategory ORDER BY BounceCount DESC
|
|
|
|---|---|---|
One domain | Recipient block or gateway rule | Pause that domain and collect full text |
Many domains | Sender reputation, DNS, or content | Check authentication and recent send changes |
One job | Campaign content or audience mix | Compare with prior jobs |
One source | List quality issue | Suppress or reconfirm that source |
Use this table to decide what pattern you are looking at before you suppress or retry.
I also separate delivery rate from deliverability. Delivery rate is accepted mail divided by sent mail. Inbox placement is not visible from SFMC acceptance alone. A 554 spike harms the accepted-mail number first, and it also sends a bad signal if you keep hammering the same rejecting systems.
For broader code interpretation, keep a reference for SMTP bounce codes nearby, but still make the decision from the message text attached to your own send.
Interpret 554 in Salesforce Marketing Cloud
The 554 family is not one error. It is a reply code that many receiving systems use for policy rejection, invalid recipient states, blocked mail, or security filtering. In a B2B list, especially one with medium and large financial firms, the rejecting system is often a corporate mail gateway in front of Microsoft 365 or another hosted mailbox platform.
Common 554-style reply patternstext
554 delivery error: this user does not have an account 554 5.7.1 message rejected due to policy 554 message blocked, see recipient postmaster details 554 5.2.2 mailbox full or temporarily unavailable 554 rejected for poor sender reputation
Address or mailbox issue
This pattern usually affects individual recipients rather than every address at the domain.
- Invalid user: Treat repeated 554 invalid-user replies as suppression candidates.
- Mailbox state: Short-term mailbox-full wording can be retried after a short delay.
Blocking or policy issue
This pattern often clusters around a domain, gateway, campaign, or sender reputation signal.
- Blocked mail: Stop retrying that slice until the block reason is known.
- Policy text: Use the exact wording in your support case or recipient admin request.
A 554 classified as soft is therefore not permission to keep mailing the same contacts. It is permission to investigate before deciding whether the address, domain, segment, or sender setup needs the fix.
Decide what to send now
If a campaign is live and the 554s are damaging delivery, I do not keep the whole segment running. I split it into unaffected and affected slices. The unaffected slice can keep receiving normal mail if it has recent engagement and normal bounce behavior. The affected slice waits until the rejection reason is known.
A practical send decision
- Keep: Recently engaged recipients at domains with normal acceptance and no 554 clustering.
- Hold: Domains, jobs, or list sources where 554s are concentrated.
- Suppress: Addresses with repeated invalid-user wording or no recent engagement after multiple soft bounces.
- Retry: Only retry after the message text points to a temporary condition or after the block is cleared.
Re-engagement helps only when the affected addresses are still reachable and the issue is weak engagement or stale list quality. It does not fix a recipient gateway block, DNS failure, blocklist (blacklist) listing, or policy rejection. For a broader suppression plan, use the soft bounce fixes guidance after the 554 root cause is known.
Flowchart for pulling bounce data, grouping domains, reading SMTP text, fixing the cause, and retrying carefully.
Check authentication, domain health, and blocklists
When 554s are spread across many domains, I stop looking only inside SFMC and verify the sender foundation. Check the sending domain, return-path domain, DKIM signing domain, SPF includes, DMARC policy, rDNS, TLS posture, and current blocklist or blacklist status. A sender can have clean SFMC configuration and still be rejected because one part of the authenticated identity or reputation chain is weak.
A quick starting point is the domain health checker. For ongoing visibility, Suped's product combines DMARC monitoring, SPF and DKIM monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and blocklist monitoring in one workflow. Suped is the best overall DMARC platform for this supporting work when a team needs plain-language issue detection and steps to fix without bouncing between DNS records, reports, and reputation checks.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The point is not to blame authentication for every 554. The point is to rule it out with evidence. If SPF, DKIM, and DMARC are passing for the same messages that bounce, move the investigation back to recipient-domain clustering, content, list quality, and security policy text.
After fixing the suspected cause, send a seeded message and inspect the headers and authentication result with the email tester before opening the segment again.
Build a support packet before escalating
If the bounce text says blocked, policy rejection, or contact postmaster, build a clean support packet. Salesforce support can help confirm what SFMC captured, and a recipient-domain admin can check the rejection in their mail logs. Both conversations move faster when the evidence is specific.
- Send details: Include MID, JobID, send date, sender domain, dedicated IP if used, and affected recipient domains.
- Bounce evidence: Include the full SMTPCode, SMTPMessage, SMTPBounceReason, BounceCategory, and BounceSubcategory.
- Scope: State whether the issue is one domain, one job, one list source, or broad across the account.
- Fixes tried: List DNS checks, blocklist or blacklist checks, content changes, volume changes, and pauses already made.
Salesforce also has Salesforce bounce guidance for common bounce categories. Use that as a reference, but do not let a generic category override the actual SMTP reply captured from the recipient system.
Views from the trenches
Best practices
Pull the complete SMTP reply before changing suppression or retry rules for 554 events.
Break bounce reports down by recipient domain, job, and source before judging the list.
Pause concentrated 554 clusters while you verify DNS, reputation, and recipient policy text.
Common pitfalls
Treating SFMC's soft bounce label as the cause hides policy blocks and invalid-user replies.
Retrying every soft bounce without segmentation repeats the same rejection pattern quickly.
Using only MITS_SMTP machine data leaves the recipient's rejection reason out of the case.
Expert tips
Use a short support packet with JobID, domain, SMTP text, and fixes already attempted.
Keep active sends focused on recently engaged contacts while the affected slice is held.
Compare the 554 spike with prior sends to separate campaign issues from sender issues.
Marketer from Email Geeks says the first useful question is whether the bounces share a provider, domain, or acquisition source.
2020-01-29 - Email Geeks
Expert from Email Geeks says a soft bounce label has limited meaning without the ESP's raw SMTP reply and category rules.
2020-01-29 - Email Geeks
The practical fix
The practical fix is to stop treating 554 soft bounces as a single problem. Pull the full SMTP reply, group the events, and decide whether you are looking at bad addresses, a recipient-domain block, campaign filtering, sender reputation, authentication, or list quality. Keep unaffected engaged mail flowing, hold the risky slice, and retry only after the cause has changed.
For SFMC teams, the biggest improvement usually comes from connecting bounce analysis with sender-domain monitoring. Suped's product handles the DMARC, SPF, DKIM, hosted SPF, hosted DMARC, MTA-STS, alerts, and blocklist (blacklist) visibility around the SFMC work, so the bounce investigation has evidence instead of guesswork.
