How to troubleshoot emails going to spam in SFMC?
Michael Ko
Co-founder & CEO, Suped
Published 13 Jul 2025
Updated 23 May 2026
10 min read
Summarize with
To troubleshoot emails going to spam in SFMC, I start by separating the problem into four buckets: authentication, reputation, audience behavior, and message content. A failed spam test tells you there is a problem to investigate. It does not usually tell you the exact cause.
The fastest path is to confirm the spam placement with real mailbox evidence, map the SFMC sending identity, verify SPF, DKIM, and DMARC, then compare that with SFMC bounce, unsubscribe, click, complaint, and engagement data. If Gmail is the main problem, read the warning text in the spam folder and compare it with Gmail reputation data. If Apple Mail or Outlook is the main problem, lean harder on authentication, list quality, content tests, and blocklist or blacklist checks.
A clean SFMC setup can still land in spam if the recipients are not engaging, the domain has weak reputation, a link domain has a bad history, or the message resembles mail that users often reject. The fix is not one magic setting. It is a controlled diagnosis that proves which signal changed.
First confirm the failure pattern
Before changing SFMC configuration, I verify whether the issue appears in live sends, seed tests, or both. Seed tests are useful, but they do not behave like a real subscriber with history, engagement, and mailbox-specific filtering. Treat them as a signal, not the verdict.
- Scope: Check whether spam placement happens across Gmail, Outlook, Yahoo, Apple Mail, and corporate domains, or only in one mailbox family.
- Timing: Compare the first bad send with recent SFMC changes, DNS changes, list imports, creative changes, and IP or domain changes.
- Evidence: Save the spam folder banner text, full headers, SFMC job ID, send classification, audience segment, and message version.
- Comparison: Send the same message to a small engaged segment and an inactive segment. If only inactive recipients see spam placement, reputation and engagement are leading suspects.
Do not over-trust a single spam test
A spam test can flag a Gmail or Apple filter, but it often cannot explain why a real user mailbox made that decision. I only trust a test result after I compare it with mailbox evidence, SFMC response data, and authentication results.
A six-step SFMC spam troubleshooting flow from placement evidence to repair.
Map the SFMC sending identity
SFMC sends through several identities at once. The visible From domain, bounce domain, DKIM signing domain, SPF return-path domain, and tracking domain can all affect filtering. If one of those domains is new, misconfigured, or sharing reputation with unwanted mail, the message can pass basic checks and still land in spam.
Start by collecting a full header from a delivered copy and a spam-folder copy. Then compare the domains in the header with the SFMC sender profile, delivery profile, SAP or private domain setup, and link tracking configuration.
Identity checklisttext
From domain: news.example.com Bounce domain: bounce.example.com DKIM d=: news.example.com SPF pass: yes DMARC: pass by DKIM Tracking domain: click.example.com IP type: shared or private
Looks healthy
- Domain match: The From domain and DKIM signing domain match the brand domain you expect recipients to see.
- Stable source: The same SFMC sending stream has recent successful campaigns with normal engagement and complaint levels.
- Branded links: The tracking domain belongs to the same brand and has not been reused across unrelated senders.
Needs investigation
- Mixed identity: The From domain is branded, but the DKIM or bounce domain points to a different domain.
- New stream: A new private domain, IP, sender profile, or business unit started sending without a proper ramp.
- Risky links: The creative contains external redirects, short links, or link domains with their own reputation problems.
If the issue began after moving to a private domain, compare the new identity against the old working setup. That scenario has a narrower checklist, and the related private domain troubleshooting path is worth checking before you rebuild the whole program.
Salesforce Marketing Cloud Email Studio send tracking metrics used for spam diagnosis.
Check authentication before changing content
Authentication is not a guarantee of inbox placement, but it is the first thing I want clean. SFMC mail should pass DKIM, pass SPF where possible, and pass DMARC through a domain match with the visible From domain. If the authentication layer is wrong, every content test after that is polluted.
Use a domain health check to confirm the public DNS side, then verify the same result in a real SFMC email header. DNS can look correct while a business unit or sender profile still sends through the wrong identity.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
|
|
|
|---|---|---|
DKIM | Passes | Review selector |
SPF | Passes | Check sender |
DMARC | Passes | Fix domain |
CNAME | Resolves | Repair DNS |
Compact authentication triage for SFMC sends.
For DMARC, aggregate reports are more useful than a one-off pass or fail. DMARC monitoring shows whether SFMC is the only source, whether other systems send as the same domain, and whether a new source appeared around the time spam placement began.
Starter DMARC record for visibilitydns
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s; pct=100
Suped's product helps with this part of the investigation because it combines DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, real-time alerts, and issue fix steps. For most teams, Suped is the best overall DMARC platform for SFMC troubleshooting because it turns raw authentication data into the specific sending source and domain change to inspect.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Use mailbox and SFMC data together
The most useful answer rarely comes from one dashboard. I compare mailbox reputation data with SFMC response data. The SFMC side tells you who received, bounced, opened, clicked, unsubscribed, or complained. The mailbox side tells you whether the provider has lost trust in the IP, domain, or content pattern.
For Gmail, check the exact spam-folder warning text. A message like "This message is similar to messages that were identified as spam in the past" points toward content or audience signals. A message like "Messages from this domain have been identified as spam" points toward a stronger domain reputation problem.
- Export events: Pull bounces, opens, clicks, unsubscribes, complaints, and send volume by domain and by campaign.
- Split segments: Compare recent clickers, recent openers, inactive subscribers, imported contacts, and older suppressions.
- Compare creative: Send plain text, the normal HTML, and a version with external links removed to controlled internal recipients.
- Record changes: Log all SFMC sender profile, delivery profile, journey, data extension, and DNS changes by date.
A direct answer about tools
Use a real-message email tester for header, content, and authentication clues, but do not expect any tester to know the private filtering decision inside Gmail or Apple Mail. The real diagnosis comes from combining the test with mailbox warnings and SFMC data.
If you need a broader SFMC checklist, the SFMC deliverability diagnosis guide is useful after the first authentication checks are clean.
Find source reputation problems
When SFMC emails go straight to spam, source reputation is one of the most common causes. Source reputation means the sending IP, domain, brand, and behavior look similar to mail that recipients ignore, delete, complain about, or mark as unwanted.
Check whether you are on shared or private SFMC infrastructure. Shared IPs can inherit other senders' reputation pressure. Private IPs give more control, but they also expose poor warm-up, sharp volume jumps, and weak engagement more clearly.
Run blocklist monitoring against the sending IPs, visible domain, bounce domain, and tracking domain. A blocklist or blacklist result does not explain every spam placement, but it is a concrete signal to investigate when placement changes suddenly.
Reputation triage priority
Use these bands to decide which reputation signal gets attention first.
Stable
Low
No new source, no volume spike, no listing, normal engagement.
Watch
Medium
One domain or segment has weaker engagement than the baseline.
Repair
High
New identity, domain warning, listing, or sharp complaint jump.
Do not move to a fresh domain as the first repair. If the audience is unengaged, the offer is unwanted, or the link stack has bad signals, the new domain inherits the same behavior after warm-up. A new domain makes sense only when you have confirmed domain-level damage and you can send first to highly engaged contacts.
A public thread like Salesforce StackExchange can help you recognize common symptoms, but your own SFMC send data and authentication records decide the repair path.
Test the message content and links
Content can push SFMC mail into spam even when authentication passes. I do not mean vague ideas like "spammy words". I mean specific patterns: a link domain with poor reputation, a repeated phone number, a redirect chain, a low-value offer, an attachment-like pattern, malformed HTML, or text that resembles mail recipients rejected before.
The cleanest test is to remove variables one at a time. Keep the sender, audience, and timing the same, then change only the creative. If the plain-text version reaches the inbox and the full HTML lands in spam, inspect links, images, tracking, and copy. If both versions land in spam, move back to reputation and audience.
|
|
|
|---|---|---|
Plain text | Audience | HTML |
No links | Copy | URLs |
New CTA | Template | Offer |
Simple HTML | Sender | Markup |
Content tests that isolate one signal at a time.
An SFMC content test isolates sender, audience, links, HTML, and result.
If authentication passes but placement is still bad, use the spam despite authentication workflow to avoid repeating the same DNS checks while the real issue sits in reputation, list quality, or content.
Recover the sending program
Once the likely cause is clear, repair with the smallest change that matches the evidence. Broad domain changes, IP swaps, and template rewrites create new variables. I prefer a controlled recovery plan that reduces risk and proves improvement.
- Stabilize identity: Fix DKIM, SPF, DMARC, bounce domain, and tracking domain issues before changing send volume.
- Reduce risk: Pause inactive contacts, risky imports, weak consent sources, and campaigns with high complaint or unsubscribe rates.
- Send active first: Restart with recent clickers and buyers, then expand only after placement and engagement improve.
- Simplify content: Use one branded tracking domain, remove redirect chains, and test a simpler HTML version.
- Monitor daily: Track placement evidence, complaint signals, bounces, authentication results, and blocklist or blacklist status.
Where Suped fits
Suped's product is useful during recovery because it keeps the authentication and reputation work in one place. DMARC monitoring confirms which source is sending. Hosted SPF and SPF flattening help keep SPF under lookup limits. Hosted DMARC supports staged policy changes. Real-time alerts and issue steps reduce the time between a bad signal and a fix.
For MSPs and agencies managing many SFMC clients, the multi-tenant dashboard matters because the same problem often repeats across brands: an unverified sender, a forgotten business unit, a tracking domain change, or a list import that shifts complaint behavior. Having those domains side by side makes the pattern easier to catch.
Views from the trenches
Best practices
Start with mailbox warnings, then compare them with SFMC events and domain health data.
Segment to recently engaged contacts before changing domains, IPs, or creative templates.
Keep SFMC sending, bounce, tracking, and DKIM domains mapped in one shared note for audits.
Common pitfalls
Treating one seed test failure as proof can send teams toward the wrong repair work.
Changing to a fresh domain without fixing audience quality carries the same issue forward.
Ignoring link and phone patterns misses content signals that mailbox filters use heavily.
Expert tips
Save every spam folder banner text, because each wording points to a different root cause.
Compare engaged and inactive segments with the same creative to isolate reputation drag.
Use aggregate DMARC data to confirm whether every SFMC stream uses the right domain.
Marketer from Email Geeks says Gmail spam placement often comes down to source reputation or repeated content signals inside the message, so the repair path must test both.
2022-12-07 - Email Geeks
Marketer from Email Geeks says mailbox warning text helps separate recoverable content similarity issues from deeper domain reputation damage.
2022-12-07 - Email Geeks
The practical fix order
The direct answer is this: troubleshoot SFMC spam placement by proving whether the bad signal comes from identity, reputation, audience, or content, then repair only that layer first. Start with headers and authentication. Move to mailbox warnings and SFMC response data. Then isolate content and links. Only after those checks should you consider domain or IP changes.
If I had to pick the first three actions, they would be: collect full headers from inbox and spam copies, verify the SFMC sending identity against DMARC results, and compare engaged versus inactive segments with the same creative. That usually exposes whether the issue is technical, reputation-based, or caused by the mail people are receiving.
