// fix guide · Salesforce Marketing Cloud

Fix Salesforce Marketing Cloud emails going to spam

When Marketing Cloud Engagement sends start landing in spam, the cause is almost always how authentication is provisioned, not your subject line. Without the Sender Authentication Package, your bounce and link-wrapping domains stay on Salesforce-owned hosts like exacttarget.com and mc.pd25.com, so SPF never aligns and DKIM signs the wrong domain. This guide covers the SAP versus Private Domain difference, the default-domain alignment trap, dedicated IP warmup, multi-bounce domain, and Reply Mail Management, plus how to test a real Marketing Cloud send with Unspam. Note that Account Engagement (Pardot) is a separate product that authenticates differently.

Run a free spam test → How to test your sends

// why it happens

Why Salesforce Marketing Cloud emails land in spam.

Your bounce and link domains are still Salesforce-owned (exacttarget.com)

Without the Sender Authentication Package (SAP), Marketing Cloud sends with a Return-Path on a Salesforce host such as bounce.s7.exacttarget.com or bounce.s10.mc.pd25.com, and wraps every link and image URL through Marketing Cloud domains. SPF passes against Salesforce's domain but never aligns with your From domain, and the wrapped links read as a mismatch to Gmail. The fix is SAP, which provisions an authenticated Private Domain that signs DKIM as your domain and brands link and image wrapping with it. Confirm the d= domain and link domain on a live send, not just in DNS.

You bought a Private Domain but not full SAP, so links still say Marketing Cloud

Private Domain on its own is an authentication-only add-on: it applies SPF and DKIM to a sending subdomain but does not wrap links or images and does not include a dedicated IP. The SAP domain (or default Marketing Cloud domain) is still used for image URLs, View as Webpage, CloudPages, and link wrapping. Filters see your From domain on the envelope but a different domain on every clickable link, which weakens trust. If you want full branding, you need the complete SAP configuration, not just Private Domain.

SPF alignment is off until someone enables multi-bounce domain

Even after SAP, the bounce domain defaults to a static value tied to your SAP domain, so the Return-Path may still not match your visible From domain and SPF alignment fails. Salesforce has a multi-bounce domain feature that lets the bounce domain align to a domain like bounce.yourdomain.com so SPF aligns, but the toggle is not visible in the UI: you must ask Salesforce support to turn it on. DKIM alignment alone is enough for DMARC to pass, but enabling multi-bounce domain gives you a second aligned identifier and cleaner DMARC reports.

DMARC was never published, because Salesforce does not create it for you

When Salesforce configures your Private Domain or SAP domain in DNS, there is no default DMARC record added to the sending domain. Many Marketing Cloud accounts run for years with aligned DKIM but no DMARC policy on the From domain at all. Since the February 2024 Gmail and Yahoo bulk-sender rules, senders above 5,000 messages a day to Gmail must publish at least p=none. Add a v=DMARC1 record with an rua reporting address yourself, then tighten the policy once DKIM and SPF alignment read clean on a real send.

You stood up a dedicated IP and blasted full volume on day one

A dedicated IP is part of SAP and is generally only worthwhile above roughly 250,000 messages a month, the volume Salesforce recommends to keep an IP's reputation warm. A brand-new IP has zero history with Gmail and Yahoo, so a full-list blast looks like a spam cannon. Warm it over 4 to 6 weeks: start around 500 messages a day to your most engaged subscribers, then raise volume gradually each step while watching complaints. Below that volume threshold, a thinly used dedicated IP can perform worse than Salesforce's warmed shared pool.

Replies bounce or vanish without Reply Mail Management

By default, replies to a Marketing Cloud send go to a no-reply Salesforce address and are discarded, and a From address that cannot receive mail is itself a negative signal to some filters. Reply Mail Management (RMM), part of SAP, routes replies to a managed mailbox, filters out-of-office and bounce noise, and can forward genuine replies to your team. Configure RMM so your From address accepts mail and unsubscribe-by-reply works, rather than sending from an address that black-holes every response.

// authentication

How Salesforce Marketing Cloud authenticates your mail.

Marketing Cloud signs and bounces mail on infrastructure it controls, so there is nothing to paste into your root SPF for alignment. Authentication hinges on one thing: whether you have provisioned an authenticated Private Domain (standalone or as part of the Sender Authentication Package) and published your own DMARC record. You can sanity-check each record below with the Unspam SPF, DKIM, and DMARC checkers before and after the change.

record	default	the problem	the fix
DKIM	Without a Private Domain or SAP, Marketing Cloud signs DKIM with a Salesforce-owned domain, not your From domain. You cannot upload self-generated keys; Salesforce holds the private key and gives you records to publish.	The DKIM d= domain does not match your From domain, so DMARC alignment fails and the message reads as sent on behalf of a Salesforce domain.	Provision an authenticated Private Domain (or full SAP) so DKIM signs as your subdomain, then publish the exact CNAME or TXT records Salesforce supplies (for example s1._domainkey.email.yourbrand.com), or delegate the subdomain to the Salesforce (ExactTarget) nameservers Salesforce gives you if they manage your DNS. Confirm the signature with the Unspam DKIM checker.
SPF	The Return-Path (bounce) domain is a Salesforce host such as bounce.s7.exacttarget.com or bounce.s10.mc.pd25.com, so SPF passes but against Salesforce's domain rather than yours.	SPF passes without alignment, which is why DMARC reports show SPF pass but SPF alignment fail on default sends. Adding a Salesforce include to your root SPF changes nothing.	Ask Salesforce support to enable multi-bounce domain so the Return-Path can align to a domain like bounce.yourbrand.com. It is off by default and the switch is not exposed in the UI; DKIM alignment alone still satisfies DMARC in the meantime. Use the Unspam SPF checker to confirm your published record stays valid.
DMARC	Salesforce does not create a DMARC record when it configures your Private Domain or SAP domain in DNS, so many accounts have none.	Gmail and Yahoo expect at least p=none on the From domains of senders above 5,000 messages a day, and a quarantine or reject policy without aligned DKIM can send your own campaigns to spam.	Publish v=DMARC1; p=none with an rua address yourself at _dmarc.yourbrand.com, confirm DKIM aligns on a live send, then tighten to quarantine or reject once reports run clean. Marketing Cloud does not capture or report DMARC failures, so rely on your own rua feed and the Unspam DMARC checker.
Link and image wrapping	Links, images, View as Webpage, and CloudPages route through Salesforce-owned domains until full SAP Account Branding is active. Private Domain alone does not change this.	Every clickable link points at a Marketing Cloud domain you do not control while your From shows your brand, a mismatch some filters treat as phishing-adjacent.	Configure full SAP Account Branding so link and image wrapping uses your authenticated domain; standalone Private Domain authenticates the envelope but leaves wrapping on the SAP or default domain.

// test your real sends

How to test a Salesforce Marketing Cloud campaign with Unspam.

Marketing Cloud's preview and the test send from the email editor do not behave like a production send: tracking, wrapped links, and routing can differ. Unspam does not connect to the Marketing Cloud API, so the only honest test is a real send to a seed address using your normal send path.

01
Get your Unspam seed address

Start a spam test or inbox placement test in Unspam and copy the seed address it generates. Inbox placement tests include addresses across Gmail, Outlook, Yahoo, Zoho, ProtonMail, and AOL so you see placement per provider.
02
Add the seed address in Marketing Cloud

In Email Studio, create a Data Extension or list named something like Deliverability Seeds and add the Unspam address as a subscriber, or add it to an existing test audience you can target directly.
03
Send the real email, not a preview

Use a Guided Send or User-Initiated Send of the actual email to the seed audience through your normal sender profile, so it leaves on your real sending domain, IP, and wrapped links. Avoid the editor's Test Send, which can route and wrap differently from production.
04
Confirm it came from your authenticated domain

In Unspam, check that DKIM signs your subdomain (not a Salesforce domain), that the Return-Path aligns if you enabled multi-bounce domain, and that wrapped links use your branded domain rather than a Marketing Cloud host.
05
Read the results in Unspam

Review the spam score, SPF, DKIM, and DMARC results on the live send, blacklist and HTML checks, per-provider Inbox, Promotions, Spam, or Missing placement, client previews including dark mode, and the AI eye-tracking heatmap. The AI fix assistant flags what to change before your next campaign.

// platform gotchas

Salesforce Marketing Cloud features that quietly affect delivery.

Domain verification is not authentication

The Register Domain button in From Address Management generates a TXT token you add to DNS, but that only proves you own the domain so Marketing Cloud will let you send as it. It does not apply SPF, DKIM, or DMARC. A domain can be verified and still fail every alignment check. Authentication requires a Private Domain or full SAP, not just verification.

Multi-bounce domain is invisible until support enables it

The setting that aligns your bounce domain to a domain like bounce.yourbrand.com is not exposed in the Marketing Cloud UI. You cannot self-serve it; you must open a case with Salesforce support and ask them to turn multi-bounce domain on. Until then, your Return-Path stays on the SAP domain and SPF alignment will not pass.

Private Domain does not wrap links, only SAP does

Teams often buy Private Domain expecting fully branded mail, then find links and images still resolve through a Marketing Cloud domain. Link and image wrapping, CloudPages, and View as Webpage branding come only with full SAP Account Branding. If branded links matter for your reputation, confirm you have SAP, not just Private Domain.

Account Engagement (Pardot) is a different product

If you actually send through Account Engagement rather than Marketing Cloud Engagement, the setup differs: it signs DKIM with your sending domain by default, uses a Return-Path like bounce.s7.exacttarget.com that is not SPF-aligned unless you request a custom return path, and does not supply DMARC authentication. Do not apply Marketing Cloud SAP steps to a Pardot account; check which product is sending first.

// FAQ

Salesforce Marketing Cloud deliverability, answered.

Why does my Marketing Cloud mail show as coming from a Salesforce domain?

Your account has not provisioned an authenticated Private Domain, so DKIM signs with a Salesforce-owned domain and links wrap through Marketing Cloud hosts like exacttarget.com. Set up a Private Domain to align DKIM as your subdomain, and full SAP Account Branding to brand link and image wrapping. Domain verification alone does not fix this.

Do I need to add Salesforce to my domain's SPF record?

No. Marketing Cloud controls the Return-Path domain, so SPF is evaluated against Salesforce's infrastructure and already passes without alignment. Adding an include to your root SPF does nothing for alignment. What aligns SPF is asking Salesforce support to enable multi-bounce domain, and DKIM alignment via a Private Domain already lets DMARC pass on its own.

What is the difference between Private Domain and the Sender Authentication Package?

Private Domain is an authentication-only add-on: SPF and DKIM on a sending subdomain, no dedicated IP and no link or image branding. SAP is the full bundle: Private Domain plus a dedicated IP, Account Branding for link and image wrapping, and Reply Mail Management. Salesforce recommends a dedicated IP for senders above roughly 250,000 messages a month.

Will a dedicated IP get me out of the spam folder?

Only if you have the volume to keep it warm. A dedicated IP comes with SAP and generally makes sense above about 250,000 messages a month. A new IP must be warmed over 4 to 6 weeks starting around 500 messages a day to engaged subscribers, and a thinly used dedicated IP can perform worse than Salesforce's warmed shared pool. Fix authentication, list hygiene, and complaint rate before reaching for a dedicated IP.

Can Unspam connect to my Marketing Cloud account and test sends automatically?

No. Unspam does not integrate with the Marketing Cloud API or any other ESP API. The workflow is manual by design: add Unspam's seed address to a Data Extension or list, run a real Guided Send to it, and read the results in Unspam. That is the only way to test the exact mail your subscribers receive, including authentication and wrapped links.

I use Pardot, not Marketing Cloud Engagement. Do these steps apply?

Not directly. Account Engagement (formerly Pardot) is a separate product that signs DKIM with your sending domain by default and uses a Salesforce bounce domain that is not SPF-aligned unless you request a custom return path. It also does not supply DMARC authentication. Confirm which product sends your mail, then follow that product's authentication path rather than mixing the two.

Salesforce Marketing Cloud platform details were verified against publicly available documentation in June 2026 and may have changed since. Salesforce Marketing Cloud is a trademark of its respective owner. Unspam is not affiliated with or endorsed by Salesforce Marketing Cloud.

// see where you land

Test your next Salesforce Marketing Cloud campaign before your subscribers do.

Start a free spam test → Inbox placement test