MailReach Warming: What the Docs Say, and Where the Site Disagrees With Itself

Someone about to start cold outbound reads that they need to warm their IP before sending, searches for an IP warming service, and lands on a MailReach page titled exactly that. The page sells them a plan. What the page describes doing, in its own words, is connecting an email address. Whether those are the same purchase is a fair thing to want settled before the card goes in, and MailReach settles it in a FAQ answer sitting on two other pages of the same site.

This piece works entirely from MailReach's own surfaces, fetched in August 2026 and quoted with the page each fact came from. There are three things on those surfaces worth a B2B sender's attention: an unusually direct answer to the IP question, a properly documented API that almost nobody writes about, and a number the site contradicts itself on today.

The commercial side is deliberately not covered here. MailReach's published pricing sits alongside the rest of the category in the warmup services price survey, and how mailbox warmup works in general is covered in the warmup tools review.

The IP question, answered by the vendor

The FAQ block on both /email-warmup-api and /pricing carries this exchange verbatim:

Does MailReach warm my domain and IP or only my email address? MailReach warms the email account, associated domain and associated IP behind. However, if you have multiple sending addresses under one domain and/or under one IP, every address should be warmed in order to generate enough engagement on the domain and/or IP level.

That is a clearer answer than most vendors in this category give, and it has two halves that both matter.

The first half says the unit of work is the email account, and that the domain and the IP reputation behind it move as a consequence of warming that account. For anyone sending through Google Workspace, Microsoft 365, or any of the relay providers, this is the only shape available anyway. You do not have an IP to warm in the sense the phrase implies: you share a large pool of provider IPs with everybody else on that platform, and your influence on it is the engagement your own mail generates. A dedicated IP is a different situation with different rules, and it is a bulk-sending arrangement rather than a cold outbound one.

The second half is the operationally expensive part, and it is easy to skim. Every sending address under one domain needs warming separately for engagement to accumulate at the domain level. So a programme running eight mailboxes on one sending domain does not get domain-level benefit from warming one of them. That single sentence is the honest driver of what a warmup subscription costs at scale, and it is the vendor saying it rather than a competitor.

The page called IP warming is selling the mailbox product

Set the /ip-warming-service page next to what it actually describes and the structure becomes obvious.

Its mechanism section says: "MailReach connects with your email address to automatically start conversations with thousands of inboxes". Its setup instruction says: "Sign up, choose a plan, connect your email address and start the IP warming." Its promotional banner, at the top of that same page, is denominated in mailboxes: "Get 20% OFF for the first 30 days of warming up your first mailbox".

The words "dedicated IP" and "shared IP" do not occur anywhere on that page. Neither concept is discussed, which is a striking absence on a page whose entire premise is IP-level work.

The MailReach API docs describe the commercial model as two billable things: "Warming & Monitoring" charged "Per connected inbox (seat), monthly", and "Spam Checker" charged "Per test run (one credit per test)". There is no third line item for IP warming.

/ip-warming-serviceMarketed as IP warming

• Mechanism described as connecting your email address
• Setup is sign up, choose a plan, connect your email address
• Promo banner priced against warming your first mailbox
• Zero occurrences of dedicated IP or shared IP
• Network of 15,000+ human inboxes

/email-warmup and /email-warmup-apiMarketed as mailbox warmup

• Same mechanism, described as chatting with your email address
• FAQ states warming the account warms the domain and IP behind
• FAQ states every address under a domain needs warming separately
• Network of 30k real human inboxes
• API billed per connected inbox (seat), monthly

None of this is deceptive. Building a landing page around the phrase a buyer actually searches for is ordinary practice, and the FAQ answer above means the vendor is not hiding the relationship. It is worth knowing before the purchase, because it tells you the thing you are buying is counted in mailboxes, and your bill will grow with mailbox count rather than with anything IP-shaped.

The same page also argues a point of terminology, in an answer that carries a typo the vendor has not caught: "IP warm up and IP warming are similar but IP warming is the most relevant way of calling it", because stopping once campaigns begin "is a bad pratice". Keep the typo in mind. It comes back below.

The API is the surface that says what the product actually does

Marketing pages describe benefits. A resource list describes a product. MailReach's docs at docs.mailreach.co publish a real one, and it is the most informative thing on the entire site.

The base URL is https://api.mailreach.co/api/v1. Authentication uses an API key in the X-Api-Key header, prefixed with Bearer, and the docs state plainly that "Requests with a missing or invalid key return 401 Unauthorized". A worked first call is given as a POST to https://api.mailreach.co/api/v1/spam_tests with the body {"seedlist": 1}.

The docs describe the API's scope as follows: "Use it to run email spam tests, connect and manage inboxes for warming and monitoring, pull deliverability statistics, and automate every workflow available in the MailReach app."

The endpoint reference is grouped into ping, config, projects, accounts, notifications, conversation_statuses, conversation_message_logs, domain_blacklists, tags, stats, alerts, spam_tests, email_workspaces and automated_tests. Read that list as the product's real surface area. Conversation message logs and conversation statuses tell you the warming conversations are individually addressable. Domain blacklists tell you blocklist checking is a first-class resource rather than a dashboard widget. Email workspaces plus the documented "batch workspace import" tell you the product expects to be pointed at a whole Google or Microsoft tenant.

Two details deserve calling out for anyone planning to automate against it.

The statistics resource is offered as a way to "pull daily time-series data to build your own deliverability dashboard". That is the feature that lets a deliverability signal live in your own reporting rather than in a vendor's tab, which is the difference between a number somebody notices and a number nobody opens.

And the docs state: "The API does not currently support idempotency keys." Take that seriously if you are writing anything that retries. A create call that times out after the server processed it, retried, produces a second resource. The docs give the workaround themselves, which is to check for an existing resource before creating one, or use the returned id to update rather than re-create. Pagination is page and per_page, with results in descending creation order.

The commercial framing in the docs is worth one line: "The API itself is free." Calling the API costs nothing and you are billed on platform usage. In a category where API access is routinely an enterprise-tier upsell, that is a genuine differentiator and nobody writes about it.

1. Step 1Get the key

   The API key lives on the Settings tab of a project

2. Step 2Authenticate

   X-Api-Key header prefixed with Bearer, or a 401 comes back

3. Step 3Connect inboxes

   IMAP/SMTP or OAuth for Gmail and Outlook, including batch workspace import

4. Step 4Enable warming

   Turn it on from account settings once the inbox is connected

5. Step 5Pull statistics

   Daily time series into your own dashboard, paginated with page and per_page

The site disagrees with itself about the network size, today

This is the finding that should change how you read any vendor number.

MailReach's /email-warmup page states "Network of 30k real human inboxes" and, beneath it, "More than 30k high-reputation inboxes are ready to chat with your email address." The /email-warmup-api page carries the identical pair of claims.

The /ip-warming-service page states "Network of 15,000+ human inboxes", and beneath it, "More than 15k high reputation inboxes are ready to warm your IP."

All three pages were fetched on the same day. Both figures are live on mailreach.co right now.

30kStated on /email-warmup and /email-warmup-api

Network of 30k real human inboxes

15,000+Stated on /ip-warming-service

Network of 15,000+ human inboxes

Which one is current cannot be established from outside. What can be established is that the IP warming page reads as a legacy landing page throughout: it carries the uncorrected "pratice" typo quoted earlier, it lists compatible providers as "Gmail / G Suite, Outlook / Office365, SendGrid, MailGun, Custom STMP, etc." with SMTP misspelled, and it omits the warmup guidance its sibling pages carry. The 15,000+ figure most likely dates from whenever that page was last touched.

The general lesson travels well beyond this vendor. A page can be live, indexed, ranking and years out of date at the same time, and none of those states is visible to a reader or to a search engine. A figure quoted from such a page inherits its staleness silently. This is why a number belongs to a URL and a date rather than to a company: "MailReach claims 30k inboxes" is a sentence that cannot be checked, while "the /email-warmup page stated 30k in August 2026" can be, by anyone, forever.

Apply that when comparing vendors. Half the numbers in any comparison table were copied from a page nobody has audited, and the ones on competitor comparison pages are the least reliable of all. The alternatives comparison sets the field out with each figure attributed.

What warming does not fix

Warming generates engagement signal on a mailbox, and it accrues to the domain and the infrastructure behind it. That is a real input to sender reputation and it is table stakes for cold outbound.

It does not repair a bad list, and bounces to dead addresses damage domain reputation faster than warming rebuilds it. It does not clear a domain already on a blocklist. It does not get you past a recipient-side security gateway that has decided about your domain, and it does nothing about an offer nobody wants. Warming a mailbox attached to any of those problems buys an expensive delay.

We run managed warmup across our own sending inventory, and the honest position is that warmup is the least interesting part of making cold email land. The parts that decide outcomes are list quality, domain age and configuration, per-inbox volume discipline, and how fast a damaged domain gets pulled from rotation. Setting a new domain up properly in the first place is covered in the domain warmup guide, and checking where a domain currently stands is covered in the sender reputation check.

Before you buy or integrate

• ✓Yes: Count every sending address, since the FAQ says each one under a domain needs warming separately
• ✓Yes: Read the FAQ answer on /pricing or /email-warmup-api if you are trying to settle the IP question
• ✓Yes: Handle retries yourself, because the docs state idempotency keys are not supported
• ✓Yes: Check the date and the page behind any network or capability figure before quoting it
• ✕No: Assume /ip-warming-service is a separate product with separate billing
• ✕No: Treat a warmup subscription as a fix for list quality or an existing blocklisting

The short version

MailReach sells mailbox warming, and its own FAQ states that warming the account warms the domain and IP behind it, with every address under a shared domain needing its own warming. The page marketed as an IP warming service describes that same mailbox product and never once mentions dedicated or shared IPs. The API is documented properly, covers fourteen resource groups, costs nothing to call, and does not support idempotency keys. And the site publishes two different network sizes on two pages on the same day, which is the most useful thing on it, because it shows exactly how much weight any vendor figure will carry.

If warming is a job you would rather not own at all, the whole programme can sit with us instead: prepay one qualified meeting, and if we do not book it within 30 days you get a full refund.

Pricing and features verified as of August 2026. Verify current terms with the vendor before relying on them.