How to get SMTP bounce messages from Salesforce Marketing Cloud?
Michael Ko
Co-founder & CEO, Suped
Published 1 Jul 2025
Updated 15 May 2026
10 min read
Summarize with
The direct answer is: get SMTP bounce messages from Salesforce Marketing Cloud by querying the _Bounce data view in Automation Studio and writing the results into a data extension. Include SMTPBounceReason, SMTPCode, BounceCategory, BounceType, Domain, and JobID so the result has the actual SMTP reason plus the send context.
For a one-off investigation, I use a manual Automation Studio query activity. Change the JobID each time, run the automation once, then export the data extension if the result set is larger than the rows shown in the interface. For recurring investigations, I prefer a daily automation that stores the last 14 days of bounce rows, because it gives deliverability teams a searchable working table when a provider issue appears.
SFMC gives you bounce event fields, not a full raw SMTP transcript. That distinction matters. The fields are still enough to identify mailbox problems, policy blocks, temporary deferrals, blocklist (blacklist) symptoms, and authentication-related rejections when you combine them with DMARC, SPF, DKIM, and reputation data.
Use the _Bounce data view first
The normal SFMC route is a SQL Query Activity in Automation Studio. Salesforce documents the _Bounce data view as the place to query bounce data, and it includes SMTP fields such as SMTPBounceReason. Build a target data extension first, then point the query at that data extension.
- Minimum fields: Store JobID, SubscriberKey, EventDate, Domain, BounceCategory, BounceType, SMTPCode, and the SMTP reason text.
- Primary filter: Use JobID when the question is about a specific campaign send.
- Provider filter: Use Domain when the issue is isolated to Gmail, Yahoo, Outlook, iCloud, or a corporate domain.
- Retention limit: Query recent data quickly. SFMC bounce data views are retained for six months.
One-off _Bounce query by JobIDSQL
SELECT JobID, SubscriberKey, EventDate, Domain, BounceCategory, BounceType, SMTPCode, LEFT(SMTPBounceReason, 4000) AS SMTPBounceReason FROM _Bounce WITH (NOLOCK) WHERE JobID = 253977
The LEFT wrapper is practical because SMTP reason text can exceed the text length you created in the target data extension. Salesforce's own guidance uses this pattern for long text fields.
Salesforce Marketing Cloud Automation Studio query activity for bounce data.
Build the target data extension correctly
The target data extension determines whether your query is useful or frustrating. If the field types are too short, you lose the part of the bounce reason that explains the rejection. If the keys are missing, you struggle to join the result back to a send, journey, or subscriber.
|
|
|
|---|---|---|
JobID | Number | Send lookup |
SubscriberKey | Text | Contact lookup |
Domain | Text | ISP filter |
SMTPCode | Text | Code grouping |
SMTPBounceReason | Text | Provider reason |
Recommended target data extension columns for SFMC bounce pulls.
Keep long SMTP reasons intact
Use a large text field for SMTPBounceReason. I still limit it in SQL with LEFT() so the query does not fail when a receiver returns a long diagnostic string.
For enterprise accounts, confirm whether you need to query in the parent business unit or prefix enterprise-level data views with ENT.. That detail is easy to miss when the bounce investigation starts in a child business unit but sends or subscribers span a wider account structure.
Filter by job, domain, ISP, and time
A raw bounce pull gets noisy fast. I usually start with the send, then narrow by receiver domain and date window. If the complaint is about a single mailbox provider, domain filtering gives a cleaner answer than scanning all bounce rows.
Pull a provider-specific bounce sampleSQL
SELECT b.JobID, b.SubscriberKey, b.EventDate, b.Domain, b.BounceCategory, b.BounceType, b.SMTPCode, LEFT(b.SMTPBounceReason, 4000) AS SMTPBounceReason FROM _Bounce b WITH (NOLOCK) WHERE b.JobID = 253977 AND b.Domain IN ('yahoo.com', 'aol.com') AND b.EventDate >= DATEADD(day, -7, GETDATE())
If you need IP address level analysis, SFMC bounce data alone usually is not enough. Join what you can to job and send metadata, export the rows, then compare the time window against your sending IP allocation, MTA pool, and receiver pattern. A provider-specific spike with similar SMTP reasons across a short window is a stronger signal than a single row.
One-off pull
- Best use: Investigating one campaign, one journey send, or one provider incident.
- Setup: Manual Automation Studio run with a changed JobID.
- Weak spot: You lose speed if the issue reappears every week.
Daily archive
- Best use: Ongoing deliverability work across brands, domains, or business units.
- Setup: Scheduled query that stores a rolling 14-day or 30-day sample.
- Weak spot: It needs table hygiene so old rows do not pile up.
For interpretation, pair the raw SMTP text with a practical reference for SMTP bounce codes. The code family tells you whether the receiver treated the event as temporary or permanent, while the reason text explains the receiver's policy wording.
Use the API when you need automation outside SFMC
If you need to pull bounce events into a warehouse or an internal support tool, use the Marketing Cloud SOAP API. Salesforce has BounceEvent details for retrieval, including SMTP-related fields such as SMTPCode and SMTPReason.
- Choose scope: Decide whether your retrieval is by send, subscriber, or date range.
- Request fields: Include SMTPCode, SMTPReason, subscriber identifiers, and send identifiers.
- Store raw values: Keep the original reason text before you classify it.
- Normalize later: Classify by provider, code family, and repeated wording after ingestion.
Data view or API?
Use Automation Studio when a marketer or deliverability lead needs a fast pull inside SFMC. Use the API when engineering owns a warehouse, BI model, or support workflow that needs repeatable ingestion.
The SQL route is still the simplest starting point. I move to the API only when the bounce data must live outside Marketing Cloud or when several business units need a single reporting flow.
Read the SMTP reason without overreacting
The SMTP reason is diagnostic evidence. It is not always a final verdict. A line that mentions spam, policy, or reputation tells you what the receiver said at that moment. It still needs context: volume, affected domain, authentication results, sending IP, complaint rate, and whether the same wording repeats.
Bounce signal priority
A simple way to rank SMTP bounce patterns before opening a deliverability incident.
Normal
Low volume
Scattered mailbox or address failures
Watch
Provider cluster
One provider has repeated temporary failures
Act
Repeated pattern
Policy, spam, blocklist, or blacklist language repeats
A 554 response deserves a closer read because providers use it for policy and reputation rejections. If your SFMC result shows that pattern, this deeper guide on 554 soft bounces is a useful next step.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
After pulling bounce data, send a live test message through the same authenticated path and inspect the result with an email tester. That catches issues the bounce row alone will not show, such as broken DKIM signing, weak content signals, or an unexpected sending domain.
Tie bounce messages to authentication and reputation
SMTP bounce data explains what receivers rejected. It does not show the whole authentication story. For SFMC, I want to see the bounce reason beside the domain's DMARC, SPF, DKIM, and blocklist (blacklist) posture. That is where Suped fits into the workflow.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's DMARC platform gives a clean view of authentication health, sending sources, and policy status. When SFMC bounce rows point to policy or reputation language, Suped helps confirm whether the visible From domain, DKIM domain, SPF path, and DMARC result are healthy.
- DMARC checks: Use DMARC monitoring to catch authentication failures and unauthorized sources.
- Domain checks: Use a domain health check when you need a fast SPF, DKIM, and DMARC review.
- Reputation checks: Use blocklist monitoring when bounce text references a blocklist or blacklist.
- Operational alerts: Suped has real-time alerts and issue steps so authentication problems are not left as raw reports.
For most teams, Suped is the best overall DMARC platform for the authentication and reputation side because it brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, and MSP multi-tenancy into one platform. SFMC remains the source for its own bounce rows. Suped turns the related domain and reputation signals into fixable work.
A practical investigation workflow
When a campaign has an unexplained bounce spike, I work in this order. The point is to separate address quality, provider policy, authentication, and reputation instead of treating every bounce as the same problem.
Flowchart for investigating Salesforce Marketing Cloud bounce messages.
- Pull rows: Query _Bounce for the affected send and export the results.
- Group reasons: Count repeated SMTP codes and repeated wording by receiver domain.
- Classify causes: Separate invalid users, full mailboxes, policy rejections, and reputation blocks.
- Check domain setup: Confirm the sending domain has the expected SPF, DKIM, and DMARC results.
- Act by cause: Suppress bad addresses, slow risky sends, fix authentication, or work the provider-specific issue.
For classification logic, read this companion guide on parsing SMTP responses. It helps turn varied provider text into hard bounce, soft bounce, policy block, and reputation categories without hiding the original reason.
What I would automate
- Daily extract: Store recent _Bounce rows in a research data extension.
- Provider rollup: Count bounce reasons by domain and campaign.
- Export path: Send the result to FTP or a warehouse for longer trend analysis.
- Domain monitoring: Pair the export with Suped alerts for DMARC and blocklist changes.
Salesforce also has guidance for teams that need to pull bounce reasons during low deliverability investigations. The key is the same: export enough fields to preserve the SMTP text and the send context.
Common mistakes to avoid
Most failed bounce investigations come down to missing fields or weak filters. The query runs, but the output does not answer the deliverability question.
- Missing SMTP text: Pulling only bounce category hides the receiver's real wording.
- Short text fields: A small target field cuts off the useful part of the reason.
- No provider grouping: A total bounce count hides a Yahoo-only or Outlook-only issue.
- No authentication check: Policy rejection text often points back to SPF, DKIM, DMARC, or sender identity.
- Overwriting history: One-off target tables should be named clearly or exported before reuse.
Views from the trenches
Best practices
Create a reusable bounce pull with JobID, Domain, SMTPCode, and SMTP reason fields.
Keep a rolling bounce archive so urgent provider issues are searchable without rebuilds.
Export large result sets when the SFMC interface shows only a limited visible sample.
Common pitfalls
Do not rely on category alone because it drops the receiver's actual rejection wording.
Do not use tiny text fields for SMTP reasons because long provider diagnostics get cut.
Do not diagnose ISP issues without grouping bounce rows by domain and send context.
Expert tips
Use one-off automations for urgent sends and scheduled automations for trend analysis.
Pair SFMC bounce rows with DMARC and blocklist data before changing sending strategy.
Keep original SMTP text before mapping it into hard, soft, policy, or reputation labels.
Marketer from Email Geeks says a one-off Automation Studio query against _Bounce works well when the JobID changes for each investigation.
2019-12-19 - Email Geeks
Marketer from Email Geeks says the target data extension must include SMTPBounceReason or the query will miss the actual provider message.
2019-12-19 - Email Geeks
The practical answer
To get SMTP bounce messages from Salesforce Marketing Cloud, query _Bounce in Automation Studio, write the result into a data extension, and include SMTPBounceReason plus the send and provider fields needed to interpret it. For one campaign, filter by JobID. For provider issues, add Domain and date filters.
Once you have the rows, do not stop at the bounce text. Check authentication, blocklist (blacklist) status, and sender identity. SFMC tells you what bounced. Suped helps you connect that evidence to DMARC, SPF, DKIM, and reputation fixes across the domains you send from.
