Guide
A dedicated IP is a sending IP address used by one sender only. A shared IP pool is used by many senders at once. The conventional advice is to move to a dedicated IP as soon as volume allows. That advice is wrong for most senders, because a dedicated IP only works if you can send enough mail, consistently enough, to warm it and then keep it warm.
Last reviewed September 2026
Definitions
A dedicated IP address carries only your mail. A shared IP pool carries yours alongside other senders'. The differences are mechanical rather than a matter of opinion, and each row below turns into a practical consequence for one side or the other.
| Dedicated IP | Shared IP pool | |
|---|---|---|
| Who else sends from it | Nobody | Other customers of the same provider |
| Whose behavior moves the reputation | Yours only | Every sender in the pool, collectively |
| Warming required before full volume | Yes, weeks of gradually increasing volume | No, the pool is already warm on your first message |
| Effect of a gap in sending | Reputation is reassessed on recent behavior, so the ramp is partly undone | Other senders keep the volume flowing, so the pool stays warm |
| Volume needed to maintain it | Consistent volume from you, indefinitely | None from you specifically |
| Control over sending patterns | Complete, including the freedom to get it wrong | Bounded by the pool operator's rules |
| PTR hostname in your own domain | Possible, one sending domain per IP address. Rarely asked for | No, the PTR names the operator, which is what receivers ask for |
| Separating marketing from transactional | Another set of addresses per stream, each warmed and maintained separately | Separate pools per stream, run by the provider |
| Typically billed as | A monthly add-on, often priced per IP address | Included in the platform |
| Who manages the warming | You, or your provider on your behalf | The provider, as a condition of running the pool |
The standard advice exists for real reasons, and the best statement of them is not a vendor's. M3AAWG's Sender Best Common Practices, version 4.0 of August 2026, sets out when a dedicated environment is the right provisioning decision. Its list is the case for a dedicated IP, made by a body whose membership includes the mailbox providers doing the filtering.
Two more sit outside that list and are worth adding. Infrastructure isolation is a contractual or regulatory condition in some environments, binding whether or not it improves placement. And a sender large enough to be most of a pool's volume gains little from the pool and a good deal from isolation: cleaner signal, cleaner diagnostics, no need to reason about anyone else.
An IP address has exactly one PTR record, so a reverse lookup can only ever return one hostname. M3AAWG's definition of a dedicated IP builds that in: it is an address used by one sender, which "usually identifies itself in rDNS as being associated with that brand". Its shared IP definition is the mirror image, an address "usually identified with the ESP that owns the IP rather than one of the brands sending from that IP". The best practice it gives for dedicated environments is that reverse DNS "should be entity-specific rather than ESP-specific". So the capability is real, and only a dedicated address can provide it.
The question is who wants it. Google does not. Its sender guidelines require that "the public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname", and that the hostname resolve back to the same address. That is forward-confirmed reverse DNS, it applies to shared pools and dedicated addresses equally, any competent provider satisfies it for you, and nothing in it asks for the PTR hostname to match your sending domain. The claim that Gmail wants PTR alignment circulates widely. It is not in Google's published requirements.
The provider that has actually published something in this area is Deutsche Telekom, for t-online.de, and what it asks for is narrower than alignment with your From domain. Its sender requirements state that the hostname for the delivering system's IP address must let an affected party easily research and identify the operator's domain and website, with a direct means of contact, citing RFC 1912, forward-confirmed reverse DNS and Article 5 of EU Directive 2000/31/EC. That is a transparency requirement about who runs the mail server. It is not an authentication signal about who the mail is from.
Which is why it bites where the operator and the sender are the same party: an organization running its own MTA. On an established ESP network the operator is the ESP, its hostname identifies it, and the requirement is met at that level. It is met more comfortably still for an accredited one. Omnivery is a certified member of the Certified Senders Alliance, the European accreditation scheme that carries particular weight with German and wider European receivers, so the sending identity is not an unknown quantity a reverse lookup has to establish from scratch.
PTR alignment per sending domain is a genuine capability that only a dedicated IP can give you, and it is one of the least frequently requested things in email.
If it is offered as a headline reason to upgrade, that deserves the same scrutiny as the rest of the upsell. Ask which receiver is asking, and for what.
The rest of it is worth conceding plainly: for a sender with high, steady, daily volume, a dedicated IP is the right choice, and Omnivery provisions them for that case. The question is what happens to everyone else, which is most senders.
The first item in the case above is the one everybody buys: on a dedicated address, the reputation is entirely yours. It is also the weakest of them, because an IP address is never assessed as an isolated object. It sits in a /24, in a network, in an autonomous system, and reputation systems look at all of those.
This is not an inference. It is how the widely used blocklists are built:
M3AAWG's own conditions for bringing your own IP space to a provider point the same way: the minimum range it will accept is a /24, and it requires that "the addresses in the IP address range must have a clean history". Not the address you intend to use. The range.
A dedicated IP is not a plot of land you own outright. It is an address inside somebody else's range, announced by somebody else's autonomous system, sitting next to whatever else that party has provisioned. Buying a dedicated address moves you out of a shared reputation at the IP layer and leaves you in one at every layer above it.
So the question comes back to the same place. You are choosing a network to sit in either way. The choice is not whether to have neighbors; it is whether the party admitting them applies any standard, and whether it controls the space at all. A provider renting capacity from a hyperscaler is offering you a dedicated address inside a range it does not own, announced by an autonomous system it does not run, alongside tenants it did not select and cannot remove. Vetting is not available to it as an option, because there is nothing there for it to vet.
Omnivery owns its IP address space and operates its own networks and autonomous systems, on its own physical hardware, with no hyperscaler anywhere in the delivery path. That is not a procurement detail. It is what allows the layers a reputation system actually looks at to line up:
Every reputational signal points at the same clean entity. A receiver widening its assessment from the address to the range, to the network, to the AS finds the same answer at each step rather than a different party at every layer, most of whom have made no commitment about who they let in. That is the version of a dedicated IP's promise that survives contact with how reputation is actually computed - not an address isolated from its neighbors, which is not a thing that exists, but a neighborhood that reads the same at every level of zoom.
There is a second-order version of this worth knowing if you are being sold several dedicated addresses at once. Spamhaus CSS targets snowshoe patterns, meaning volume spread thinly across many addresses with weak sending history. A bank of lightly used dedicated IPs, warmed on a deadline for one campaign a quarter, is not snowshoe spam and does resemble its shape. The e-commerce case below is the one most likely to produce it.
A dedicated IP is sold as a purchase. It behaves like a standing commitment to a sending habit. The argument runs in four steps, and only the first of them is widely discussed.
A new IP address has no delivery history, no complaint history and no engagement record. Sudden volume from it is indistinguishable from a compromised host, so the mail is throttled, deferred or filtered. The remedy is a slow, consistent ramp - M3AAWG suggests considering six weeks as an average, and pacing it against how receivers respond rather than against a calendar. The IP and domain warming guide covers the mechanics.
Google defines it in those terms: reputation is "a rating of the quality of domains and IP addresses used to send email, and is determined by the sending behavior of a domain or IP address". Behavior is present tense. Receivers are scoring a rolling record of recent sending, and an address that stops sending stops supplying one.
Google's own tooling shows where that ends. Postmaster Tools withholds data for a day when "the total number of messages for a given day is too low", which is a plain statement that below a certain volume there is not enough signal to report on. A sender who cannot fill that record is asking receivers to form an opinion from very little.
Reaching full volume once does not finish the job. Holding the reputation means continuing to send at a comparable rate, more or less indefinitely. Every quiet period is a partial reset, and the deeper the trough the more of the ramp it undoes.
The volume threshold at which a dedicated IP gets recommended is almost always measured against peak or projected sending. The number that decides whether the address survives is the baseline: what you send on an ordinary Tuesday in your quietest month. Those two figures can differ by an order of magnitude, and the gap between them is where dedicated IPs fail.
The question is not whether you send enough email to justify a dedicated IP. It is whether you send enough email, consistently enough, to keep one warm between your peaks.
A sender who can answer yes should have a dedicated IP. A sender who cannot is buying an address that will spend most of the year cold.
E-commerce sending is spiky by construction. Black Friday, the seasonal sale, a product launch, an end-of-line clearance: the calendar is built around a handful of days that carry a disproportionate share of the year's revenue. Between those days, volume drops to a fraction of the peak.
Apply the standard dedicated-IP advice to that shape and it produces a specific, repeatable failure.
A single IP can only push so much mail per hour before receivers start deferring it. Getting a large campaign delivered inside the window it was timed for therefore takes several addresses sending in parallel, not one.
Ordinary weeks do not produce enough volume to keep one dedicated IP warm, let alone spread across several. Divide a modest baseline across a bank of addresses and each individual address looks quieter still.
The addresses get ramped in the weeks before the peak, because that is when they are needed. Warming becomes a project with a deadline attached to the most commercially important date in the year.
Freshly ramped IPs meet their largest ever send on the day it matters most. Receivers see an unfamiliar address producing its highest volume to date, which is the exact pattern warming exists to avoid.
Applied to a spiky sending profile, dedicated-IP advice produces the worst deliverability on the most valuable sending days of the year.
That is not an edge case or a hypothetical. It is the normal outcome of the standard recommendation meeting a normal retail calendar.
The same shape turns up wherever sending follows events rather than a steady rate: ticketing, travel around a season, utilities around a billing run, real estate around a launch. E-commerce is simply where the peaks are largest and the gaps between them longest. What that pattern needs from an email platform is covered in transactional email for e-commerce.
Marketing and transactional mail must not share a reputation record. A campaign that draws complaints should not be able to spend the standing your password resets and order confirmations depend on. That much is not controversial, and it is the reason most senders end up running two streams.
Separating them properly takes several signals at once, and the order matters. The primary boundary is the DKIM signing key, because receivers weight a DKIM-signed domain above the IP address a message arrived on. Beneath that sit separate IP pools, separate sending domains with transactional mode enabled only on the transactional one, and different message headers per stream. The warming guide covers why no single one of those signals is sufficient on its own.
M3AAWG names the underlying problem in its case for provisioning a dedicated environment, and it is worth quoting because it is an argument against mixing the streams rather than an argument for any particular product:
"Combining transactional and marketing email or mail from more than one entity can create irregular traffic volumes. Consistency of volume, whether high or low, plays an integral part in the determination of IP reputation and deliverability outcomes."
M3AAWG Sender Best Common Practices, version 4.0. Note that "more than one entity" and "transactional and marketing" sit in the same sentence: a receiver reads mixed streams the way it reads mixed senders.
So the streams have to be provisioned apart. The IP layer is one of the four ways that happens. It is also the layer where a dedicated setup multiplies.
Stream separation doubles the warming problem and doubles the invoice, while halving the baseline volume that has to solve it.
The three effects compound in the same direction, which is why senders who separate their streams correctly are often the ones least able to sustain dedicated addresses.
On a vetted shared pool none of that reaches the customer. Omnivery separates the streams for every customer running both, as the way the platform is set up rather than as a tier or an add-on: distinct DKIM signing keys as the primary boundary, distinct IP pools beneath them, separate sending domains with transactional mode enabled per domain by the Omnivery team, and distinct headers per stream. Suppressions and reporting are held per domain, so the two streams stay separate in the data as well as in the reputation. There are no addresses to buy per stream and no second warm to run, because every pool involved was already warm.
The mechanism is not complicated, and M3AAWG states it directly. From the same version 4.0 that sets out the case for dedicated environments:
"IP reputation is sensitive to changes in sending volume. Mail volumes from more than one entity can be combined in a shared environment to sustain consistent overall average sending volume from the shared environment to establish and maintain IP reputation."
M3AAWG Sender Best Common Practices, version 4.0, on when provisioning to a shared environment is appropriate.
That is the whole argument in two sentences, and it is worth noticing which way round it runs. The shared environment is not a discount version of a dedicated one that you tolerate until you can afford better. It is the provisioning decision that solves a problem a dedicated environment has and a shared one does not.
What it buys, in practice:
Note what the pool does not do. It warms the IP side and nothing else. Your sending domain is new to every receiver regardless of which address it leaves from, and its record still has to be built - M3AAWG recommends domain warming even for a new subdomain of an organizational domain that already has a reputation. That is the most common misreading of "the provider handles warming", and it is the subject of the IP and domain warming guide.
All of that depends on the other tenants, and the risk that comes with them is real. M3AAWG puts it more bluntly than a vendor would:
"ESPs that send large volumes of email on behalf of their clients are at the mercy of their worst clients' worst practices."
M3AAWG Sender Best Common Practices, version 4.0, opening the section on vetting.
One bad sender damages inbox placement for everyone sharing those addresses. A complaint spike, a purchased list, a spam trap hit, a compromised account: any of them degrades the pool's standing, and every other sender in it carries the consequence without having done anything and often without ever learning the cause. Diagnosing it from the inside is close to impossible, because the symptom is your mail performing worse for reasons that are not in your data. M3AAWG's own word for what one entity's poor sending or list-building does to a shared environment is "poison".
This is precisely why the standard advice says to get a dedicated IP, and as a response to this risk the advice is reasonable. It is solving the problem in the wrong place. Moving to a dedicated address removes you from the bad neighbors; it does not remove the bad neighbors, and it charges you the entire warming problem described above for the privilege of leaving.
The alternative is to fix the pool. That is only possible if the pool operator controls who gets in, which most of them have decided not to do.
A shared pool is a bet on your neighbors. Most providers ask you to place that bet blind, on a pool anybody can enter with an email address and a credit card, or with neither. The controls that decide whether the bet is a reasonable one are the entry controls, and they exist before anyone sends a message.
This is not an Omnivery opinion about how a pool should be run. It is what the standards body requires of anyone running one:
"All ESPs must have some type of pre-send vetting process to proactively identify malicious senders before they mail and they must all have a post-send vetting process to monitor clients after they mail."
M3AAWG Sender Best Common Practices, version 4.0, section 5. It also recommends "extra diligence in vetting entities to be provisioned in a shared environment", because of the greater chance that one entity's practices poison it for the others.
Both halves of that are load-bearing, and the second is the one usually missing. Vetting at signup catches the sender who was always going to be a problem. Vetting after the fact catches the sender whose list quality decays, whose account is taken over, or whose business model changes. Omnivery runs both halves, and neither is automated end to end:
Vetting also decides who is turned away, and the answer is more specific than "spammers". Cold prospecting does not pass. Neither does synthetic warming, the practice of manufacturing opens, clicks and replies between networks of controlled accounts, which the same M3AAWG document calls artificial warming and says is "not recommended and may be illegal", which its Position on Cold Email calls "not acceptable in any manner", and which now attracts blocklists that attach to the sending domain and the brand on it. The warming guide covers why.
Vetting, the absence of a free tier and staff review of every domain make it substantially less likely that a damaging sender is in the pool at all, and monitoring is what catches the ones whose sending deteriorates after they are admitted. None of that is a guarantee that no sender in a pool will ever cause a problem, and any provider claiming otherwise is describing a pool they do not operate. What it changes is the odds, and the odds are the entire substance of the shared-versus-dedicated decision.
A dedicated IP is a billable line item. Across the industry it is sold as a monthly add-on, frequently priced per address: Mailgun lists additional dedicated IPs at $59 per IP per month, with one included from its higher-volume plans upward. That structure is normal, and variations on it are near-universal.
It also creates an incentive problem worth naming. A provider recommending a dedicated IP is recommending a product it profits from, at a volume threshold the provider itself sets. The recommendation may well be correct. But the party giving it is not disinterested, and the threshold behind it is rarely tested against the number that actually decides the outcome, which is whether the sender can keep the address warm between peaks rather than what the sender does at peak.
None of that requires anyone to be acting in bad faith. The incentive is structural, which means it operates on honest advice as readily as on dishonest advice, and it is a reason for a sender to ask a specific question rather than to distrust the answer: does this recommendation account for my baseline volume, or only my peak?
Omnivery offers dedicated IPs. We recommend them when the deliverability case supports it, and we tell senders not to buy them when it does not. A dedicated IP that cannot be kept warm is worse than no dedicated IP at all, and selling one anyway is not deliverability advice, it is a revenue decision.
That position has a cost attached. It means declining revenue on the basis of a sender's baseline volume, which is a figure that has to be asked for rather than one that appears on a pricing page.
A dedicated IP is genuinely the right answer in five situations, and Omnivery provisions one where any of them holds.
Version 4.0 of the M3AAWG BCP also documents a third path that is neither a shared pool nor a provider-owned dedicated address: bringing IP space you already own onto a provider's platform. It avoids warming new addresses, because the addresses are not new, and it keeps the reputation you have already built in space you continue to control. M3AAWG sets conditions - verified ownership by RDAP or a signed letter of authorization, a minimum IPv4 range of a /24, a clean history for every address in it, reverse DNS pointing at the owner's domain rather than the provider's, and sending from the old provider stopped before the routing announcement completes - and notes that it "is generally not widely offered at the current time" because of the setup it demands on the provider side. Omnivery supports it, in both its EU and US data centers. Worth knowing the option exists before assuming the choice is binary, particularly on a migration where the addresses you already have are the asset you are trying not to lose.
The useful question is not what volume tier you have reached. Providers publish thresholds and those thresholds are chosen by the party selling the address. The question is about the shape of your sending rather than its size:
Between your peaks, in your quietest month, can you generate enough consistent daily volume to keep the address warm on its own?
If yes, a dedicated IP will do what it promises. If no, it will spend most of the year cold, and a cold dedicated address performs worse than a well-run shared pool rather than better.
Answering that honestly usually needs your own numbers rather than a rule of thumb, which is what a deliverability analyst is for. Omnivery's white-glove deliverability team works the question from your actual sending history and per-receiver placement, and will tell you not to buy a dedicated IP when the numbers do not support one.
At a glance
Questions
A dedicated IP is a sending IP address used by one sender only, so its reputation reflects that sender's behavior alone. A shared IP pool is a set of addresses used by many senders at once, so its reputation reflects the collective behavior of everyone in it. The practical difference is not privacy but volume: a dedicated address has to be warmed and kept warm by its single sender, while a shared pool is kept warm by everybody's ordinary sending combined.
Probably not, and that is usually the right outcome rather than a compromise. The test is not what volume tier you have reached, it is whether you can generate enough consistent daily volume between your peaks, in your quietest month, to keep the address warm on its own. If you can, a dedicated IP will do what it promises. If you cannot, it will spend most of the year cold, and a cold dedicated address performs worse than a well-run shared pool.
There is no honest single number, and any threshold you are quoted was chosen by the party selling the address. Volume thresholds also measure the wrong thing. What decides whether a dedicated IP works is the shape of your sending rather than its size: a sender doing large peaks with quiet months between them can exceed any published threshold on annual volume and still be unable to keep an address warm. Ask about your baseline, not your peak.
Its reputation is reassessed on the basis of recent behavior, and there is no longer any recent behavior to assess. Google describes reputation as a rating determined by the sending behavior of a domain or IP address, which is a present-tense judgment rather than a status you earn once. A quiet period undoes a meaningful part of the ramp, and the longer and deeper the gap the more of it is lost. Resuming at full volume after a gap is the same pattern warming exists to avoid.
Not fully, and this is the part the "your reputation is entirely your own" pitch leaves out. An IP address is never assessed on its own: it sits inside a /24, a network and an autonomous system, and reputation systems work at those levels too. Spamhaus DROP lists netblocks rather than addresses, ASN-DROP lists whole autonomous system numbers, and the Spamhaus Reputation Portal presents a network owner's space by /24 with listing counts per range. Cisco Talos reports the owner of the largest block an address belongs to. A dedicated address is announced from your provider's network, so you take on that network's standing whether or not the address itself is clean. The practical consequence is that you are choosing a neighborhood either way, and the useful question is who else the operator lets into the space.
Yes. A complaint spike, a purchased list, a spam trap hit or a compromised account degrades inbox placement for every other sender using those addresses, through no fault of theirs and often with no visible cause. This is the genuine risk of a shared pool and the reason the standard advice recommends moving away from one. The alternative response is to control who is admitted to the pool in the first place, which is what vetting is for.
Its Sender Best Common Practices, version 4.0 of August 2026, treats the choice as a genuine provisioning decision rather than a hierarchy, and sets out when each is appropriate. For shared environments it states that mail volumes from more than one entity can be combined "to sustain consistent overall average sending volume from the shared environment to establish and maintain IP reputation", and that provisioning several entities together means "mistakes made by any single sender in the environment can dilute the overall reputational impact". For dedicated environments it lists isolating mail of unknown or unusually high quality, controlling volume, not being identified with the provider, needing different outbound MTA settings, and third-party programs that require one. It also requires every ESP to run both pre-send and post-send vetting, and recommends extra diligence when vetting senders for a shared environment.
That depends entirely on who else is in it, which makes the entry criteria the question rather than the architecture. A pool that anyone can join with a free account carries real and unmanageable risk. A pool where every customer is vetted before contract, every sending domain is reviewed by staff, there is no free tier, and analysts monitor behavior on an ongoing basis carries substantially less. No provider can promise that a sender in a pool will never cause a problem, and one that does is describing a pool it does not operate.
More than one, which is exactly where the trouble starts. A single IP address can only push so much mail per hour before receivers begin deferring it, so a large campaign that has to land inside a window needs several addresses sending in parallel. The number depends on the size of the send, the window and the recipient provider mix. The harder problem is not provisioning them, it is that a baseline which struggles to keep one address warm will not keep several warm.
Because e-commerce sending is spiky and dedicated IPs need consistency. The peak days need several addresses to deliver quickly, while the ordinary weeks between them do not produce enough volume to maintain even one. The addresses end up being warmed on a deadline set by the campaign, so the largest send of the year leaves from addresses that were ramped in a hurry. The result is the worst deliverability on the most valuable sending days, which is the opposite of what buying the addresses was meant to achieve.
If you are on dedicated addresses, yes, and this is where the cost of the decision becomes clear. Marketing and transactional should build separate reputation records so a campaign drawing complaints cannot damage delivery of password resets, and addresses shared between the streams give up exactly that separation. So two streams means two sets of addresses, two warms running in parallel, and a baseline that divides across the streams before it reaches any single address. The bill multiplies the same way, since dedicated IPs are priced per address per month. Note also that the separation is not only about addresses: the primary boundary is the DKIM signing key, because receivers weight a DKIM-signed domain above the IP a message arrived on.
Across four signals, in order of how much reputation each carries: distinct DKIM signing keys as the primary boundary, distinct IP pools beneath them, separate sending domains with transactional mode enabled only on the transactional one, and different message headers per stream. Suppressions and reporting are held per sending domain, so the streams stay separate in the data as well as in the reputation. This is how the platform is set up for customers running both streams rather than a tier or an add-on, so there are no addresses to buy per stream and no second warm to run.
Yes. Omnivery provisions dedicated IP addresses where the deliverability case supports one: high consistent volume, a specific receiver asking for PTR alignment, a contractual or regulatory isolation requirement, or a sending pattern that fits the pool badly. Omnivery also supports bringing your own IP address space onto the platform, in both its EU and US data centers, which is the better route where you already hold addresses with a history worth keeping. It is not the default recommendation, and a sender whose numbers do not support one is told so. The default is the vetted shared neighborhood, which requires no warming management from the customer.
It is worth paying for when you can keep it warm, and a waste of money when you cannot. Dedicated addresses are sold as a monthly add-on, commonly priced per address, so the cost is recurring while the benefit depends on a condition that many buyers never meet. Before paying, work out your baseline daily volume in your quietest month and ask whether it is enough to sustain the address on its own.
Partly because the advice is genuinely correct for high-volume, steady senders, and partly because a dedicated IP is a billable line item. Mailgun, for example, lists additional dedicated IPs at $59 per IP per month. That does not make any particular recommendation wrong, but the incentive is structural and the volume threshold is set by the party selling the address. The question worth asking a provider is whether its recommendation accounts for your baseline volume or only your peak.
Not the IP side. A well-maintained shared pool is already warm and you inherit that from the first message, which is why sending can start at normal volume immediately. The domain side is different and is still yours: your sending domain is new to every receiver regardless of which IP address the mail leaves from, and its reputation record has to be built. Confusing the two is the most common misreading of "the provider handles warming".
No. A dedicated IP address changes who is responsible for the reputation, not what the reputation is. On day one it has no history at all, which is worse than a good shared pool and better than a bad one. What improves deliverability is consistent volume, clean list practice, correct authentication and low complaint rates, and a dedicated address raises the cost of getting any of those wrong because there is nobody else's good behavior to dilute it.
PTR domain is the hostname obtained by a reverse DNS lookup on the sending IP address. Alignment means that hostname sits in the sender's own domain rather than the provider's, and yes, it requires a dedicated IP address per sending domain, because an address has exactly one PTR record.
The more useful question is who asks for it, and the answer is almost nobody. Google does not: its requirement is that every sending IP have a PTR record resolving to a hostname that resolves back to the same address. That is forward-confirmed reverse DNS, it applies to shared pools too, and it says nothing about matching your sending domain. The provider that does publish a requirement here is Deutsche Telekom, and what it asks is that the hostname for a delivering system let an affected party identify the operator's domain and website with a direct means of contact, citing RFC 1912, FCrDNS and Article 5 of EU Directive 2000/31/EC. That identifies who runs the mail server, not who the mail is from, so an established ESP satisfies it with its own hostname. It principally affects organizations running their own MTA, where the operator and the sender are the same party.
Sometimes, and it is the option most often left out of the dedicated-versus-shared conversation. M3AAWG documents it in version 4.0 of its Sender Best Common Practices: rather than using addresses the provider owns, a sender can bring IP space it owns onto the provider's platform. The appeal is that the addresses are not new, so there is no warming to do and no reputation to rebuild. The conditions it sets are ownership verified by RDAP or a signed letter of authorization, a minimum IPv4 range of a /24, a clean history for every address in the range, reverse DNS pointing at the owner's domain rather than the provider's, and sending from the previous provider stopped before the routing announcement completes. M3AAWG notes the approach "is generally not widely offered at the current time" because of the work it requires on the provider side. Omnivery supports it, in both its EU and US data centers.
Every external claim on this page traces to one of these. Where a statement describes Omnivery's own platform or policy rather than a published standard, it is linked to the documentation instead.
Where this page says a warming ramp takes weeks, M3AAWG's own guidance is to "consider 6 weeks of warm-up as an average" - an average rather than a schedule, and one that depends heavily on list size, list quality and recipient provider mix. The number of IP addresses a large campaign requires depends on send size, delivery window and recipient mix, and no general figure is offered here for that reason. The claim that Gmail treats PTR domain as an authenticity signal for unauthenticated messages appears in several places including Omnivery's own documentation; it is not in Google's published sender guidelines and is not repeated on this page.
This decision settles which addresses your mail leaves from. These cover what happens to the reputation afterward, and what decides whether a pool is worth being in.
Every customer is vetted before contract and every sending domain is reviewed by staff, so the shared neighborhood is warm on your first message and stays that way. Dedicated IP addresses are available where the numbers support one, and a senior deliverability analyst will tell you when they do not.