All solutions

Solutions

Email Service That Handles Dedicated IPs and Warmup Options

An email service that handles dedicated IPs and warmup options should answer two questions honestly: do you need a dedicated IP, and do you need warmup? On Mails.ai your agent sends from day one on a shared rail with an established sending record — there is nothing to warm, and no schedule to run. A dedicated IP is available on request on the Scale plan for senders approaching several hundred thousand messages a month. Below that volume a dedicated IP starts cold and is harder to maintain than the warm shared pool it replaces.

What “handles dedicated IPs and warmup” actually means

Most buyers searching this phrase have two concerns: will I get a dedicated sending IP, and does the service manage the warmup process so I do not have to? Both are legitimate questions, and both deserve an honest answer before you commit to a platform.

Mails.ai's answer: the shared rail is already warm, and a dedicated IP is available when your volume actually justifies one. We would rather tell you which option fits your send volume than sell you a product feature that hurts delivery below a certain threshold.

The shared rail — warm from message one

Every agent on Mails.ai sends from a workspace subdomain (agent@yourworkspace.mails.ai) on a shared sending infrastructure with an established record. There is no ramp period, no seed network to subscribe to, and no warmup schedule to manage.

What keeps that rail warm is policy, not a tool: cold outreach is refused at the API, not discouraged in a terms-of-service document. The mail that moves through the shared infrastructure is real transactional and agent mail with low complaint rates — and that record is what your agent inherits on its first send.

  • No warmup wait before your first message
  • No seed-network subscription alongside your email plan
  • Per-agent reputation scoring keeps individual agents from affecting each other
  • Custom domains get a DKIM keypair automatically — publish one DNS record and sends switch to your brand domain once it verifies

Dedicated IPs — when they help and when they do not

A dedicated IP isolates your sending from every other sender on the platform. Your placement cannot be hurt by another sender's behaviour — and also cannot be helped by the warm record they have built. You start from zero.

Getting from zero to a stable reputation requires sustained volume. The floor the industry usually publishes is around 300,000 messages a month. Below that, a dedicated IP has too little traffic to establish or hold a reputation with mailbox providers. At low to mid volume, dedicated usually delivers worse than shared — not better.

At high and consistent volume, isolation becomes an asset: your placement is entirely yours to control. If that describes your send profile, a dedicated IP is available on request on the Scale plan.

What the warmup process actually involves

If you do move to a dedicated IP, the ramp is built from your real mail — not from a seed schedule. Any provider quoting you a fixed number of days is quoting a schedule; mailbox providers weight opens, replies and complaints from real recipients, and only real traffic produces those. What throttling a ramp schedule does is avoid tripping rate-heuristics while your volume builds. It does not create reputation on its own.

On the shared rail there is no warmup to manage at all — the infrastructure is already sending at scale and your agent inherits that record:

# Send from your agent — no warmup state to wait on
curl https://api.mails.ai/v1/messages \
  -H "Authorization: Bearer $MAILS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "support",
    "to": ["customer@example.com"],
    "subject": "Your request is ready",
    "body_text": "Here is what you asked for..."
  }'

# Check your domain's verification state
curl https://api.mails.ai/v1/domains/dom_123 \
  -H "Authorization: Bearer $MAILS_API_KEY"

# {
#   "id": "dom_123",
#   "domain": "mail.yourapp.com",
#   "status": "verified",         // pending -> verifying -> verified
#   "provider": "ownmetal",
#   "dns_records": [ /* each with "verified": true */ ],
#   "fail_reason": null
# }

Choosing between shared and dedicated

A quick heuristic: if you are sending under 100,000 messages a month, the shared rail delivers better than a dedicated IP would from the same starting point. Between 100,000 and 300,000 the answer depends on your complaint rate and sending patterns — ask and we can look at the data with you. Above 300,000 consistently, isolation starts to pay for itself.

Either way, the mechanics of sending do not change. Same workspace, same API, same dashboard — a dedicated IP is a routing change under the hood, not a product migration. And you can move back to the shared rail at any time.

Why one platform covers both dedicated IPs and warmup

Most buyers evaluating an email service for dedicated IPs and warmup options end up cobbling together two products: a sending provider and a warmup tool on top. Mails.ai does not offer a warmup tool — because the shared rail is already warm and a dedicated IP warms through your real traffic, not a seed loop.

What you get from a single platform instead of two:

  • No warmup dashboard to manage. The shared rail has an established sending record before your first message. Dedicated IPs warm through your actual send volume — there is no parallel seed service to run.
  • Reputation tracking in one place. Per-agent scores, complaint rates, and suppression lists live in the same workspace as your IP configuration.
  • No product migration when you scale. Moving from the shared rail to a dedicated IP is a request, not a re-integration. The API, SDK, and dashboard stay the same.
  • Honest gatekeeping.Cold outreach is refused at the API — that is what keeps the shared rail's record clean. You do not need to manage the hygiene of a warmup loop on top of it.

For the full arithmetic on dedicated IPs: see Dedicated IP — how it works and when you need it. For why most senders skip standalone warmup tools: Email Warmup Service — Why We Don't Sell One. For the ramp mechanics in detail: Automated Dedicated IP Warm-Up — And Why You Probably Should Not.

What to ask when evaluating an email service for dedicated IPs and warmup

If you are comparing email services on these two criteria, here are the four questions that expose the real differences between providers:

  • Is the shared pool warm on day one, or do I have to ramp it?A shared rail that requires a warmup period is either new infrastructure or a pool that has not been carefully gated. Mails.ai's shared rail has an established record because cold outreach is refused at the API — not discouraged in a policy document.
  • Is a dedicated IP self-serve, or is there an honest qualification step? A provider that sells dedicated IPs to anyone — including senders under 100,000 messages a month — is selling you a cold IP that will deliver worse than the shared pool. The right answer is “on request, and we will check your volume first.”
  • Does the warmup happen through real mail or a seed network? Seed networks generate artificial engagement signals. Mailbox providers weight opens, replies and complaints from real recipients; seeds can fill a schedule but do not build a reputation. A dedicated IP warms through the traffic you actually send.
  • Is IP routing a migration or a config change? If moving to a dedicated IP requires a new integration, you are looking at a different product tier — not a routing change. On Mails.ai it is a request; the API, SDK and dashboard stay identical.

Frequently asked questions

Do I need a dedicated IP with this email service?

Almost certainly not yet. A dedicated IP only earns a reputation from sustained volume — the figure the industry usually publishes is around 300,000 messages a month. Below that, your own IP starts cold and delivers worse than the shared rail you already have. A dedicated IP is available on request on the Scale plan for senders where the volume justifies it.

How does warmup work for a new sender?

On the shared rail there is nothing to warm — your agent inherits an existing sending record from its first message. There is no ramp to schedule, no seed network to buy, and no warmup period to wait through. For your own custom domain, DKIM is provisioned automatically and sends travel over mail servers we own and keep warm.

What dedicated IP options are available?

Dedicated IPs are available on request on the Scale plan rather than as a priced self-serve add-on, because whether one helps depends on your volume. If you are sending several hundred thousand messages a month consistently and want your placement insulated from other senders, ask — we will look at that with you. If you are not at that volume, the honest answer is that the shared rail serves you better.

Can I handle both dedicated IPs and warmup from one platform?

Yes. Mails.ai manages the shared sending infrastructure — warm rails, DKIM for custom domains, complaint monitoring and suppression — from a single workspace and API. Adding a dedicated IP on Scale does not change how you send: same SDK, same dashboard, same domain. The warmup of that IP happens through your own real mail, not a seed service.

What does a dedicated IP cost?

It is not a self-serve line item because the right answer depends on your volume. Dedicated IPs are available on request on the Scale plan. If your volume is well under a few hundred thousand messages a month, we would rather say so than sell you an IP that starts cold and delivers worse than the pool.

How is this different from a standalone IP warmup tool?

Standalone warmup tools (Warmbox, Lemwarm, etc.) circulate your domain through seed inboxes to manufacture engagement signals. We do the opposite: cold outreach is refused at the API rather than discouraged in a policy, which is what keeps the shared rail's record clean. A shared rail that never sends cold mail does not need an artificial warmup loop.

Does this email service handle both dedicated IPs and warmup from one dashboard?

Yes — sending infrastructure, reputation monitoring, suppression, domain verification, and dedicated IP routing are all managed from a single Mails.ai workspace. There is no separate warmup dashboard because the shared rail does not need one. If you add a dedicated IP on Scale, its traffic and reputation data appear in the same workspace alongside your other agents.

Live now

Built for agents.
Self-serve in minutes.

The API is live and self-serve. Drop ~6 lines into your agent and ship.

npmpnpmbunnpx
$ npm install @mailsai/sdk
Live on npm today · @mailsai/sdk + @mailsai/mcp-server