The dedicated IP you are sold will never warm up

by Francis Rozange | Sep 8, 2026 | Email Marketing

Abstract 3D render: an empty cold glass pedestal beside a crowded luminous platform

The day you sign with a sending provider, you will be offered a dedicated IP address. The price is modest, the argument simple: your reputation will be your own.

That is true. It is also, for most companies, exactly what you should not buy.

What Google writes about shared IPs

The description is direct, and the downside is named:

“A shared IP address is an IP address used by more than one email sender. The activity of any senders using a shared IP address affects the reputation of all senders for that shared IP address. A negative reputation can impact your delivery rate.”

There is the dedicated IP sales pitch, written by Google itself. Other people’s behaviour reaches you.

Google also gives the course of action: check that the shared IP is not on a blocklist, and monitor its reputation in Postmaster Tools.

A small irony of timing: the IP reputation dashboard is precisely the one Google is about to retire, on the grounds that its data is not actionable.

The paragraph that actually decides

It sits further down the same page, it deals with quotas, and it is the best published explanation of the difference between the two reputations.

“Gmail tracks volume, feedback, and limits per domain and IP address:

DKIM and SPF quotas are specific to your domain. If you hit the limit, other domains that send from the same IP may not be affected.

The IP address quota is shared for all senders that use that IP address. When the IP address hits its quota, all domains that send from that IP address stop sending emails.”

Read the last sentence slowly. When the IP hits its quota, all domains sending from that IP stop sending. Not just yours: all of them.

That is the real risk of a shared IP, and it is not reputational in nature. It is an availability risk. Another of your provider’s customers launches a badly calibrated send, the IP quota is reached, and your invoicing stops at the same time as their promotion.

Conversely, the domain quota isolates you. Your authentication, your volume, your ceiling. It is the only good news in that paragraph, and it matters: your domain is already yours.

The real cost of a dedicated IP

A new IP has no reputation. It has a bad one, or more precisely an unknown one, which to a filter amounts to nearly the same thing.

Building it takes volume and regularity. M3AAWG, the only primary source giving an order of magnitude, speaks of six weeks on average for a domain, and stays vaguer still on IPs: “Senders should have a well-defined process for warming IPs to be introduced to a dedicated environment and should follow it consistently.”

Amazon, which has to parameterise a product and therefore publishes figures, writes this about maintaining reputation once warm-up is complete:

“After you warm up a dedicated IP address, you should send around 1,000 emails every day to each email provider that you want to maintain a positive reputation with.”

A thousand messages a day per provider, just to maintain. A company sending ten thousand messages a month across all providers is a long way short.

Its dedicated IP will never be warm. It will stay an unknown sender, indefinitely, where a shared IP would have given it the benefit of an already established history.

The threshold, put another way

No operator publishes a volume above which a dedicated IP becomes worthwhile. That number does not exist, and be wary of anyone who gives it to you with confidence.

The question is asked differently, and answered with your own data.

Do you send enough, and regularly enough, for an operator to form an opinion of your IP between two sends? If your campaigns are monthly, the answer is no: between sends, your IP falls back into anonymity.

Is your reputation better than that of your provider’s shared pool? If your complaints sit at the market average, leaving the pool loses you a history and gains you nothing.

And can you tolerate a sending stop caused by a neighbour? That is the one question where the dedicated IP clearly wins, and it mostly concerns transactional email, where a delay is measured in support tickets.

The technical prerequisite, which is not negotiable

A sending IP, dedicated or not, must have a coherent reverse DNS record. Google makes it an explicit requirement, and the wording is more precise than the usual shorthand:

“The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname. […] The same hostname must also have an A (for IPv4) or AAAA (for IPv6) record that resolves to the same public IP address used by the sending server.”

Forward and reverse, both. A PTR pointing to a name that does not resolve back to the same IP is worth nothing, and the corresponding rejection is documented: 550 5.7.25 at Gmail, a code you can read straight out of your logs.

On a shared IP, that work is done by the provider. On a dedicated IP it is yours, and it is part of the price nobody quotes you.

What to do tomorrow morning

Pull the volume sent over the last twelve months, broken down by month and by receiving operator. Two curves are enough: Gmail and Microsoft almost always account for the bulk.

If either curve does not exceed a few hundred messages a day, regularly, a dedicated IP is an expense that degrades your position rather than improving it.

If you mix transactional and marketing on the same shared IP and your order confirmations arrive late, you have the one case where a dedicated IP can be defended, and it is solved by separating the two streams rather than dedicating both.

Finally, stop thinking in terms of IP reputation. The operator that displayed it most clearly is removing it from its tools on the grounds that it misleads. Your domain, on the other hand, stays. That is where the game is played, and it is shared with nobody: it is also Sestaro’s position on sending, where messages go out from your server, under your domain.

Sources

LaFactory works email on the evidence: headers, DNS records, rejection logs. No open rate promises, ever. Get in touch for a deliverability audit.