When is it advisable to share a pooled IP address in Salesforce Marketing Cloud (SFMC)?
Published 16 Jun 2025
Updated 11 Oct 2026
14 min read
Summarize with
Updated on 11 Oct 2026: We clarified SFMC shared IP eligibility, domain authentication options, and dedicated IP capacity planning.
Salesforce Marketing Cloud Engagement's public shared IP pool is advisable mainly when a sender stays below 100,000 messages per month, has permission-based data, sends consistently, and accepts blended reputation. Salesforce recommends a dedicated IP between 100,000 and 250,000 messages per month and requires one above 250,000. A smaller division sending within the middle range can remain eligible only when the Enterprise uses shared IP space, but the dedicated route is the stronger default when reputation control matters.
Consider an Enterprise with an existing division sending 20 million messages per month, a 4.3 million-message daily peak, and a new division sending 100,000 to 250,000 messages per month. In this scenario, the general shared pool cannot run beside a dedicated IP on the same Enterprise. If the smaller division sends comparable mail to similar recipients, consider the established dedicated route after checking burst rate, complaint risk, segmentation, and total IP capacity. The daily peak exceeds Salesforce's published per-IP capacity guidance, so it requires a capacity review before adding traffic. The Salesforce policy explains the current thresholds and shared-pool rules.
Additional dedicated IP capacity is appropriate when Salesforce confirms the need. A private pool keeps sending inside the organization's program, but it does not isolate divisions when both use the same IPs. Every new dedicated IP still needs warming.
When shared IP routing is advisable
Use a pooled IP in SFMC when the entire Enterprise is eligible for shared routing and its volume is too low to maintain a dedicated IP reputation. Do not use a public shared pool to hide weaker mail, untested acquisition sources, old data, or campaigns that the main brand does not want on its dedicated IP. That practice damages blended pool reputation and can lead to removal from the shared pool.
- Advisable: The Enterprise sends fewer than 100,000 permission-based messages per month with stable engagement.
- Consider dedicated: Monthly volume sits between 100,000 and 250,000 or reputation control matters.
- Dedicated required: Monthly volume exceeds 250,000 messages.
- Risky: The division has separate acquisition practices, older lists, seasonal bursts, or uncertain consent records.
- Unsupported mix: The same Enterprise attempts to use public shared IPs and dedicated IPs at the same time.
- Private pool: Combine dedicated IPs when each address has enough steady volume and the organization accepts shared reputation risk between its divisions.
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. Stage the first sends and watch mailbox placement, bounces, complaint signals, and deferrals.
Decision table for the SFMC options
The choice depends on volume, account architecture, mail quality, and the reputation the organization wants to own. A public pool combines low-volume senders but offers less control. A dedicated IP gives the sender full responsibility for its reputation and needs steady volume. Multiple dedicated IPs can provide more capacity or separate commercial and transactional traffic.
|
|
|
|
|---|---|---|---|
Public pool | Under 100K/month | Blended reputation | Low-volume Enterprise |
Existing IP | Same mail quality | Capacity pressure | Check peak volume |
New IP | Need isolation | Warmup work | Warm and sustain volume |
Private pool | High or split volume | More setup | Confirm pool membership |
A compact routing comparison for SFMC senders.
Public shared pool
- Speed: Faster to start because the IPs have existing traffic.
- Control: Lower control because unrelated senders affect blended IP reputation.
- Routing: The IP can vary between sends and cannot be selected.
- Fit: Better for a clean, low-volume Enterprise using shared routing throughout.
Private dedicated pool
- Speed: Slower at first because every new IP needs a warmup plan.
- Control: Higher control because reputation stays inside the organization's sending program.
- Routing: Account Default uses the pool for the selected send classification type; Private pins the Delivery Profile to one dedicated IP.
- Fit: Better for large senders that need capacity or sender separation.
For reputation separation, assign each stream its own IP through a Delivery Profile. Rotating both streams through the same private pool shares IP reputation risk; common domains can still carry reputation across separate IPs.
For a division sending 100,000 to 250,000 messages per month, Salesforce recommends a dedicated IP but does not require one until volume exceeds the upper threshold. A shared route remains an option only when the Enterprise is configured for shared IP space. If the Enterprise already uses dedicated IPs, assess the existing private capacity or add another dedicated IP instead of planning a parallel public-pool test.
Salesforce's Email Studio guidance calls for at least 100,000 emails per month per dedicated IP to keep it warm. Count the volume reaching each IP, rather than just the account total, and avoid spreading low volume across too many addresses. A single monthly burst is a weaker basis for reputation than regular sends.
The Enterprise-level constraint changes the choice
Marketing Cloud Engagement does not support simultaneous shared and dedicated IPs on the same Enterprise. That rule changes the decision for a new business unit: a Delivery Profile cannot send one division through Salesforce's public shared pool while another division in the same Enterprise uses a dedicated IP. Moving the Enterprise between IP types requires a routing change and, when moving to a new dedicated IP, a warmup plan.
This guidance applies to Marketing Cloud Engagement. Marketing Cloud Account Engagement and Marketing Cloud Next have different sending models. Check the product named in your contract before applying these thresholds or planning an IP migration.
- Shared Enterprise: SFMC selects an address from the shared pool, and the specific IP can change between sends.
- One dedicated IP: The assigned IP is the default route for all sends in scope.
- Multiple dedicated IPs: Account Default selects from the pool for the send classification type; Private selects one dedicated IP. Ask Support to confirm the pool membership.
- Different account structure: Ask Salesforce to confirm stack, Enterprise, and account eligibility before assuming IPs can be shared across divisions.
Do not treat a Delivery Profile as an exception
Delivery Profiles control available routing inside the account's IP assignment. They do not make public shared IP space available to an Enterprise that is configured with dedicated IPs. Confirm the account design with Salesforce before scheduling a migration. The 2018 Trailblazer answer discusses optional shared routing, but the current Salesforce policy prohibits simultaneous shared and dedicated IP use. Confirm the available routing against Delivery Profile guidance.
Authenticate your domain on shared IPs
A low-volume sender can use an authenticated sending domain while remaining on an eligible shared-IP Enterprise. Salesforce's Private Domain add-on supplies SPF and DKIM authentication without a dedicated IP or a change to the IP assignment. It does not include branded tracking links or image URLs. See Private Domain guidance.
The Sender Authentication Package (SAP) includes domain authentication and account branding. Salesforce permits opting out of its included dedicated IP during initial setup when volume is too low to support one. That forfeits the included IP entitlement; a later dedicated IP needs an additional purchase. Confirm the choice before provisioning against Salesforce's product overview.
- Select the sending domain in Setup > Security > Domain SSL Certificates and complete the domain configuration steps. Confirm that the domain is Active before launching.
- Verify SPF and DKIM on a real SFMC message and configure DMARC reporting. Shared IP reputation does not authenticate your From domain.
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, envelope domain, DKIM signing domain, visible From domain, links, message pattern, and recipient response. Moving to a shared IP changes the IP signal, but it does not erase a new or quiet domain history.
SFMC domain warmup: authenticate, start small, check engagement, then increase volume.
Separate warmup into four checks. Confirm that the authenticated domain is technically correct. Send the first campaigns to the most engaged recipients. Raise volume only when complaints and deferrals remain controlled. Keep cadence consistent enough for mailbox providers to evaluate the stream.
SPF checks the Return-Path domain, while DKIM checks the signing domain in the d= value. DMARC requires at least one passing mechanism with domain alignment to the visible From address, as explained in Salesforce's DMARC requirements. The example below shows a passing message, not DNS records to publish. Use the exact DNS records supplied for your SAP or Private Domain configuration.
Illustrative authentication results for an SFMC messagetext
Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.news.example.com; dkim=pass header.d=news.example.com; dmarc=pass header.from=news.example.com
Put authentication reporting in place before moving any SFMC stream. Suped's DMARC monitoring shows whether Salesforce passes SPF or DKIM with DMARC alignment, whether the intended subdomain is in use, and whether another platform sends with the same domain. Add the reporting address supplied by Suped to the DMARC rua tag so aggregate reports reach the platform. If Salesforce hosts the delegated domain's DNS, request the policy change through Support.
Send a real campaign sample through Suped's email tester to inspect received headers, SPF and DKIM results, DMARC alignment, and sending-IP checks. The report diagnoses sending configuration; it does not measure inbox placement across mailbox providers or predict campaign placement.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If the test send shows a failing DKIM signature, failed DMARC alignment, missing DMARC, or broken Return-Path setup, fix it before deciding whether the IP should be shared or dedicated. Bad authentication can make the IP decision look like the root cause when the sender identity is the real problem.
Reputation risk when the pool is public
A public shared IP pool depends on Salesforce enforcing sending standards and removing accounts with repeated excessive bounces or complaints. Ask Support about pool management rather than assuming that SFMC uses reputation-based pool tiers. Shared IP reputation is the blended result of every sender assigned to that space. Complaint spikes, spamtrap hits, or mailbox deferrals caused by one sender can affect the others.
Illustration of Salesforce Marketing Cloud sender and Delivery Profile IP settings.
A well-managed shared pool can support a small sender. Weak governance leaves the sender with less control than a private dedicated IP. That matters most when email drives material revenue or the sender has 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 (blacklist) events affecting your recipients.
- Sender mix: Ask how Salesforce handles senders exceeding the volume policy or generating repeated excessive bounces or complaints.
- IP variability: Expect the sending IP to vary because SFMC does not guarantee one consistent shared address.
- Exit path: Agree on the trigger for an Enterprise migration to dedicated IP space if placement drops.
- Proof: Review bounces, complaint rate, domain reputation, and mailbox-specific results weekly.
For a public pool, keep Suped's blocklist monitoring active for domain signals and every sending IP observed in your SFMC headers or reports. Update the monitored IPs when routing changes. A single listing does not always explain inbox placement, but a timed blocklist (blacklist) event after a routing change is evidence that the route needs review. If SFMC shared IP reputation drops, follow an operational recovery plan. The shared IP reputation recovery steps cover that process.
Plan capacity for the 4.3 million-message peak
A business unit sending 20 million messages per month and peaking at 4.3 million per day already needs a dedicated IP capacity review. Salesforce's use policy gives approximately 2 million messages per IP per day as capacity guidance, while its Email Studio documentation lists 2.5 million. These published figures differ, so confirm account capacity with Salesforce instead of treating either as guaranteed throughput. The smaller division's additional 100,000 to 250,000 messages per month is modest, but it should not be added until peak throughput and mail quality have both been checked. See the use policy and Email Studio guidance.
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 comparable consent, audience expectations, and suppression controls, it can share the existing dedicated route after capacity review. If its consent records or data hygiene are unproven, fix those first. Use a separate dedicated route for a valid stream needing reputation separation, provided it has enough steady volume. For smaller streams, review dedicated IP fit before assigning another IP.
- Measure: Compare complaint rate, hard bounce rate, engagement, and suppression rules for both divisions.
- Confirm architecture: Get written confirmation of the Enterprise IP assignment, pool behavior, and available Delivery Profile choices.
- Check capacity: Confirm the required IP count and send window for the 4.3 million-message peak. Two IPs at the use policy's approximate 2 million each total only 4 million per day; provider throttling can reduce throughput further.
- Stage: Start with engaged recipients and use an IP warming plan for every new dedicated address.
- Validate: Run Suped's domain health checker before launch and after each routing change.
- Exit: Define the bounce, complaint, deferral, or placement threshold that triggers a routing review. Check results by mailbox provider; an SFMC Delivered event records server acceptance, not inbox placement.
Practical routing order
First assess the existing dedicated IP if the smaller division's mail quality matches the larger division. Add the dedicated IP capacity Salesforce confirms is needed, and use separate Delivery Profiles when the mail streams need separate IP reputations. Use the public shared pool only for an eligible shared-IP Enterprise, not as a parallel route inside the existing dedicated-IP Enterprise.
Where Suped fits
Suped is our DMARC reporting and email authentication platform. For an SFMC routing change, Suped can verify SPF and DKIM results, show DMARC alignment by source, monitor blocklist and blacklist events, and alert the team when DMARC failures exceed its chosen threshold. Compare these checks with SFMC delivery logs to distinguish authentication failures from IP capacity or shared-pool reputation problems.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
The workflow is direct: add the sending domain, verify SPF and DKIM, watch DMARC pass status by source, monitor blocklists and blacklists, and follow the issue-level fix steps. When the new SFMC division starts sending, DMARC reports show which sources pass authentication and which fail. Compare those results with SFMC bounces and complaints, plus Suped's blocklist alerts, to investigate delivery problems outside authentication.
- Before launch: Confirm the subdomain has valid SPF, DKIM, and DMARC before mail volume moves.
- During rollout: Review source changes and use DMARC failure alerts and blocklist (blacklist) alerts during rollout.
- After rollout: Keep weekly reporting active so routing changes do not hide domain-level problems.
- Across business units: Compare sources and authentication outcomes without treating every delivery issue as an IP problem.
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 each IP has steady volume and reputation ownership matters.
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 managed rather than assuming senders move through reputation tiers.
Confirm daily IP capacity with Salesforce; published 2M and 2.5M figures differ between documents.
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 view
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 view
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
Routing recommendation for the two divisions
For the scenario here, keep the new division inside dedicated IP space because the Enterprise already uses a dedicated route. Compare mail quality first, then review the 4.3 million-message daily peak against current IP capacity. Confirm the IP count and send window with Salesforce before adding throughput. Use a separate Delivery Profile when a valid stream needs IP reputation separation and has enough steady volume.
