Built-in warm-up in cold email tools: three architectures

Warm-up means one thing to a receiving provider: mail from this domain and this mailbox gets delivered, opened, replied to and not marked as spam. Any mechanism that produces those signals works. The reason "built-in warm-up" varies so much in results is that the mechanism underneath is one of three quite different designs, and the product page rarely says which.

The three designs

1. An internal pool of the platform's own users. Your mailbox exchanges mail with other customers' mailboxes on the same platform. Cheap to build, no extra infrastructure, and the pool is as good as the platform's customer base. Risks: the pool is dominated by brand-new cold-outreach domains, which is the opposite of the neighbourhood you want to be seen corresponding with, and a provider that recognises the pattern discounts the whole pool at once.

2. A dedicated warm-up network run separately from your sending tool. Mailboxes recruited and maintained for this purpose, across several providers, with engagement behaviour (opening after a realistic delay, replying, moving a message out of spam) as the actual product. More work to run; produces stronger signals, particularly if the provider mix matches your recipients.

3. Your own mailboxes exchanging mail with each other. Free and fully under your control, and almost useless at scale: the signal all comes from inside one or two domains, so you are teaching providers that your domains like each other. It is a fine smoke test for whether SMTP and DKIM work.

The question that actually separates them

Ask one thing: does the tool read the recipient mailbox to confirm where the message landed?

A warm-up feature that only records "sent" is reporting on itself. To know whether warm-up is working you need the recipient side — an IMAP or API read of the receiving mailbox that reports Inbox, Spam or a category tab, broken out per provider. Without that, a warm-up dashboard going green tells you nothing about Gmail or Microsoft 365.

Second question: per provider, or one blended score? A mailbox at 90% in Gmail and 20% at Microsoft averages to something that looks acceptable, and the Microsoft problem — which is where most B2B recipients are — stays invisible.

Where the warm-up sits relative to your sender

A practical detail that matters more than branding. If warm-up runs inside your cold email platform, the traffic uses the same credentials and path as your campaigns, which is good for signal consistency — but you only get the data that platform chooses to show you. If warm-up runs separately, it has to connect to the same mailbox by OAuth or by SMTP and IMAP, and then it can both send on the real path and read the receiving side independently.

Both arrangements work. What does not work is warming a Google Workspace mailbox on one domain while campaigns leave through an unrelated ESP on another domain: you are building reputation for a path you do not use.

What warm-up does not do, regardless of architecture

• It does not clean a list. Hard bounces and complaints from bad data outrun any warm-up; Amazon SES, for example, reviews accounts at 5% bounce or 0.1% complaint no matter how warm your domain is.
• It does not fix missing or misaligned authentication. Publish SPF, DKIM and DMARC first, and confirm alignment from a received message's Authentication-Results header.
• It does not replace a volume ramp. Three warm weeks followed by 10,000 sends on Monday is still a spike.
• It does not clear a blocklisting. Delist, then warm.
• It does not make a weak offer land. Placement gets you read; it does not get you replies.

Choosing, in order

1. Confirm the recipients are real mailboxes with a named provider mix, and that the tool reads the receiving side.
2. Confirm per-provider, per-mailbox daily reporting, because that is what you will act on.
3. Confirm it can drive the mailbox you actually send from — OAuth for Gmail or Outlook, SMTP and IMAP for an ESP-based sender.
4. Confirm you can pause and re-ramp a single mailbox without resetting everything.
5. Run it for three weeks against a seed placement test you trust, and judge it on the placement grid plus reply rate, not on the tool's own score.

MailPilot is the second architecture, stated plainly: real mailboxes exchanging real messages with real opens and replies, read back over IMAP so placement is measured per provider rather than assumed. It connects over OAuth for Gmail and Outlook, or over SMTP and IMAP for SendGrid, Amazon SES, Mailgun, Postmark and custom SMTP, and it runs alongside whatever platform sends your campaigns — it does not replace it.