A client sends me his checklist before his first big campaign. Line 3: "warm up the sending IP over six weeks." He sends through Brevo, standard plan. He does not have a sending IP. He shares one with thousands of other senders, and that address has been warm for years.
The advice is not wrong. It simply does not apply to him. And it applies to almost none of the small and mid-sized companies I work with: Brevo, Mailchimp, Klaviyo, Sendinblue that became Brevo. Everyone starts on a shared pool, and almost nobody knows it. So people spend weeks worrying about a lever they do not hold, while the levers they do hold sit untouched.
On a shared pool, the reputation of the IP is not yours. The reputation of your domain is, entirely. Every useful hour of work sits on that side.
You have no IP, and that is almost always good news
A shared IP is a sending address used by several customers of the same platform. It is already warm, it carries volume every day, and it asks nothing of you. A dedicated IP starts at zero: no history, therefore no trust, and it takes several weeks of steady sending before receiving servers take it seriously.
Brevo publishes its own thresholds in its documentation on the difference between a shared and a dedicated IP: a dedicated address makes sense from three campaigns a week to 3,000 contacts or more, or above 100,000 emails a month. Below that, a cold IP performs worse than the pool. I say it plainly every time the question comes up: for a company sending one newsletter a month to 4,000 addresses, a dedicated IP is a problem you pay for.
There is a downside, and I would rather state it. Google writes in its email sender guidelines that the activity of any sender on a shared IP affects the reputation of everyone using it. That is true. It is also not something you can act on, and your provider is watching: on its shared pool, Brevo expects a complaint rate under 0.2%, a hard bounce rate under 2 to 3% and an unsubscribe rate under 1 to 2%, or it will ask you to move to a dedicated address.
Domain reputation is your side of the deal
Here is the passage from Google's guidelines I pull up in every meeting, because it settles the argument in two lines: DKIM and SPF quotas, the two mechanisms that authenticate your mail, are specific to your domain, and if you hit the limit, other domains sending from the same IP may not be affected at all. The IP quota, on the other hand, is shared by everyone.
Two counters run in parallel. One is collective and out of your hands. The other carries your domain name, and it follows you everywhere, including to another platform two years from now. Yahoo puts it even more directly in its sender requirements and recommendations: applied properly, these rules give a sender a consistent reputation for their domain, regardless of which IP the mail is sent from.
That is the whole argument of this article. You do not rent a reputation. You build one, and it is attached to a name, not to an address.
Authentication, the only part fully in your hands
Three records in the DNS zone of your domain name, where its technical settings live, and the question is settled for years. SPF declares who is allowed to send on your behalf. DKIM signs your messages cryptographically. DMARC tells receiving servers what to do when one of the two fails, and sends you reports.
The thresholds have not been negotiable since 2024. Google requires SPF or DKIM from every sender, plus a valid PTR record, meaning a clean reverse lookup on the sending address, an encrypted TLS connection and a spam rate below 0.30%. Above 5,000 messages a day to Gmail accounts: SPF and DKIM and DMARC, with the domain in the From header aligned with either the SPF or the DKIM domain, plus one-click unsubscribe. Yahoo applies the same limits and accepts relaxed alignment. Microsoft joined in May 2025 with its requirements for high-volume senders to Outlook, above 5,000 daily messages to consumer mailboxes.
The trap, and I find it on nearly every account I take over: by default, many platforms sign your messages with their domain, not yours. Technically everything passes. DMARC alignment fails, because the name the recipient sees is not the name that signed. The fix is three CNAME records at your DNS host, the ones your platform hands you under "verify your domain". Five minutes of work, and it is the difference between being authenticated and believing you are.
One firm opinion: do not start at p=reject. Publish p=none with a reporting address, read what comes back for three or four weeks, discover the five tools sending in your name that nobody remembers signing up for, then tighten. I walked through that path in my article on deliverability, DMARC, BIMI and IP warming, which covers the dedicated-IP side of the story.
What you are told, and what actually applies
| The advice you read everywhere | Why it does not hold on a shared pool | What matters instead |
|---|---|---|
| Warm up your IP over six weeks | The IP is already warm, and it is not yours | Ramp up volume on the sending domain |
| Buy a dedicated IP to deliver better | Under 100,000 emails a month, a cold IP does worse than the pool | Stay on the pool and fix the list |
| Monitor your IP reputation | You do not control the other senders in the pool | Monitor domain reputation in Postmaster Tools |
| Publish DMARC at p=reject right away | The blocking risk is immediate, the benefit is delayed | p=none with reports, then quarantine, then reject |
| Send from your main domain | One bad campaign contaminates your billing emails | A sending subdomain dedicated to marketing |
| Judge deliverability by open rate | Google does not measure opens and does not trust third-party figures | Complaint rate, hard bounces, unsubscribes |
The sending subdomain, a decision I make on day one
In practice: campaigns go out from news.yourdomain.com or mail.yourdomain.com, not from yourdomain.com. Yahoo explicitly recommends separating mail streams by IP or by DKIM signing domain, and not mixing marketing with service messages, because every signing domain carries its own reputation.
The value shows up the day something goes wrong. A campaign that collects too many complaints damages the subdomain. Your quotes, your invoices and your password resets keep leaving from the main domain, untouched. Without that separation, one bad newsletter week can push an order confirmation into the spam folder, and at that point we are no longer talking about marketing, we are talking about operations.
The honest caveat: a fresh subdomain has no history at all. Creating one the day before a send to 40,000 addresses is a bad idea. The right time to set it up was before your first campaign. The second best is today, while your list is still small.
Ramping up without an IP to warm
What everyone calls warming still matters. It simply applies to the domain rather than the address. Google is explicit about the method: send at a steady rate, avoid bursts, start with low volume to engaged recipients, never suddenly double a volume you have no history for, and watch what receiving servers send back, since the SMTP protocol returns a code for every message, so you can slow down as soon as rejections climb.
In practice I split the first ramp into three or four sends over three weeks. The first goes to contacts who opened something in the last ninety days, usually twenty to thirty percent of the list. Those are the people who generate the positive signal you need. Then you widen in steps, watching complaints. The same principle applies to automated flows: I would rather launch an automation sequence on an engaged segment before opening it to the whole database.
The worst first campaign is always the same one: everything at once, to the entire list, from a domain receiving servers have never seen, using a file built up over five years. Deliverability is not the problem in that scenario. Method is.
The most expensive mistake
Buying a dedicated IP to fix a list problem. I have watched it several times: results decline, someone suggests "getting our own IP", the add-on is paid for, six weeks of warming follow, and nothing improves. Of course not. The cause was a purchased database, a file nobody ever cleaned, or a signup promise that did not match what was actually sent. A dedicated IP does not fix any of that. It just isolates the problem so it belongs entirely to you, with nobody left to absorb it.
My framing rule: nobody says the words "dedicated IP" until we have looked at where the addresses came from, when the list was last cleaned, and what the real complaint rate is.
The three numbers I watch, and the one I ignore
Complaint rate first. Google asks you to keep it under 0.10% and never to reach 0.30%, Yahoo sets the same ceiling, and your provider often expects better than that on a shared pool. It is the only metric that can send you to the spam folder off a single campaign. Then hard bounces, which reveal an ageing list, and the unsubscribe rate, which reveals a signup promise you are not keeping.
The one I ignore, and this is a real habit change for many teams: open rate. Google states plainly that it does not track opens, that it cannot verify open rates reported by third parties, and that a low open rate is not necessarily a sign of a delivery problem. Since Apple introduced Mail Privacy Protection, a large share of reported opens are prefetches anyway. Presenting a deliverability report built on open rate means measuring something other than what you think you are measuring.
The right tools are free. Google Postmaster Tools works perfectly well on a shared IP: Google even recommends using it to check the reputation of the pool. On the Yahoo side, the complaint feedback loop requires a DKIM signature, which is one more reason to sign with your own domain. And I wire these signals into the rest of the reporting, exactly as I do for analytics and data-driven decisions.
The DNS checklist, in the order I run it
- One single SPF record on the sending domain, including your provider. Two SPF records on the same domain and the whole thing fails.
- Your provider's DKIM CNAMEs published on your domain or subdomain, so the signature carries your name rather than theirs.
- A DMARC record on
_dmarc, set top=nonewith aruaaddress that genuinely receives the reports. - One-click unsubscribe, using the headers described in RFC 8058. Most platforms handle it, but check the option is switched on and that the visible link in the body works too.
- A control send to one Gmail and one Outlook address, then read the headers: SPF, DKIM and DMARC must all show "pass", and the signing domain must be yours.
Half a day of work, once. It is the best effort-to-result ratio in the whole of email marketing, and it also protects your transactional messages, the ones revenue depends on directly for an online store, as I explain in my e-commerce work.
In the crucible: turning an address into a reputation
An IP address is rented, shared and replaced. It has no memory of you. A domain name does: it accumulates, it remembers, and it travels with you from one platform to the next. It is the only durable material in this whole business, and it is precisely the one people neglect while worrying about a warm-up that was never theirs to do.
So forget the IP. Publish three DNS records properly, separate marketing from the rest with a subdomain, ramp up in steps, and clean your list before you double it. The day your volumes genuinely justify a dedicated address, you will arrive with a domain that already has a reputation, and the move will be painless. That is exactly the order I work through the subject in my email marketing and automation service.
Are your emails actually reaching the inbox?
I check your DNS authentication, read your DMARC reports, look at your real complaint rates, and hand back a clean configuration plus a ramp-up plan.