How to verify SFMC IP warming and domain reputation when sharing an IP address?
Published 4 Jun 2025
Updated 28 Sep 2026
14 min read
Summarize with
Updated on 28 Sep 2026: We clarified how to verify shared and dedicated IP use in Marketing Cloud Engagement, and added the separate automated IP path used by Marketing Cloud Next.
The direct answer is to identify the Salesforce product first, then verify SFMC IP warming in two tracks. For Marketing Cloud Engagement, ask Salesforce Support to confirm the account's shared or dedicated assignment, stack, ownership scope, and available deliverability review. Use received headers and bounce data to identify the IPs used by affected sends because a shared-pool IP can change. Then verify the new From domain with aligned authentication, Gmail placement, bounce data, complaints, SMTP responses, and domain-level reporting. A warm IP does not make a new From Address subdomain warm.
Treat this as a domain reputation problem first and an IP problem second. A dedicated IP shared only between company-owned Enterprise IDs differs from a broad Salesforce-managed pool. Gmail still evaluates the visible sender domain, authenticated domains, sending history, engagement, complaints, and message compliance.
- Support request: Ask Salesforce whether the account uses the rotating shared pool or a dedicated IP shared across company accounts, then request the current deliverability review available for the EID and SAP.
- Domain proof: Check SPF, DKIM, DMARC, the tracking domain, the bounce domain, and organizational-domain alignment for the new From subdomain.
- Mailbox evidence: Compare Gmail placement, complaints, deferrals, and rejections against other mailbox providers instead of relying on blended opens.
- Volume control: If 57,000 messages have already gone out, slow Gmail volume, send to recently active recipients, and fix authentication or compliance gaps before scaling again.
The direct verification path
Some teams remember a Salesforce process called a Reputation Audit. Availability and scope vary, so do not depend on that name. Open a support case and ask deliverability support to confirm the product, shared or dedicated assignment, account scope, recent reputation signals, and whether the new Enterprise ID is using the intended Sender Authentication Package.
Salesforce's Salesforce warming guidance is worth reading before filing the case because it treats warm-up as a controlled sending pattern, not a status inherited from another account's prior use of an IP.
Ask for these exact items
- IP inventory: The sending IPs observed on the affected jobs, plus whether the account uses the shared pool or a dedicated IP shared only inside the company.
- SAP mapping: The Sender Authentication Package, private domain, From Address domain, bounce domain, and tracking domain tied to the sends.
- Review scope: Whether the available review covers authentication and reputation signals only, or also includes mailbox placement and sending-pattern feedback.
- Evidence range: The exact dates, campaigns, job IDs, SMTP responses, and Gmail-heavy segments that produced the spam-folder symptoms.
A support answer that says the IP assignment has healthy history 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 and meets Gmail's current sender requirements.
First identify the Salesforce product
The workflow on this page mainly applies to Marketing Cloud Engagement, where Enterprise IDs, Email Studio, Sender Profiles, Delivery Profiles, and SAP identify the sending setup. Marketing Cloud Next uses a different IP management model, so confirm the product before asking whether an IP has been warmed.
Marketing Cloud Engagement
Check the Delivery Profile and received headers. A Shared IP selection lets Salesforce choose an address from the account's pool, so different sends can use different IPs. A dedicated IP can be shared across company accounts on the same stack.
- Warm-up owner: The sender warms a newly assigned dedicated IP and the sending domain.
- Best evidence: Delivery Profile settings, job-level data, received headers, and Support confirmation.
Marketing Cloud Next
Check Setup > Unified Messaging > Email > Settings > Sending IP Addresses. Shared pools are the default. Under Salesforce-managed provisioning, sustained volume around 5 million messages per month can start a roughly 30-day move to a dedicated pool. The threshold is guidance, not a guaranteed SLA.
- IP transition: Salesforce can shift an increasing share of traffic to the dedicated pool automatically.
- Domain work: Authentication, list quality, steady volume, and domain warm-up still belong to the sender.
Do not mix the two warm-up models
Marketing Cloud Next's managed IP transition does not mean that Marketing Cloud Engagement automatically warms a new dedicated IP. It also does not warm a new sending domain in either product.
Why the shared IP is only half the story
Two Marketing Cloud Engagement arrangements often get mixed together. One is a Salesforce-managed shared IP pool used by unrelated senders. The other is a dedicated IP shared across company accounts on the same stack. The second arrangement gives the company more control, but the new sending domain still needs its own stable history.
Sender Profiles, Delivery Profiles, SAPs, and private domains can be shared across parts of a Marketing Cloud Engagement enterprise structure. Visible configuration in one Business Unit or Enterprise ID does not prove isolation. Verify the actual profile mapping and the final received headers.
Salesforce Marketing Cloud sender and delivery profiles used to verify a shared IP and sending domain.
Dedicated IP shared by company accounts
The dedicated IP is used by more than one Enterprise ID, but the senders have the same corporate owner and use the same Salesforce stack. 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 recently active recipients and keep the older EID's volume steady.
SFMC-managed shared pool
The pool carries traffic from senders outside the organization, and the IP can vary between sends. The sender has less visibility into traffic quality and less control when another pool member creates a reputation problem.
- Control: Salesforce manages the pool and its internal sending rules.
- Risk: Other pool members affect IP reputation, while mailbox providers still evaluate the sender domain.
- Action: Prove the domain and authentication are healthy before changing IP strategy.
For a Marketing Cloud Engagement shared pool, Salesforce recommends a dedicated IP above 100,000 messages per month and requires one above 250,000 messages per month. Those thresholds do not prove that an IP shared only across company-owned Enterprise IDs belongs to the public shared pool, so confirm the assignment with Support.
Do not skip domain warm-up
A warm IP does not give a new From Address subdomain an inherited Gmail reputation. Warm the domain, especially when Gmail placement is already landing in Spam. Reduce Gmail volume, send first to recent clickers, purchasers, and other active recipients, then 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, an unsigned message, or a DKIM signature tied to an unexpected domain. On a shared pool, headers also show which rotating IP handled that specific send.
After the SFMC checks, send a live message to an email tester and inspect the result next to Gmail seed inboxes. Confirm SPF pass, DKIM pass, DMARC pass, and organizational-domain alignment between the From domain and at least one authenticated domain.
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 List-Unsubscribe: <https://brand.example/unsubscribe/opaque-id> List-Unsubscribe-Post: List-Unsubscribe=One-Click
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For a Gmail spam issue in SFMC, the strongest evidence is received headers, SFMC job IDs, provider response codes, and domain-level results collected for the same sends. If the live test fails authentication or shows a domain alignment problem, fix that before blaming the IP.
- Pull the IP: Read the sending IP from headers or bounce data for each affected job, then ask Support to confirm the account's pool or dedicated assignment.
- Confirm the SAP: Match Sender Profiles, Delivery Profiles, Send Classifications, the private domain, bounce handling, and the tracking domain.
- Verify authentication: Check SPF, DKIM, DMARC, and alignment on real received mail, then compare the result with DNS.
- Compare providers: Separate Gmail, Microsoft, corporate, and other consumer domains so Gmail does not get hidden inside aggregate results.
- Escalate clearly: Send Salesforce the observed IPs, headers, job IDs, affected dates, Gmail samples, SMTP responses, 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, consent, engagement, and recent list-source changes are tested instead of blaming the IP too early.
Check Gmail bulk sender compliance
If the organization sends more than 5,000 messages a day to personal Gmail accounts, shared IP health does not provide an exemption from Gmail's bulk sender requirements. Gmail can respond to non-compliant traffic with temporary failures, permanent rejections, or spam-folder placement.
- Authentication and alignment: Use both SPF and DKIM, publish DMARC, and ensure the From domain has organizational-domain alignment with SPF or DKIM.
- Infrastructure: Confirm valid forward and reverse DNS for the sending IP, TLS transport, and RFC 5322 message formatting with Salesforce.
- Unsubscribe handling: Marketing and subscribed mail need RFC 8058 one-click unsubscribe plus a visible body link, and requests need to be processed within 48 hours.
- Complaint target: Keep Gmail's user-reported spam rate below 0.1% and prevent it from reaching 0.3% or higher.
- Sending cadence: Send at a consistent rate, avoid bursts, start with active recipients, and slow the ramp when complaints or SMTP deferrals increase.
Passing authentication is only the baseline
SPF, DKIM, and DMARC can all pass while Gmail still sends mail to Spam because of complaints, unwanted traffic, abrupt volume, or weak engagement. Record authentication, compliance, reputation, and audience signals separately so one passing result does not hide another problem.
How to read the evidence
The pattern matters more than any one signal. Healthy delivery at non-Gmail domains shows that the campaign is not globally blocked. Gmail Spam placement points toward sender identity, audience quality, compliance, 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, audience, or compliance signal | Slow Gmail and segment active users |
Other providers healthy | Provider-specific issue | Compare provider-level results |
Authentication passes | Technical baseline is met | Check complaints and consent |
Authentication fails | Configuration or alignment issue | Fix DNS or SFMC mapping |
SMTP 4xx deferrals | Rate or reputation pressure | Slow volume and inspect codes |
New From domain | Limited sending history | Warm gradually |
Evidence map for shared IP and domain reputation checks.
Check blocklist and blacklist signals, but a clean blocklist result does not prove Gmail trusts the domain. Blacklist checks show whether a listing exists, not whether Gmail accepts the mail stream or places it in the inbox.
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 below the target.
Review
Hold
Authentication passes, but Gmail placement is uneven.
Slow
Reduce
Gmail Spam placement or deferrals grow after a volume increase.
Pause
Stop
Authentication fails, bounces rise, or complaints approach 0.3%.
When 57,000 messages have already been sent from the new Enterprise ID, this is no longer a clean pre-warm. The sender has created a reputation trail. Improve that trail with cleaner segments, smaller Gmail batches, consistent authentication, compliant unsubscribe handling, and steadier volume.
A warm-up plan for the new From domain
For a new domain on an existing IP, warm the domain. The first audience should not be the biggest list, the newest acquisition source, or an old reactivation segment. Start with recent clickers, purchasers, account users, and recipients with recent explicit consent. Use opens only as a secondary signal because privacy features and automatic image loading can distort them.
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
RFC 9989 now defines DMARC, with RFC 9990 covering aggregate reporting and RFC 9991 covering failure reporting. The older pct tag is historic, so it should not appear in a new DMARC record.
SFMC shared IP verification flow for domain warm-up, Gmail volume, and authentication review.
- Segment first: Use recent Gmail clickers and other active recipients before adding colder Gmail recipients.
- Ramp slowly: Increase Gmail volume only after placement, bounces, SMTP responses, 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 the date, SFMC job ID, audience type, Gmail volume, placement, bounce rate, SMTP responses, and complaint signals.
Where Suped fits
Suped's product supports the ongoing verification work after a one-time Salesforce review. It keeps SPF, DKIM, DMARC, sending-source, and blocklist or blacklist evidence together while the SFMC configuration and volume plan change.
Use the domain health checker for a fast DNS review, then DMARC monitoring to follow authentication results by source. Suped's blocklist monitoring can also record blocklist (blacklist) changes between campaign checks.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For SFMC, the practical value is source attribution. If DMARC reports show the expected SFMC source with aligned DKIM or SPF, continue with engagement, Gmail placement, compliance, and volume analysis. If reports show unexpected sources, domain misalignment, or authentication failures, correct those issues first.
Useful Suped workflows here
- Issue detection: Findings identify broken SPF, DKIM, DMARC, forwarding, and domain-alignment problems with steps to fix.
- Failure alerts: Authentication failure spikes can be flagged as new reports arrive during the warm-up.
- DNS management: Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS can reduce DNS work for teams with limited access.
- Multi-domain view: Enterprise teams can compare sending domains and Enterprise IDs in one dashboard.
Suped does not create Gmail trust for a new domain. It supplies evidence about the 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 active 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 metrics 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 Salesforce's review covers authentication or also reputation indicators.
Use received headers to verify the 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 view
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 view
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
Recommended operating sequence
Open the Salesforce case with the product name, assignment, observed IPs, headers, job IDs, affected dates, provider responses, and volume history. In parallel, check authentication and Gmail compliance, then reduce Gmail exposure if placement worsens. 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 product, IP scope, SAP mapping, received headers, DNS, DMARC alignment, and Gmail sender compliance.
- Stabilize: Slow Gmail volume and send to the most recently active audience first.
- Escalate: Give Salesforce the evidence package instead of a general complaint about Gmail Spam.
- Monitor: Keep watching authentication, SMTP responses, complaints, domain reputation, and blocklist signals after each volume change.
