The same person got the same campaign three times, then reported us as spam
When your Subscriber Key is a CRM Contact ID instead of the email address, one address can live under multiple keys and SFMC treats each as a separate contact. Data Extension sends do not dedupe by email unless you enable it, and triggered sends never dedupe, so a person receives the same campaign once per record, hits the spam button, and the complaint spike drives Gmail and Yahoo to filter you.
The fix
For Data Extension sends, turn on the Remove Duplicates option in audience selection; it is off by default and dedupes by email address, catching one address that appears under multiple SubscriberKeys within that send. List sends always dedupe automatically at send time, but this checkbox does nothing for Journey Builder email activities or triggered sends, which have no deduplication. The durable fix is upstream: standardize on one stable ContactKey/SubscriberKey, normalize duplicates in your CRM or CDP so each person is one golden record, and audit the All Subscribers list for the same email under multiple keys.
Gmail started bulk-filtering us and it turned out our promo was flagged Transactional
A Transactional Send Classification strips the visible unsubscribe link, the physical address block, and the one-click List-Unsubscribe header by default, which is correct for a receipt but a compliance failure once the message carries promotional content. Teams misclassify commercial mail as transactional by misclick or to suppress opt-outs, and since February 2024 that missing one-click header trips the Gmail and Yahoo bulk-sender rules for anyone over 5,000 messages a day.
The fix
Audit your Send Classifications against what each email actually contains and send anything promotional under a Commercial Send Classification. A Commercial classification is what makes Marketing Cloud add the visible unsubscribe link and inject the List-Unsubscribe and one-click List-Unsubscribe-Post headers, which ship on all commercial sends and cannot be disabled. Separately, confirm the Delivery Profile used on the send has header/footer content configured with your CAN-SPAM physical address, since that block comes from the Delivery Profile, not the classification. Lock down who can choose the Send Classification and edit Sender and Delivery Profiles, and reserve Transactional strictly for genuine receipts, password resets, and order confirmations.
Our delivery tanked and we never touched a thing: it was a stranger on our shared IP
On SFMC's shared IP pool your reputation is fused to every other tenant, so a noisy neighbor blasting spam or bounces triggers B2C blocks at Yahoo, AOL, and Microsoft and deferrals at Gmail even with perfect authentication. Support will confirm Deliverability and Abuse are engaged but will not name the offending sender or the remediation underway, which makes it feel unfixable.
The fix
Open a case and attach evidence that separates your sending from the pool's collapse: bounce logs, SMTP deferral and block codes, your complaint rate, and blocklist status showing the whole range moved together while your metrics stayed stable. Escalate through Support and your account team and ask them to either move you to a healthier shared pool (granted at Salesforce's discretion, so treat it as a request) or start your dedicated IP migration through your Account Executive. On classic Email Studio, warm the new IP manually over 4 to 6 weeks, starting around 500 messages a day to your most engaged subscribers and raising volume gradually while watching complaints. On Marketing Cloud Next, Salesforce automates dedicated IP warmup over roughly the first 35 days.
After we migrated to Marketing Cloud, Gmail delivery went from instant to hours late
Post-migration senders on the SFMC shared pool report mail sitting in queue or getting repeatedly deferred by Gmail, so messages arrive hours late even though SPF, DKIM, and DMARC all pass. Gmail applies extra scrutiny to the high marketing volume on the shared IP, and time-sensitive transactional mail queued behind bulk campaigns gets throttled with it.
The fix
Pull the full email headers and read the Received timestamps from bottom to top to prove where the delay is, at SFMC before handoff or at Gmail deferring repeatedly with a 4xx, rather than guessing. Confirm a Gmail-side deferral against your domain and IP reputation in Google Postmaster Tools, since Marketing Cloud does not surface deferral reasons. If transactional mail is the casualty, separate it onto its own subdomain and routing, a distinct Sender Profile and transactional Send Classification, and at volume a dedicated IP or the Transactional Messaging API, so it is not stuck behind campaign queues. If the shared pool itself is deferring, escalate to Salesforce for a pool move or dedicated IP, and confirm you are not warming a new IP into full volume too fast.
Marketing Cloud User-Initiated Sends go to spam while Journey emails mostly reach the inbox
Senders with SPF, DKIM, and DMARC all configured still see User-Initiated Sends land in spam, with some Journey emails following. User-Initiated Sends often target inactive or frustrated recipients, which drags domain reputation fast, and that damage spills into Journeys that share the same sending domain and IP.
The fix
This is not an authentication config problem, it is a reputation and audience problem. Check alignment, not just setup: SPF and DKIM can pass while the visible From domain, Return-Path, and signing domain are misaligned, which providers still treat as higher risk. Suppress unengaged recipients on User-Initiated Sends and delete contacts who signed up months ago and never opened, so those sends stop generating complaints that bleed into your Journeys. Keep templated content short and purpose-driven, and if you are on a dedicated IP send consistently, since gaps in volume reset your sender reputation.
