IP warming as a managed service, for operators who already have their MTA and just need someone competent to warm the IPs

Two reasons. First: the schedule is the easy part. The hard parts are reading Postmaster Tools data correctly, knowing when to flatten the curve versus push through, recognizing the difference between a real reputation signal and noise, and adjusting in response. Most DIY warmings fail not because the schedule was wrong but because the operator did not know how to interpret the signals. We do that interpretation for you. Second: the operational time. A competent deliverability engineer warming a single IP DIY spends 30 to 50 hours of focused work over 21 to 28 days. At fully-loaded cost, that is €1,800 to €5,000. Our pack at €499 is significantly cheaper than the engineering time, and the dynamic curve adjustment produces better outcomes than even an experienced engineer working from a static schedule.

Three differences. First: scope. Lemwarm and Warmbox warm individual mailboxes (Gmail, Outlook accounts) for cold email use cases; we warm IPs for any sending use case (transactional, marketing, cold). Second: detection risk. Synthetic warmup tools that exchange messages between bot accounts have been increasingly detected by major mailbox providers since 2023. Our engagement pool exchanges real-content conversations across actually-engaged inboxes. Third: scale. The mailbox-warming tools cap at maybe 50 mailboxes per account; our IP warming routinely handles /28 blocks (13 IPs) coordinated, with each IP carrying significantly more volume than a single mailbox warmup. Different tool for a different problem.

No. The warming traffic uses your IP as the sending IP, not ours. We provide the relay path and the engagement pool, but the SMTP HELO, the SPF/DKIM authentication, the IP that the receiver sees in the message headers, all of those are yours. Your IP builds its own reputation from the warming traffic. Once the warming engagement closes and you remove the relay configuration, the reputation continues attached to your IP, not transferable to us, not dependent on us. This is the core difference between our service and a managed-ESP migration: we do not take ownership of your reputation.

Two options, customer choice. Option one: full refund of the engagement fee, you keep whatever warming progress was achieved (often partial reputation that you can build on yourself with additional time). Option two: extended engagement at no additional charge until reputation stabilizes, with a hard cap of double the original engagement window. We have not had a single engagement fail to stabilize in the last 18 months, but the warranty exists because warming has inherent probabilistic elements (a Spamhaus listing during the warming, a sudden ESP policy change, a list quality issue we did not catch in discovery) and the contract should be clean about what happens when those events occur.

The engagement pool is around 4,000 actively-engaged inboxes that exchange real content across multiple senders, not bot accounts running automation scripts. The conversations have realistic engagement patterns: opens, replies, archives, label assignments, search activity, folder moves, occasional spam reports (yes, even those). The receivers see traffic that matches the patterns of normal sender networks, not the patterns of synthetic warmup pools. We have been operating this pool since 2023 and refining it continuously. Validity, Mailgun, and Microsoft have all published research about detecting synthetic warmup; our pool design directly addresses the patterns those papers describe.

Yes, with caveats. If your IP was listed on a major blacklist (Spamhaus DBL, SORBS, UCEPROTECT) and is still listed, we cannot warm an actively-blacklisted IP; the listing has to be cleared first (reputation recovery is a different service we offer). If the listing has cleared but reputation has not recovered, warming can rebuild it. If your IP was never blacklisted but reputation deteriorated due to volume or content issues, warming can help but the underlying issue (usually list quality or content) has to be fixed in parallel; warming a new IP without fixing the root cause just transfers the problem to the new IP.

You handle them, with our guidance. We provide the exact configuration lines to add (PowerMTA pmta.conf snippet, KumoMTA Lua block, Postfix transport map entry, etc.), and we walk through them with your engineer on a 15-minute call. The reason we do not apply changes to your MTA directly is operational hygiene: you should not give third-party engineers root access to your production MTA, and we should not be on your MTA writing config that we cannot audit later. The configuration is small (3 to 10 lines for most MTAs), and your engineer applies it after our walkthrough. Total effort on your side is usually under 30 minutes of engineering time.

Each daily report includes: current sending volume versus target curve, Postmaster Tools state (sender reputation, IP reputation, domain reputation, complaint rate, authentication results), Microsoft SNDS state (Green/Yellow/Red status with traffic volume), Sender Score numerical value, blacklist check results across 50+ sources, per-receiver placement breakdown for the top 10 receivers, any curve adjustments made and the rationale. The report arrives by email each business morning during the engagement, with a Slack push if you have configured Slack delivery. Reports are also accessible in the customer dashboard for retroactive review.

For PowerMTA, the configuration adds a new VirtualMTA with our relay address as the smtp-source-host and routes warming-marked traffic through it. For KumoMTA, a Lua function checks message headers for the warming flag and routes to our relay accordingly. For Postfix, a transport map entry routes specific recipient domains through our relay during warming. The data we see during the engagement: SMTP envelope (from, to, message size), message headers, and the timestamp; we do not store message bodies, we do not log content beyond what is needed for delivery diagnostics. Privacy-conscious customers can request the configuration to additionally redact message subject lines from our logs, which we support at no extra charge.

The warming traffic carries customer email content during execution, which makes us a sub-processor under your GDPR contracts. We sign a standard DPA with you before the engagement, our infrastructure runs on EU sub-processors only (this matches our broader EU sovereign positioning), and we delete the engagement logs 90 days after handoff. For customers with stricter requirements (financial services, healthcare, public sector), we offer a custom DPA with shortened log retention and additional confidentiality terms; this is a 1-week negotiation, not a 6-month enterprise procurement.

Yes. We have run customers with up to four parallel engagements (different IP blocks, different MTAs, different volume targets). The engagements are independent and the daily reports separate. Pricing is per-engagement at the published pack rate; no parallel discount because the engineering work is genuinely independent across engagements. For very large customers running fleets of 50+ IPs continuously, the Fleet Warming custom engagement is the right shape; the parallel-pack approach makes sense for occasional bursts but not for ongoing fleet operations.

IPv6 warming is included in every pack at no extra charge, but the practical reality is that IPv6 reputation is distinct from IPv4 reputation at most major receivers and the warming is mostly separate work. We warm both protocols in parallel during the engagement; the IPv4 reputation tends to establish faster because more warming traffic flows over IPv4. For senders who only operate IPv4 (which is most senders even in 2026), we skip the IPv6 portion at no price reduction. For senders with strong IPv6 use cases (rare but exists in some EU markets), we run both with extended monitoring on the IPv6 side.

Two completely different shapes. The /email-sending-servers product includes warming because we are operating the full sending infrastructure on your behalf; warming is part of the bundled service. This /ip-warming product is for customers who already operate their own MTA and just want the warming layer outsourced. Most customers buying /ip-warming are explicitly choosing not to migrate their MTA; the right customer for /email-sending-servers is the one ready to outsource the entire stack. The discovery call clarifies which side of that line you are on, and we are willing to recommend the bundled product over the standalone if it is the better fit.

Dedicated only. Shared IP pool reputation is managed by the ESP that operates the pool; you cannot warm someone else's pool from outside. If you are on a shared pool with reputation issues, the right answer is talking to your ESP, not warming. If you are migrating from shared to dedicated, we warm the dedicated IPs as part of the migration; that is a normal use case for the Single IP or Multi-IP packs. If you are unsure whether your IPs are dedicated or shared (some ESPs use ambiguous language), we can verify during the discovery call.

They run in parallel without interference. The relay configuration only routes traffic flagged as warmup through our infrastructure; your production sends continue going through whatever path they normally use. We coordinate volumes carefully so that your IP's total daily volume (warmup plus production) tracks the warming curve. For customers with substantial production volume already on the IP, we may recommend pausing or reducing production during the first 5 to 7 days of warming, then ramping production back up in coordination with the warming curve. The exact recommendation comes out of the discovery baseline review.

Yes, with caveats. Customers with their own seed list of test mailboxes (typically 50 to 200 mailboxes across major receivers) can substitute or supplement our pool with their seeds. The trade-off is that your seed list is small relative to our 4,000-inbox pool, which means the engagement signals reaching the receiver-side reputation systems are weaker. Customers who use their own seeds usually do so for compliance reasons (specific data-residency requirements, custom NDA scenarios). We can run a hybrid approach where 70 percent of warming volume hits our pool and 30 percent hits your seeds, which preserves the volume-driven reputation signals while accommodating your specific requirements.

For typical use cases targeting standard B2B prospects, the achievable steady-state placement rates are: Gmail recipients, 88 to 94 percent inbox; Outlook/Microsoft 365 recipients, 78 to 88 percent inbox; Yahoo and AOL, 80 to 90 percent inbox; smaller receivers, varies. These ranges assume reasonable list quality and content; bad list quality or aggressive content will drop placement regardless of how well the IP is warmed. The closing report from the engagement includes per-receiver placement breakdown so you have a documented baseline to track against post-handoff. Placement degradation in the first 30 days post-handoff falls under the warranty; degradation after 30 days is a list-quality or content question, not a warming question.

Fleet Warming custom engagements are quoted based on IP count, target volume per IP, geographical distribution, and engagement timeline. Typical pricing for a /27 (29 IPs) lands around €7,000 to €9,000 depending on complexity. A /26 (61 IPs) lands around €13,000 to €18,000. Very large fleets (multiple /27s across regions) get quoted per-engagement; we have run fleet warmings up to 80 IPs in a single coordinated engagement. The discovery call covers the specifics. Customers running ongoing fleet operations (continuously cycling new IPs into the fleet) often shift to a retainer arrangement at €4,000 to €8,000 per month, which is a different product shape from one-time engagements.

Three things during onboarding. First: the IPs to be warmed (specific addresses or the CIDR block) and the rDNS PTR records configured for those IPs (rDNS must match the HELO domain for the warming to work properly). Second: target sending volume after warming completes, broken down by recipient distribution if you have it (US versus EU versus rest of world matters for receiver-side filter behavior). Third: MTA admin credentials or a contact engineer who can apply the relay configuration. We do not need access to your application, your CRM, your customer database, or your email content; we just need the SMTP-side configuration access. Onboarding documentation comes with checklist; most customers complete it within 1 to 2 hours.

Yes, and many customers do. The typical pattern: customer warms initial /29 with the Multi-IP Pack, business grows, customer needs another /29 six months later, customer engages us again for a second Multi-IP Pack. We treat each engagement as independent (no discount for being a returning customer beyond the standard volume tiers), but we do retain the playbook from your previous engagement which makes the second one operationally faster. Returning customers often receive engagement starts in 3 business days instead of 5, simply because we already know your MTA, your sender profile, your authentication setup, and your typical placement metrics. The relationship pays off in operational speed even though it does not show up in the price.

Send us your MTA name and version during the discovery call. The compatibility list covers the platforms we have explicit playbooks for; the broader reality is that any MTA supporting outbound relay configuration can work with us. If your MTA is something custom (forked Postfix, custom Go-based mailer, in-house Rust MTA that nobody else uses), we work with your engineering team to define the relay configuration during onboarding. Custom MTA setups add 1 to 3 days to onboarding because we are designing the integration from scratch rather than running a playbook, but the engagement itself runs the same way once the relay is configured. We have not encountered an MTA we could not work with in the last 18 months, including some genuinely unusual setups.

Yes, three patterns. First: extremely high complaint rates (above 0.3 percent sustained). Recipients clicking "report spam" at scale tells receiver-side filters something the warming cannot override. Second: scraped or purchased lists with high invalid-address rates (above 5 percent bounce rate). Bounces and invalid-recipient signals are weighted heavily and warming traffic cannot mask them. Third: content patterns that match known spam templates (heavy use of caps, certain trigger phrases, excessive linking, low text-to-image ratio). We assess these during the discovery baseline review and we will tell you upfront if the underlying behaviors are likely to make warming unproductive. Better to refund the inquiry at discovery than to refund the engagement after a failed warming.

Mailbox providers ramp trust on observed engagement over real days, and there is no input that compresses that clock. Microsoft and Gmail throttle a new IP regardless of who operates it, so pushing volume early triggers deferrals that set the schedule back rather than forward. The ramp follows replies and opens, not a calendar you choose, which is why a credible warming plan is measured in weeks and refuses to promise a shortcut that the receivers will not honor.