Dedicated vs shared sending IPs

2 June 2026 · 12 min read

When you send email through a provider like Amazon SES, SendGrid, Postmark, Mailgun or a marketing platform, your mail leaves their infrastructure from an IP address. That address has a reputation at every receiver, and that reputation is one of the inputs Gmail, Yahoo and Microsoft use to decide between inbox, spam folder and outright rejection. The question of whether that IP is yours alone (dedicated) or shared with other senders on the same platform is one of the most consequential and most misunderstood deliverability decisions you will make.

This article is specifically about the IP reputation trade-off and how it interacts with email authentication: SPF, DKIM and DMARC. It is not a generic "warm up your IP" listicle. The interesting part for anyone running DMARC is that the dedicated-versus-shared choice changes which authentication mechanism actually protects you, how SPF alignment behaves, and what your aggregate reports will show you about sources you do not control. If you have not yet baselined where your domain stands, run it through the DMARC checker and the deliverability score before you read on, because the right IP strategy depends on your real sending volume.

What "the IP" actually controls, and what it does not

A receiving mail server makes a series of decisions about an inbound message. Simplifying slightly, those decisions draw on:

• Connection-level reputation: the reputation of the sending IP and its reverse DNS (PTR) record.
• Authentication results: did SPF pass, did DKIM pass, and do either of them align with the From domain so that DMARC passes.
• Domain reputation: the reputation of the domain in the visible From header, and increasingly of the DKIM signing domain (d=).
• Content and engagement signals: spam-trap hits, complaint rates, opens, replies, deletes-without-opening.

The sending IP feeds the first of those buckets directly. It is a real, measurable signal, but it is not the whole story, and at the major consumer mailboxes it is no longer even the dominant one. Gmail and Yahoo have spent the last several years shifting weight away from pure IP reputation and towards domain reputation tied to authenticated identity. That shift is exactly why the 2024 sender requirements from Google and Yahoo mandate SPF, DKIM and DMARC for bulk senders. Your IP can be pristine and your mail can still go to spam if your domain reputation is poor or your authentication does not align.

Hold that thought, because it is the key to the whole dedicated-versus-shared debate. The IP is a lever, but it is a lever you should pull in the context of your authentication, not instead of it.

Shared IPs: the default, and why it is usually fine

On a shared IP pool, your provider routes your mail out of a set of addresses also used by many other customers. The pooled reputation is built and maintained by the provider, who has a strong commercial incentive to keep it clean: they police signups, monitor complaint rates, throttle bad actors and segment senders into pools.

The trade-offs:

Advantages of shared:

• No warm-up. The pool already has an established, generally good reputation, so a low-volume sender inherits inbox placement on day one. A dedicated IP with zero history starts as an unknown, which receivers treat with suspicion.
• Volume smoothing. Reputation at mailbox providers is partly built on consistent, sufficient volume. A pool sending millions of messages a day maintains a steady signal. A small sender cannot generate that signal alone.
• Provider-managed hygiene. The provider handles blocklist delisting, feedback loops and pool segmentation. That is real operational work you do not have to do.
• Lower cost. Shared sending is the default tier on almost every platform and usually costs nothing extra.

Disadvantages of shared:

• Neighbour risk. If another sender in your pool gets blocklisted or triggers a spam-trap cluster, the whole pool's reputation can dip, and your inbox placement dips with it. Good providers mitigate this with reputation-based pool segmentation, but it is never zero risk.
• Less control and less visibility. You cannot directly influence the pool's reputation, and you usually cannot see the other senders' behaviour.
• Reputation is not portable. The good reputation belongs to the provider's pool, not to you. If you migrate providers, you start over.

For the majority of senders, low-to-moderate volume, transactional mail, a normal SaaS or small business, shared is the correct default. You inherit a working reputation, you avoid warm-up pain, and you let a specialist manage the hygiene.

Dedicated IPs: control, at the price of responsibility

A dedicated IP is yours alone. No neighbours, no shared fate. But an IP with no sending history has no reputation, and receivers do not extend the benefit of the doubt to unknown addresses sending in volume. You have to build that reputation from scratch through a warm-up.

Advantages of dedicated:

• Reputation isolation. Your inbox placement reflects only your own sending behaviour. No neighbour can drag you down, and you cannot be collateral damage in someone else's blocklisting.
• Reputation you own and can grow. Sustained good sending compounds into a strong, predictable reputation that is genuinely yours.
• Granular diagnosis. When something goes wrong, the IP reputation signal points at you and only you, which makes troubleshooting cleaner.
• Required for some advanced setups, such as certain high-volume arrangements or where a receiver's policy keys off a specific address.

Disadvantages of dedicated:

• Warm-up is mandatory and slow. You must ramp volume gradually over days to weeks so receivers learn to trust the address. Send too much too fast from a cold IP and you will be throttled (4xx deferrals) or rejected.
• You need sustained volume to hold reputation. This is the decisive constraint. Mailbox providers partly decay the reputation of IPs that send intermittently. A dedicated IP that sends a few thousand messages a week struggles to maintain a strong, stable reputation because there is not enough consistent signal. Industry guidance commonly cites a rough floor in the tens of thousands of messages per day, sustained, before a dedicated IP earns its keep. Below that, a shared pool almost always places better.
• You own the hygiene. Blocklist delisting, feedback-loop registration, complaint management: all yours.

The single most common dedicated-IP mistake is a low-volume sender who hears "dedicated is better" as folklore, moves to a dedicated IP, and then sends too little, too irregularly, to ever build reputation. They end up with worse placement than they had on the shared pool, and they blame the provider. The volume threshold is not a marketing detail. It is the deciding factor.

Who should use which

A practical decision guide:

1. Low volume (under roughly 100k/month), transactional or mixed. Use a shared pool. You cannot generate enough consistent signal to maintain a dedicated IP, and you gain a working reputation for free.
2. High, consistent volume (tens of thousands per day and up). A dedicated IP starts to make sense. You can hold the reputation, you isolate yourself from neighbour risk, and you own a growing asset.
3. High volume but spiky (for example, a retailer who is quiet for weeks then sends a single huge campaign). This is the hardest case. A dedicated IP will go cold between sends and then look suspicious when the spike arrives. Either keep a baseline of consistent sending, or stay on a well-managed shared pool, or split: dedicated for steady transactional mail, shared or a separate warmed stream for the spikes.
4. Mixed transactional and marketing. Separate the streams regardless of dedicated-versus-shared. Send transactional mail (password resets, receipts) and marketing mail from different IPs and ideally different subdomains, so a marketing complaint spike never threatens delivery of a password reset. This stream separation matters more than the dedicated-versus-shared question itself.

The subdomain point deserves emphasis because it ties directly into authentication, which is where this gets interesting.

The authentication implications

Here is the part that gets skipped in generic IP advice, and the part that matters most if you run DMARC.

SPF: the IP is the thing SPF authorises

SPF works by listing authorised sending sources for your domain. With a shared pool, your SPF record typically includes the provider's include: mechanism, which covers the entire pool's IP ranges. For example:

v=spf1 include:amazonses.com include:_spf.google.com -all

That include:amazonses.com authorises Amazon's whole shared SES space, not just the addresses your mail happens to leave from. So SPF passing tells the receiver "this came from somewhere in the provider's authorised range", which is a weaker statement than you might assume. It does not distinguish you from any other tenant.

With a dedicated IP, you can tighten this. Many providers let you publish a narrow ip4: or ip6: mechanism for your specific address, or a dedicated include scoped to your account:

v=spf1 ip4:198.51.100.25 include:_spf.google.com -all

That is a more precise authorisation. It also helps you stay under SPF's hard limit of ten DNS lookups, because a literal ip4: mechanism costs zero lookups whereas a broad provider include: can cost several. If you are stacking multiple senders and brushing against that limit, a dedicated IP literal can actually simplify your SPF. Check your current lookup count with the SPF checker before you assume you have headroom; the failure mode is a permerror, covered in SPF PermError: too many DNS lookups.

Either way, remember the alignment rule that DMARC cares about. SPF passing is not enough; the domain SPF authenticates (the MAIL FROM / return-path domain) must align with your visible From domain. A dedicated IP does nothing for alignment by itself. You still need the return-path on your own domain. The IP choice and the alignment work are independent levers.

DKIM: the mechanism that does not care about your IP at all

DKIM signs the message with a cryptographic key tied to your domain (d=yourdomain.com). It is completely independent of the sending IP. A valid DKIM signature with your domain in the d= tag proves the message came from your domain and was not tampered with in transit, and that holds true on a shared pool of a thousand tenants and on a dedicated IP all your own.

This is why DKIM, not the IP, is the durable backbone of authenticated identity:

• DKIM survives forwarding. SPF breaks when mail is forwarded because the forwarder's IP is not in your SPF record. DKIM survives because the signature travels with the message. See why DKIM fails after forwarding for the mechanics.
• DKIM is portable across IPs. If you migrate from a shared pool to a dedicated IP, or change providers entirely, your DKIM-based identity and the domain reputation built on it move with you, as long as you keep signing with the same d= domain. Your IP reputation does not move. Your domain reputation, anchored by DKIM, does.

That portability is a strategic reason to lean on DKIM-aligned domain reputation rather than betting everything on IP reputation. Verify your signatures with the DKIM checker.

DMARC and reporting: the IP choice changes what your reports tell you

DMARC aggregate reports group results by source IP. This is where the dedicated-versus-shared distinction becomes a practical diagnostic difference:

• On a dedicated IP, your legitimate mail appears in reports under a small, known set of addresses. Anything sending from an unexpected IP and claiming your domain stands out immediately. Spoofing and shadow IT are easier to spot.
• On a shared pool, your legitimate mail appears under whatever pool addresses the provider used that day, which can be a wide, rotating range. Distinguishing your real mail from a spoofer who is also abusing the same shared provider is genuinely harder, because both come from the provider's space and both may even pass SPF against the provider's include:.

That last point is worth sitting with. On a shared platform, SPF alone cannot tell your mail apart from another tenant's mail, including a malicious tenant spoofing your From. DMARC alignment is what closes that gap: the spoofer cannot produce a DKIM signature with your d= domain, and cannot put your domain on the return-path they control. So on shared infrastructure, DKIM alignment is doing more of the security work, and you should treat it as non-negotiable rather than relying on SPF. Feed your aggregate reports into the DMARC report analyzer to see exactly which IPs are sending under your name and whether they align.

Reverse DNS, PTR and the trust signals around the IP

Whichever you choose, the IP carries a few signals that receivers check and that you should not ignore:

• PTR (reverse DNS). Many receivers reject or penalise mail from an IP with no PTR record, or with a generic, mismatched one. On a shared pool the provider sets a sensible PTR. On a dedicated IP you (or your provider) must ensure the PTR resolves to a hostname that itself resolves back to the IP (forward-confirmed reverse DNS, FCrDNS). Check it with the PTR record checker.
• Blocklists. Both shared and dedicated IPs can land on blocklists, but the consequences differ: on a shared pool the provider handles delisting; on a dedicated IP it is your job, and a single spam-trap hit reflects on you alone. Monitor with the blocklist checker.
• Consistency. Receivers reward steady, predictable sending from a given IP and punish erratic bursts. This is the same volume-consistency point as before, viewed from the receiver's side.

A warm-up sketch for a dedicated IP

If you have decided a dedicated IP is right (high, sustained volume, and you have separated transactional from marketing), warm it up deliberately:

1. Start small and send to your most engaged recipients first. Positive engagement (opens, replies) early teaches receivers that your mail is wanted.
2. Ramp volume gradually, on the order of doubling every day or two, watching for 4xx deferrals that signal you are pushing too fast.
3. Keep complaint rates well under the 0.3% threshold that Google's sender guidelines flag; a single bad campaign during warm-up can set you back weeks.
4. Authenticate from day one. SPF aligned, DKIM signing with your domain, DMARC published. Warming an IP while your authentication is broken just teaches receivers to distrust an address that also fails alignment. Confirm the full picture with the deliverability score.
5. Hold the volume afterwards. Warm-up is not a one-time event if you then drop to a trickle. The reputation decays without sustained sending.

The honest summary

• The sending IP is one input among several, and at the big consumer mailboxes it is no longer the dominant one. Authenticated domain reputation, anchored by DKIM, is.
• Shared is the right default for most senders: you inherit a working reputation, skip warm-up and offload hygiene. The cost is neighbour risk and reputation you do not own.
• Dedicated pays off only at high, consistent volume. Below the threshold it places worse than shared, not better. The volume requirement is the deciding factor, not folklore about dedicated being inherently superior.
• Separate transactional from marketing by IP and subdomain regardless of which model you pick. That separation protects your critical mail more than the dedicated-versus-shared choice does.
• Authentication is independent of, and more durable than, the IP. SPF authorises the IP; DKIM proves the domain and survives forwarding and migration; DMARC alignment is what distinguishes you from a spoofer, which matters most precisely when you are on shared infrastructure.

If you are weighing this decision, start by seeing what your domain actually looks like today: run the DMARC checker, confirm your SPF lookup count and alignment with the SPF checker, and verify your signatures with the DKIM checker. Then read your real aggregate reports in the DMARC report analyzer so the IPs sending under your name stop being a guess. The deliverability questions become much easier to answer once your authentication is aligned and your reporting is switched on, which is exactly what our done-for-you monitoring keeps watch over as your sending setup, and your IPs, change over time.