How to verify SFMC IP warming and domain reputation when sharing an IP address?
Matthew Whittaker
Co-founder & CTO, Suped
Published 4 Jun 2025
Updated 23 May 2026
9 min read
Summarize with
The direct answer is that you verify SFMC IP warming in two separate tracks: ask Salesforce Support for the sending IP and any available Reputation Audit or deliverability review, then prove the new From domain's reputation with authentication results, Gmail placement, bounce data, complaints, and domain-level reporting. A warm shared IP does not make a new From Address subdomain warm.
I treat this as a domain reputation problem first and an IP problem second. If the IP is shared only between two Enterprise IDs owned by the same company, that differs from a broad pooled IP. Gmail still evaluates the visible sender domain, DKIM domain, mail history, engagement, complaints, and authentication.
- Support request: Ask Salesforce for the exact sending IP, current deliverability status, and whether a Reputation Audit is available for the EID and SAP.
- Domain proof: Check SPF, DKIM, DMARC, tracking domain, bounce domain, and return-path match for the new From subdomain.
- Mailbox evidence: Compare Gmail placement against other mailbox providers, not only aggregate opens and clicks.
- Volume control: If 57,000 messages have already gone out, slow Gmail volume, send to engaged recipients, and fix authentication gaps before scaling again.
The direct verification path
The SFMC item people usually remember is called a Reputation Audit. I do not rely on it as the only proof. I open a support case and ask deliverability support to confirm the sending IP health, recent reputation signals, and whether the new Enterprise ID is using the intended Sender Authentication Package.
Salesforce's Salesforce warming guidance is also worth reading before the case is filed, because it frames warm-up as a planned sending pattern, not a checkbox removed by another account's prior IP use.
Ask for these exact items
- IP inventory: The sending IP or IPs used by the new Enterprise ID, plus whether they are shared only inside the company or in a broader pool.
- SAP mapping: The Sender Authentication Package, private domain, From Address domain, bounce domain, and tracking domain tied to the sends.
- Audit scope: Whether the review covers only authentication and reputation score signals, or also includes mailbox placement and sending pattern feedback.
- Date range: The exact dates, campaigns, job IDs, and Gmail-heavy segments that produced the spam folder symptoms.
A support answer that says the IP is warm is useful, but it does not close the case. The next question is whether the new subdomain has earned trust at Gmail under its own identity.
Why the shared IP is only half the story
There are two common SFMC sharing patterns that get mixed together. One is a real pooled shared IP used by unrelated senders. The other is an IP shared between Enterprise IDs under the same organization. The second pattern gives you more control, but it still creates domain reputation questions.
Sender Profiles, Delivery Profiles, SAPs, and private domains can be shared across parts of an SFMC enterprise structure. Visible configuration in one Business Unit or Enterprise ID does not prove isolation. I verify the actual profile mapping and final headers.
Salesforce Marketing Cloud screen showing sender and delivery profile checks.
Same company IP sharing
The IP is used by more than one Enterprise ID, but the senders have the same corporate owner. This gives the team a clearer path to coordinate volume, list quality, and suppression rules.
- Control: Internal teams can compare calendars and prevent overlapping Gmail-heavy sends.
- Risk: A weak new domain can still perform poorly even if the IP has stable history.
- Action: Warm the new domain with engaged recipients and keep the older EID's volume steady.
True pooled shared IP
The IP carries traffic from senders outside the organization. The sender has less visibility into traffic quality and less control when another sender creates a reputation hit.
- Control: The platform manages the pool and separates senders using internal rules.
- Risk: Mailbox providers still evaluate the sender domain and engagement signals.
- Action: Prove the domain and authentication are healthy before changing IP strategy.
Do not skip domain warm-up
A warm IP does not give a new From Address subdomain an inherited Gmail reputation. I still warm the domain, especially when Gmail placement is already landing in Spam. Reduce Gmail volume, send first to recent openers and clickers, and add volume only after placement stabilizes.
What to verify in SFMC
Start inside SFMC, then confirm what arrives in the mailbox. Configuration screens can look correct while headers show a different return-path, unsigned From domain, or DKIM signature tied to an unexpected domain.
After the SFMC checks, send a live message to an email tester and inspect the result next to Gmail seed inboxes. I want to see SPF pass, DKIM pass, DMARC pass, and a From domain that lines up with the brand's sending identity.
Header fields to inspecttext
From: Brand <news@mail.brand.example> Return-Path: bounce@mail.brand.example DKIM-Signature: d=mail.brand.example; s=selector1; Authentication-Results: mx.google.com; spf=pass; dkim=pass; dmarc=pass Received-SPF: pass
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
For a Gmail spam issue in SFMC, the strongest evidence is headers, SFMC job IDs, and domain-level results collected at the same time. If the live test fails authentication or shows a domain mismatch, fix that before blaming the IP.
- Pull IP: Confirm the exact sending IP used by the affected SFMC jobs, not the IP listed in a generic setup document.
- Confirm SAP: Match Sender Profiles, Delivery Profiles, Send Classifications, private domain, bounce handling, and tracking domain.
- Verify auth: Check SPF, DKIM, and DMARC on real received mail, then compare the result with DNS.
- Compare domains: Separate Gmail, Microsoft, corporate, and consumer domains so Gmail does not get hidden inside aggregate opens.
- Escalate clearly: Send Salesforce the IP, headers, job IDs, affected dates, Gmail samples, and the volume already sent.
If the symptom is isolated to Gmail, follow a Gmail-specific path as well. Pair the above checks with SFMC spam troubleshooting so content, engagement, and recent list source changes are tested instead of blaming the IP too early.
How to read the evidence
The pattern matters more than any one signal. Lots of opens at non-Gmail domains tells me the campaign is not globally blocked. Gmail Spam placement points to sender identity, audience quality, or recent volume. A shared IP with good history reduces one risk, but it does not erase a weak new domain history.
|
|
|
|---|---|---|
Gmail Spam | Domain trust issue | Slow Gmail |
Other inboxes | Provider-specific issue | Segment results |
Auth pass | Baseline OK | Check engagement |
Auth fail | Config issue | Fix DNS |
New domain | No history | Warm gradually |
Compact evidence map for shared IP and domain reputation checks.
I also check for blocklist and blacklist signals, but a clean blocklist result does not prove Gmail trusts the domain. Blacklist checks answer whether a listing exists, not whether Gmail likes the mail stream.
When to slow the warm-up
Practical action bands for Gmail placement and new domain reputation during SFMC warm-up.
Normal
Continue
Inbox placement is stable and complaints stay low.
Review
Hold
Authentication passes, but Gmail placement is uneven.
Slow
Reduce
Gmail Spam placement grows after a volume increase.
Pause
Stop
Authentication fails, bounces rise, or complaints spike.
When 57,000 messages have already been sent from the new Enterprise ID, I stop thinking of this as a clean pre-warm. The sender has already created a reputation trail. The work is now to improve that trail with cleaner segments, smaller Gmail batches, and consistent authentication.
A warm-up plan for the new From domain
For new domain plus same IP, I warm the domain. The first audience is not the biggest list, the newest acquisition source, or an old reactivation segment. It is the people most likely to open, click, and avoid marking the message as spam.
If the domain change came with a new SFMC setup, use a new subdomain warm-up plan instead of assuming the older Enterprise ID carries the new one.
Initial DMARC recorddns
Host: _dmarc.mail.brand.example Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@brand.example; pct=100
Flowchart showing how to verify SFMC shared IP and domain warm-up evidence.
- Segment first: Use recent Gmail openers and clickers before adding colder Gmail recipients.
- Ramp slowly: Increase Gmail volume only after placement, bounces, and complaints stay stable.
- Hold often: If Gmail placement worsens after a jump, return to the previous stable volume.
- Separate traffic: Keep promotional spikes, reactivation sends, and risky segments away from the warm-up stream.
- Document changes: Track date, SFMC job ID, audience type, Gmail volume, placement, bounce rate, and complaint signals.
Where Suped fits
This is where Suped's product is useful. A one-time audit helps with a snapshot, but the ongoing problem is proving whether SPF, DKIM, DMARC, blocklist signals, and sending sources stay healthy after each SFMC change. Suped is the best overall DMARC platform for most teams that need those checks in one place.
I use the domain health checker for a fast view of DNS health, then DMARC monitoring to watch real authentication results by sender. If IP or domain reputation is part of the investigation, Suped's blocklist monitoring helps catch blocklist (blacklist) changes that would otherwise be missed between campaign checks.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For SFMC specifically, the practical value is source attribution. If DMARC reports show the expected SFMC source with DKIM and SPF matching the sender identity, the next path is engagement, Gmail placement, and volume. If reports show unexpected sources, domain mismatch, or authentication failures, those fixes come first.
Useful Suped workflows here
- Issue detection: Automated findings point to broken SPF, DKIM, DMARC, forwarding, and domain matching problems with steps to fix.
- Real-time alerts: Authentication failure spikes can be caught while the warm-up is still being adjusted.
- Hosted records: Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS reduce DNS friction for teams with limited access.
- Multi-domain view: MSPs and enterprise teams can compare multiple sending domains and Enterprise IDs in one dashboard.
Suped will not make Gmail trust a new domain by itself. It gives the evidence needed to stop guessing: source, authentication result, policy state, and blacklist or blocklist changes during warm-up.
Views from the trenches
Best practices
Ask support for the exact IP scope before treating a shared IP as a warm-up exemption.
Warm each new From domain with engaged users even when the sending IP has prior history.
Keep SFMC job IDs, headers, audience details, and Gmail evidence together for escalation.
Separate Gmail results from blended opens so provider-specific issues stay visible.
Common pitfalls
Assuming a shared company IP means a new SFMC Enterprise ID has inherited domain trust.
Judging warm-up success from total opens when Gmail is the only provider showing spam.
Skipping header checks because Sender Profiles and Delivery Profiles look correct in SFMC.
Sending large early batches to Gmail before the new domain has stable engagement signals.
Expert tips
Confirm whether the SFMC audit covers authentication only or also reputation indicators.
Use received headers to verify the real return-path, DKIM domain, and authentication result.
Treat a 57,000-message start as stabilization work, not a clean pre-warm planning phase.
Hold Gmail volume at the last stable level whenever spam placement rises after a ramp.
Marketer from Email Geeks says a shared IP inside one company is different from a broad shared pool, so the first check is the actual ownership and scope of the IP.
2022-08-22 - Email Geeks
Marketer from Email Geeks says Salesforce Support was the right path for asking whether the old Reputation Audit was still available for a specific SFMC setup.
2022-08-22 - Email Geeks
My operating sequence
My next move is to open the Salesforce case, request the Reputation Audit or closest current deliverability review, and gather the SFMC evidence in parallel. I do not wait for the audit before checking headers and reducing Gmail exposure.
If authentication is clean, the IP is stable, and Gmail still places mail in Spam, the fix path is a tighter Gmail warm-up: smaller batches, stronger engagement filters, fewer risky templates, and no sudden jumps. If authentication is not clean, fix DNS and domain matching first. If a blocklist or blacklist issue appears, document the listing, affected IP or domain, first seen time, and mail stream before changing infrastructure.
- Verify: Confirm IP scope, SAP mapping, real headers, DNS, and DMARC domain match.
- Stabilize: Slow Gmail volume and send to the highest-engagement audience first.
- Escalate: Give Salesforce the evidence package instead of a general complaint about Gmail spam.
- Monitor: Keep watching authentication, domain reputation, and blocklist signals after each volume change.
