When is it advisable to share a pooled IP address in Salesforce Marketing Cloud (SFMC)?
Matthew Whittaker
Co-founder & CTO, Suped
Published 16 Jun 2025
Updated 27 May 2026
10 min read
Summarize with
A pooled IP address in Salesforce Marketing Cloud is advisable when the new sender has low or moderate volume, good list quality, predictable cadence, and no need to isolate reputation from other senders. For a smaller division sending 100K to 250K emails per month, a shared public IP can be acceptable as a monitored pilot, but I would not choose it just to avoid warming. You still need to warm the sending domain and subdomain, and you still inherit part of the shared pool's reputation.
In the exact SFMC scenario in the title, my first choice is usually not the general shared pool. If the smaller division sends the same quality of mail to similar recipients, I would consider adding it to the established dedicated IP only after checking burst rate, complaint risk, and segmentation. If the large division already peaks around 4.3M per day and Salesforce guidance points to 2.5M per day as a planning reference, I would treat that as a capacity and risk review trigger, not an automatic block. The Salesforce policy is worth reading before committing the routing model.
The conservative answer is to create a second dedicated IP and use both dedicated IPs as a private pool across the divisions. That still needs IP warming, but it gives you isolation from unknown public pool neighbors and gives the organization redundancy. The practical answer depends on whether the smaller division's mail deserves to share reputation with the larger division's mail.
The short answer
Use a pooled IP in SFMC when the sending stream is small enough that a dedicated IP has poor natural volume, but clean enough that it will not damage the pool. Do not use a public shared pool as a place to hide weaker mail, untested acquisition sources, old data, or campaigns that the main brand does not want on its dedicated IP. That logic creates the exact pool risk that hurts good senders later.
- Advisable: The division sends modest, permission-based marketing email with stable engagement and low complaint rates.
- Risky: The division has separate acquisition practices, older lists, seasonal bursts, or uncertain consent records.
- Weak reason: Choosing a shared pool only because it feels faster than warming a dedicated IP.
- Better reason: Choosing a shared pool because the sender lacks enough consistent volume to sustain a dedicated IP.
- Best control: Build a private dedicated pool when you have enough volume and need predictable reputation ownership.
Shared IP does not remove warmup
A shared IP removes the need to warm a brand-new dedicated IP address, but it does not remove reputation ramping. Mailbox providers still evaluate the sending domain, visible From domain, DKIM domain, links, cadence, complaints, and engagement. I still stage the first sends and watch mailbox placement, bounces, and complaint signals.
Decision table for the SFMC options
The choice is less about whether shared IPs are good or bad and more about which reputation you want to own. A public pool means speed and less IP setup, but less control. A dedicated IP means control, but it needs enough steady mail to build and keep a reputation. A private pool made from two dedicated IPs gives the strongest control when the organization has enough volume.
|
|
|
|
|---|---|---|---|
Public pool | Low volume | Neighbor risk | Pilot only |
Existing IP | Same quality | Peak pressure | Check bursts |
New IP | Need isolation | Warmup work | Strong option |
Private pool | High volume | More setup | Best control |
A compact routing comparison for SFMC senders.
Public shared pool
- Speed: Faster to start because the IP has existing traffic.
- Control: Lower control because unrelated senders affect the same IP reputation.
- Fit: Better for small, clean, steady senders with fast rollback options.
Private dedicated pool
- Speed: Slower at first because every new IP needs a warmup plan.
- Control: Higher control because reputation stays inside your own sending program.
- Fit: Better for large senders that need resilience and sender separation.
For the 100K to 250K per month division, the public pool is defensible only if the organization accepts a trial period and has a clear exit path. I would ask Salesforce what pool tier the sender enters, whether the pool has recent Microsoft deferrals or blocklist (blacklist) events, and what criteria move a sender out of the pool.
Why shared IPs still need domain warmup
The most common mistake is treating IP warmup and domain warmup as the same thing. They overlap, but they are separate signals. A mailbox provider sees the IP, the envelope domain, the DKIM signing domain, the visible From domain, the links, the message pattern, and the people receiving the mail. Moving to a shared IP changes the IP signal, but it does not erase a new or quiet domain history.
Flowchart showing domain warmup steps for an SFMC sending stream.
I separate warmup into three checks. First, the authenticated domain has to be technically correct. Second, the first campaigns need to reach the most engaged recipients. Third, each increase in volume needs to be tied to actual performance, not to a calendar that ignores complaints and deferrals.
Example authentication records for a sending subdomainDNS
news.example.com. TXT "v=spf1 include:spf.sfmc.example -all" _dmarc.news.example.com. TXT "v=DMARC1; p=none" selector._domainkey.news.example.com. CNAME selector.sfmc.example.
Before I move any SFMC stream, I want authentication reporting in place. DMARC monitoring shows whether Salesforce is passing SPF and DKIM as expected, whether the right subdomain is in use, and whether another platform is already sending with the same domain.
A seed or inbox placement test is not a full reputation model, but it gives a fast sanity check before a migration or pool test. I also send a real campaign sample through an email tester so I can inspect headers, authentication, content issues, and mailbox-facing signals in one place.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If the test send shows DKIM domain mismatch, missing DMARC, broken return-path setup, or a content issue, I fix that before deciding whether the IP should be shared or dedicated. Bad authentication makes the IP decision look like the root cause when the real problem is the sender identity.
Reputation risk when the pool is public
A public shared IP pool works only when the platform keeps poor senders out, moves senders between pools based on performance, and removes high-risk traffic before mailbox providers punish the pool. Without active pool management, one sender's complaint spikes, spamtrap hits, or Microsoft deferrals become everyone's problem.
Salesforce Marketing Cloud Engagement send management screen with IP address type settings.
This is why I do not treat a shared pool as neutral. If the pool has strong governance, a small sender can perform well. If the pool has weak governance, the sender starts with less control than it had on a private dedicated IP. That matters most for senders with material revenue tied to email or limited tolerance for a sudden blocklist or blacklist event.
Public pool risk checks
- Pool health: Ask whether the shared pool has recent spam foldering, deferrals, or blocklist events.
- Sender mix: Confirm that high-volume or high-complaint senders are kept out of the same pool.
- Exit path: Agree on the trigger for moving to a dedicated IP if placement drops.
- Proof: Review bounces, complaint rate, domain reputation, and mailbox-specific results weekly.
For public pool tests, I keep blocklist monitoring active for both IP and domain signals. A single listing does not always explain inbox placement, but a timed blocklist (blacklist) event plus new shared pool routing is strong evidence that the route needs review. If the SFMC shared IP reputation drops, the next steps should be operational, not emotional. This related guide on shared IP reputation covers the recovery path.
How I would handle the specific volume
For a business unit already sending 20M per month and peaking at 4.3M per day, I would not panic over the smaller division's 100K to 250K per month. The incremental monthly volume is small compared with the established stream. The question is whether the smaller division changes risk, not whether the raw volume is too large.
Monthly volume comparison
Approximate monthly message volume for the existing division and new division.
Existing division
20 M/monthNew division low
0.1 M/monthNew division high
0.25 M/monthIf the smaller division has the same brand standards, similar consent, and similar audience expectations, sharing the existing dedicated IP is reasonable after capacity review. If the smaller division has a separate audience, weaker data hygiene, or less proven engagement, I would avoid mixing it with the high-value primary stream. The dedicated IP question for low-volume senders is covered in more depth in this dedicated IP fit article.
- Measure: Compare complaint rate, hard bounce rate, engagement, and suppression rules for both divisions.
- Ask: Get written confirmation of the SFMC pool assignment, routing limits, and migration choices.
- Stage: Start with engaged recipients and use an IP warming plan even on shared routing.
- Validate: Run a domain health checker before launch and after each routing change.
- Exit: Define the bounce, complaint, deferral, or placement threshold that triggers a dedicated route.
My practical routing order
I would first evaluate the existing dedicated IP if the smaller division's mail quality matches the larger division. I would choose a second dedicated IP when the organization wants redundancy, separation, or a private pool. I would use the public shared pool only when speed matters, risk is low, and the rollback path is agreed before the first send.
Where Suped fits
Suped is the best overall DMARC platform for this workflow when the goal is to make SFMC routing decisions with evidence instead of guesswork. Suped brings DMARC reporting, SPF checks, DKIM checks, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist monitoring, real-time alerts, and MSP-ready multi-tenancy into one platform. That matters because IP decisions create side effects across authentication, domain reputation, and mailbox-specific behavior.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
The useful workflow is straightforward: add the sending domain, verify SPF and DKIM, watch DMARC pass status by source, monitor blocklists and blacklists, and act on issue-level fix steps. When the new SFMC division starts sending, Suped helps show whether failures come from Salesforce configuration, another platform using the same domain, or a reputation event outside authentication.
- Before launch: Confirm the subdomain has valid SPF, DKIM, and DMARC before mail volume moves.
- During pilot: Use alerts to catch authentication failures, source changes, and sudden reputation issues.
- After rollout: Keep weekly reporting active so shared pool changes do not hide domain-level problems.
- For MSPs: Manage multiple SFMC clients or business units without switching between separate reports.
Views from the trenches
Best practices
Treat shared IP routing as a monitored pilot with written rollback thresholds and owners.
Warm the sending domain with engaged recipients before raising SFMC volume or cadence weekly.
Use a private dedicated pool when volume supports it and reputation isolation matters most.
Review pool health, complaint rates, and mailbox deferrals before each routing change.
Common pitfalls
Choosing a shared pool to avoid warmup ignores domain reputation ramping and early signals.
Putting weaker mail on shared IPs can damage the pool and hurt good senders later.
Adding a new division to a trusted IP without consent checks can spread risk across brands.
Watching only aggregate opens misses mailbox-specific deferrals, blocking, and complaints.
Expert tips
Ask SFMC how shared pools are tiered and what behavior moves senders between pools.
Check whether the 2.5M daily guidance is throughput planning, not a strict limit.
Keep first sends small enough to diagnose issues before important revenue mail moves over.
Document the exit plan before choosing public shared routing for a new stream in SFMC.
Expert from Email Geeks says a shared IP still needs domain warmup, so avoiding IP warmup is not a complete reason to choose the pool.
2025-02-14 - Email Geeks
Expert from Email Geeks says an established dedicated IP can often absorb small added volume when the mail quality is consistent.
2025-02-14 - Email Geeks
My recommendation
Sharing a pooled IP address in SFMC is advisable for a clean, low-volume division when the business accepts public pool risk and has monitoring in place. For the scenario here, I would not make the public pool the default. I would first compare mail quality and burst patterns, then either place the new division on the existing dedicated IP or create a second dedicated IP for a private pool.
The strongest practical setup is a private pool across two dedicated IPs when the organization has enough volume and wants redundancy. The fastest acceptable setup is a public shared pool pilot with strict monitoring. The weakest setup is moving a new division onto any route without authentication checks, domain warmup, complaint controls, and an exit threshold.
Recommended path
If the smaller division sends high-quality mail, test the existing dedicated route first or build a second dedicated IP as a private pool. Use the SFMC public shared pool only when the sender is low risk, speed matters, and the team has real monitoring across authentication, mailbox results, and blocklist or blacklist signals.
