Why are my Salesforce Marketing Cloud emails going to spam after switching to a private domain and what can I do to fix it?
Updated on 6 Oct 2026: We updated this guide for SFMC migration troubleshooting and warmup based on mailbox provider results.
The most likely reason your Salesforce Marketing Cloud emails started going to spam after switching to a private domain is that mailbox providers began judging a new sending identity. Your old setup had existing domain reputation. The new private domain or subdomain needs its own sending history, while providers can still consider the parent domain and sending IP. Authentication errors introduced during the switch are the first issue to rule out.
Fix it in this order: confirm whether the move changed the domain, the IP, or both; verify SPF and DKIM pass and that at least one authenticated domain matches the visible From domain under the applicable DMARC matching rules; send a real message through an email tester; split performance by recipient domain; slow volume to your most engaged audience; then check list quality and blocklist (blacklist) exposure. Do not start by blaming IPv6 or a footer warning unless the actual message headers show that those issues affect acceptance.
- Main cause: A new private SFMC domain needs reputation building, even when the IP pool does not change.
- First proof: Check authentication on a sent campaign, not only DNS records copied from setup notes.
- Recovery path: Use a controlled warmup and remove old or low-engagement recipients during recovery.
Why a new private domain changes sender reputation
When SFMC moves mail to a private domain, the authenticated identity changes. That change gives you brand control and authentication, but it also creates a new domain for providers to assess. A mailbox provider does not only ask whether the message passes SPF and DKIM. It also asks whether this domain has a history of sending wanted mail at this volume.
Gmail and Yahoo have enforced bulk sender requirements since 2024, and Outlook.com began enforcing authentication for high-volume senders in 2025. Those rules do not make a private domain untrusted by default, but a rushed migration can expose a DMARC domain mismatch, incomplete one-click unsubscribe handling, or weak reputation when normal campaign volume reaches the new identity.
Salesforce Marketing Cloud Engagement report showing performance by recipient domain.
Do not diagnose spam placement from opens alone
An open rate decline is a warning sign, but it is not enough by itself. Privacy protections and image blocking distort opens. Compare clicks, conversions, complaints, bounces, unsubscribe activity, and confirmed folder placement before diagnosing an inbox placement problem.
- Good signal: Clicks and conversions dropped in the same period as spam-folder reports.
- Weak signal: Only opens dropped while clicks, conversions, and replies stayed stable.
SFMC delivery reports show acceptance by the receiving server, not inbox placement. Check the actual folder in test mailboxes and request headers from affected recipients. For Microsoft recipients, distinguish personal Outlook.com or Hotmail accounts from Microsoft 365 corporate mailboxes; ask the corporate mail administrator to review message trace and quarantine when only one organization is affected. Salesforce explains the reporting limitation in its deliverability FAQ.
What changed when you moved to a private domain
A standalone Private Domain can authenticate the SFMC sending domain with SPF and DKIM when authenticated email sending is enabled, but it does not add a dedicated IP or brand link and image domains. A Sender Authentication Package (SAP) includes a Private Domain, dedicated IP, branded links and images, and Reply Mail Management. In either setup, the visible From domain, return-path domain, DKIM signing domain, and DMARC result need to make sense together. Adding a Private Domain does not replace the existing SAP tracking domain, so a new From address does not reset every reputation signal.
Before the switch
- Reputation: Some trust sat with Salesforce-managed sending infrastructure and older domains.
- Authentication: SPF and DKIM depended on the previous configuration; compare old and new message headers.
- Risk: The old identity had sending history, but existing list or reputation problems can carry forward.
After the switch
- Reputation: The new private domain must earn trust through positive engagement.
- Authentication: SPF and DKIM need to authenticate, and DMARC requires a domain match to the visible From address.
- Risk: Normal volume on day one can look abrupt, especially to Gmail and Yahoo.
This is why "SFMC is authenticated" is not enough. Confirm the actual sent message passes DMARC. Relaxed matching permits the same organizational domain; strict matching requires the exact From domain. Keep Suped's DMARC monitoring running while volume ramps. DMARC requires a passing result with the required domain match through SPF or DKIM, not necessarily both.
DNS lookups using example message identitiesbash
dig TXT selector._domainkey.email.example.com dig TXT bounce.email.example.com dig TXT _dmarc.email.example.com
Replace these example names with the DKIM selector and signing domain, Return-Path domain, and visible From domain in the sent message. Publish the account-specific records supplied by Salesforce for self-hosted DNS; use the supplied nameservers for delegated DNS. These lookup commands are diagnostic examples, not DNS records to publish.
Confirm whether the IP changed too
A standalone Private Domain does not include a dedicated IP. Confirm that authenticated email sending is enabled for the domain. It uses the account's existing IP configuration, so the domain can be new while the IP remains unchanged. SAP includes a dedicated-IP entitlement, but provisioning can reuse an existing dedicated IP. Mailbox providers are judging both a new domain and a new IP only when a new sending IP was actually assigned.
|
|
|
|---|---|---|
Standalone Private Domain | New domain, existing IP setup | Build domain history and verify authentication. |
SAP with new dedicated IP | New domain and new IP | Warm the domain and IP together. |
Private Domain on current dedicated IP | New domain, retained IP history | Protect the current IP while the domain earns trust. |
Match the recovery plan to the SFMC change.
Confirm the assigned IP in the Delivery Profile, then compare the actual sending IP in a delivered message header with pre-migration mail. Do not assume the IP changed because the From domain changed. If a dedicated IP is new, ramp volume gradually and keep daily volume consistent. If shared IP space stayed in place, focus first on the new domain, subscriber response, and message-level authentication. Salesforce confirms existing-IP reuse in its SAP configuration FAQ.
Check authentication on a sent SFMC message
Before changing templates, subject lines, or cadence, test the actual message that left SFMC. DNS can look correct while the sent message still fails because the wrong sender profile, DKIM selector, bounce domain, or From domain is in use. Test a real campaign send using the affected Sender Profile, Delivery Profile, and Send Classification, not only a template preview. Use direct test mailboxes so forwarding or a corporate gateway does not obscure the original authentication results.
Also run the sending domain through Suped's domain health check to review DMARC, SPF, DKIM, and basic DNS. Use the exact DKIM selector from the message when checking DKIM. The results support the investigation alongside mailbox-provider performance data.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
|
|
|
|---|---|---|
DMARC | Pass and domain match | Whether a passing SPF or DKIM result matches the visible From domain. |
DKIM | Selector and signing domain | |
SPF | Return-path result | Whether the sending IP is authorized by the Return-Path domain's SPF record. |
Unsubscribe | List-Unsubscribe, List-Unsubscribe-Post, and body link | Whether marketing mail meets bulk sender expectations. |
Recipient domain | Gmail, Yahoo, Microsoft |
Checks to run on a real SFMC campaign message.
Suped's product helps here when the issue is not a single DNS typo. Suped connects DMARC aggregate data with source detection, authentication pass rates, and issue-level remediation steps, so SFMC failures are separated from other senders using the same domain. Aggregate reports describe authentication and policy handling, not spam-folder placement, and arrive after receivers generate them.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Check migration DNS and SFMC bounce reasons
If the switch also changed SAP, check reverse DNS (PTR) for every sending IP and affected Business Unit. The PTR hostname must resolve back to the sending IP. Retiring the old SAP DNS can break that lookup; request a PTR correction through Salesforce Support. Keep old DNS active while it supports existing messages or other Business Units. Salesforce's SAP migration guidance explains these dependencies.
Query the _Bounce data view in Automation Studio for affected JobIDs. Compare Domain, BounceCategory, SMTPCode, and SMTPBounceReason before and after the switch. These records identify confirmed delivery failures; accepted mail placed in spam does not create a bounce.
|
|
|---|---|
FCrDNS or PTR failure | Check reverse and forward DNS with Salesforce Support. |
SPF or DKIM failure | Verify the message identities and provisioned DNS. |
Temporary deferral or throttling | Reduce volume for that provider and inspect the full response. |
Policy or reputation rejection | Review the exact reason before changing authentication or audience volume. |
Match the receiving-server response to the next investigation.
Check branded tracking URLs and unsubscribe links for DNS resolution and valid HTTPS certificates. If configuration failures persist, send Salesforce Support the MID, affected JobIDs, sending IPs, complete headers, and bounce reasons.
How to separate warmup from a deeper problem
A domain warmup problem often has this pattern: authentication passes, but inbox placement and engagement are weaker on the new domain, especially at large mailbox providers. Temporary deferrals can also occur as volume increases. Persistent complaints, poor engagement, blocks, or domain-specific rejections require list and reputation investigation. Standard SFMC reports do not identify individual spam-trap addresses.
For a recovery plan, do not send the full B2B list again. Plan for several weeks of gradual reputation building, with progress determined by provider response rather than a fixed deadline. A fuller domain warm-up plan should start with recent genuine clickers and active customers. Use opens only as a secondary signal because privacy protections inflate them and security scanners inflate clicks. Widen only when complaints, bounces, and provider deferrals remain controlled.
Example engagement windows for recovery
These example windows set audience priority, not universal risk thresholds. Adjust them to normal purchase and email frequency.
Start here
0-30 days of activity
Recent verified clicks, purchases, or replies.
Review before adding
31-90 days of activity
Confirmed interest beyond opens alone.
Hold during recovery
91-180 days of activity
Older activity needs stronger evidence of current interest.
|
|
|
|---|---|---|
Initial sends | Small group with recent verified activity | Establish provider-specific baseline results. |
Repeat | Similar engaged recipients | Maintain consistent volume while results stabilize. |
Expand | More recipients with confirmed current interest | Increase each provider's volume only when results hold. |
Hold | Current recovery audience | Stop expansion if complaints, bounces, or deferrals rise. |
Resume | Broader permission-based active audience | Return to normal volume gradually after stable results. |
Advance each stage only when provider results support it.
For Gmail, keep the provider-reported daily spam rate below 0.1% and avoid 0.3% or higher, as stated in Google's sender guidelines FAQ. SFMC campaign complaint rates use different data and denominators, so do not treat them as the same measurement. Reduce volume for the affected provider when complaints or deferrals rise.
What to pause
- Cold segments: Suppress recipients with no verified clicks, purchases, replies, or other genuine activity in 180 days; adjust the window to your normal sales cycle.
- Risky imports: Hold old event lists, partner lists, and unclear consent sources.
- Full-volume sends: Delay broad campaigns until core providers show stable clicks and conversions.
Authentication issues that imitate reputation problems
Authentication failures can look like reputation problems because the symptom is the same: junk placement, lower engagement, and more complaints from internal stakeholders. The difference is that authentication problems show up clearly in headers and DMARC reports.
For bulk marketing mail, require SPF and DKIM to pass and require DMARC to pass because at least one authenticated domain matches the visible From domain under its DMARC matching rules. Gmail, Yahoo, and Outlook.com high-volume sender requirements make authentication a baseline, though passing authentication does not guarantee inbox placement. For Gmail and Yahoo bulk marketing mail, verify RFC 8058 one-click handling through List-Unsubscribe and List-Unsubscribe-Post, plus a visible body unsubscribe link. Honor Gmail unsubscribe requests within 48 hours. Salesforce's deliverability FAQ is a useful starting point when spam placement and bounces appear after an SFMC change.
A Private Domain can still use bounce.[SAP domain] as its Return-Path. When SAP and Private Domain use different organizational domains, SPF can pass without the required DMARC domain match. A passing DKIM signature with the correct domain match is sufficient for DMARC. To add SPF domain matching too, ask Salesforce Support about Multi-Bounce Domains and verify the required bounce-domain MX and SPF records before activation. Retest every affected Private Domain afterward.
DMARC record with aggregate reportingdns
_dmarc.email.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The current DMARC standard, RFC 9989, makes the old pct tag historic. Remove pct from new and maintained records instead of using it for staged enforcement. Use p=none when introducing monitoring for an unprotected domain, verify legitimate sources, then choose policy based on the reports. Keep a working quarantine or reject policy while fixing SFMC; weakening it does not improve the placement of mail that already passes DMARC.
A missing rua tag does not normally explain spam placement by itself. It does mean you lack aggregate DMARC visibility, which makes the investigation slower. Reports identify SFMC authentication failures and other failing sources; they do not measure whether those sources damaged domain reputation. For delegated DNS, request the reporting-record change through Salesforce Support. For self-hosted DNS, have your DNS administrator make it.
Footer warnings need context
Automated scanners get unsubscribe checks wrong, especially when the body link needs account context. Verify the actual RFC 8058 one-click endpoint processes a request without login or confirmation, and that the visible body link works. Header presence alone does not prove unsubscribe handling works.
IPv6 support is not a general requirement for inbox placement. If SFMC sends over IPv4, a missing IPv6 DNS record is not a reason to change the setup. If the actual SMTP connection uses IPv6, authentication and forward/reverse DNS must work for that IPv6 address. Investigate an IPv6-specific rejection before dismissing it.
If the original campaign is delivered but replies go to junk, investigate that as a separate path. Check the Reply Mail Management forwarding configuration, confirm the forwarded message headers, and allowlist the required RMM IP addresses within the receiving corporate mail system when needed. A reply-handling problem does not prove the outbound SFMC campaign has the same placement problem.
Do not ignore list quality and blocklist signals
A private domain migration exposes list quality. Recipients who tolerated old mail can react differently when the sending identity changes. Old B2B lists are especially risky because people change jobs, mailboxes get recycled, and abandoned addresses can turn into traps.
This is where blocklist monitoring matters. A domain or IP appearing on a major blocklist (blacklist) does not always cause every message to land in spam, but it is a strong signal that reputation needs attention. Suped's blocklist monitoring keeps those signals beside DMARC and authentication data, so the root cause is easier to isolate.
Blocklist checker
Check your domain or IP against 144 blocklists.
- Trap risk: Old, inactive, or unclear-source addresses can damage the new private domain quickly.
- Complaint risk: A sudden brand or domain change can confuse recipients who previously recognized the sender.
- Provider risk: One mailbox provider can degrade while another remains healthy, so segment reports by domain.
Flowchart for troubleshooting SFMC private domain spam placement.
How Suped supports the recovery workflow
Suped's product is relevant when the problem spans DMARC, SPF, DKIM, blocklists (blacklists), and ongoing sender monitoring. The immediate SFMC fix still requires good sending decisions, while Suped provides the technical evidence needed to separate authentication trouble from reputation trouble.
Suped can show whether SFMC is an authenticated source, whether other sources are failing, whether a DMARC policy change is risky, and whether a domain or IP is listed. Its reports support authentication fixes; SFMC metrics and recipient evidence determine the sending-volume decisions.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Manual workflow
- Data split: Authentication, DNS, blocklists, and campaign metrics sit in separate places.
- Fix path: Teams decide next steps by reading headers and comparing reports manually.
- Risk: A small SFMC setup error can stay hidden until deliverability drops.
Suped workflow
- Data view: DMARC, SPF, DKIM, blocklist, and source data sit together.
- Fix path: Automated issue detection gives concrete steps for each domain.
- Risk: Alerts flag reported authentication issues so teams can investigate before increasing campaign volume.
A practical SFMC recovery checklist
Work through this checklist before reverting the domain or making broad creative changes. If the migration introduced a confirmed configuration fault, coordinate a rollback with Salesforce Support. Otherwise, switching identities again interrupts reputation building without fixing list or sending problems.
- Identify: Confirm whether the domain, sending IP, or both changed, and verify PTR DNS if SAP changed.
- Authenticate: Send a real SFMC campaign message, confirm SPF and DKIM pass, and verify DMARC passes through at least one authenticated domain match.
- Report: Add DMARC aggregate reporting so failures are tied to actual sources.
- Segment: Break SFMC performance down by recipient provider and inspect bounce reasons for affected JobIDs.
- Warm: Start with the most engaged audience and widen only when metrics hold.
- Suppress: Suppress inactive, risky, or unclear-consent records during recovery and keep opt-outs suppressed in future imports.
- Monitor: Watch blocklist (blacklist) status beside provider complaints, bounces, clicks, and conversions.
If the problem is still unclear after those steps, use a structured SFMC spam troubleshooting process. Keep the investigation evidence-led. Do not chase every scanner warning when campaign metrics point to domain reputation or list quality.
Views from the trenches
Best practices
Warm the new private domain with engaged recipients before moving normal campaign volume.
Keep DMARC aggregate reporting active so failures are tied back to real sources.
Compare clicks and conversions with opens so reporting noise does not hide placement.
Common pitfalls
Assuming a private domain inherits old trust can leave sender reputation untested.
Chasing footer scanner failures wastes time when engagement needs attention first.
Sending to dormant B2B lists during recovery adds complaint and trap risk early.
Expert tips
Chunk large SFMC sends across business days and watch mailbox-specific response.
Separate Gmail, Yahoo, Microsoft, and corporate domains before judging the program.
Treat missing DMARC RUA as a visibility gap first, not proof of spam placement alone.
Marketer view
Marketer from Email Geeks says open rates alone do not prove spam placement because click and conversion trends give a better read on mailbox access.
2024-03-27 - Email Geeks
Marketer view
Marketer from Email Geeks says a new private SFMC domain still needs domain warming, even when the IPs remain unchanged.
2024-03-27 - Email Geeks
