Automated Dedicated IP Warm-Up — And Why You Probably Should Not

What automated warm-up actually means

Most providers hand you a fresh dedicated IP and a warmup guide: start at 500 sends on day one, double every few days, avoid spikes, manage the ramp yourself for a month. “Automated” warm-up means the provider runs that schedule for you.

It is worth being precise about what a schedule can and cannot do. Throttling volume avoids tripping rate heuristics. It does not create a reputation. Mailbox providers weight opens, replies, complaints and spam-folder rescues from real recipients — signals only your real mail produces. A ramp schedule paces the traffic; the traffic is what earns the standing.

Why a dedicated IP usually makes delivery worse, not better

This is the part the category does not advertise. A dedicated IP isolates you from other senders — which also means you lose the warm record those senders have built, and you are starting from nothing. Getting back to neutral requires sustained volume, and the floor the industry usually publishes for that is around 300,000 messages a month.

Send a few thousand a month from your own IP and mailbox providers never gather enough signal to form a stable view of it. Worse, an IP that goes quiet goes cold: the standing you did build decays between sends. Most transactional and agent senders are far below the line where a dedicated IP helps, so the shared rail — already warm, continuously sending, actively policed — is the better placement.

What Mails.ai does instead

• Your agent sends from agent@yourworkspace.mails.ai on a shared rail with an existing sending record, and inherits it from the first message
• Cold outreach is refused by the API rather than discouraged in a policy, which is what keeps that shared record clean for everyone on it
• Your own domain gets a DKIM keypair generated automatically and sends over mail servers we own and keep warm
• A dedicated IP is available on request on the Scale plan, when your volume justifies it

Watch the signal that actually matters

Rather than tracking a ramp schedule, watch delivery and complaints on the mail you are really sending. Every send is scored and every inbound event carries reputation data, so the question “is my sending healthy?” is answerable from the API:

# Your domain's verification state (what actually gates custom-domain sending)
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
# }

# Delivery outcomes on real traffic — the signal a ramp schedule cannot fake
curl "https://api.mails.ai/v1/events?event_type=message.delivered" \
  -H "Authorization: Bearer $MAILS_API_KEY"

When a dedicated IP does make sense

There is a real case for one, and it is a volume case: you are sending hundreds of thousands of messages a month, consistently, and you want your placement insulated from every other sender on the rail. At that scale the IP gets enough traffic to establish and hold a reputation, and isolation becomes an asset rather than a handicap. If that is you, ask — it is available on the Scale plan. If it is not you yet, the most useful thing we can tell you is not to buy one. See dedicated IP for the detail, or free email warmup for why the shared rail needs no warming at all.