# Dedicated sending IPs

A sending address of your own, with a 17-day warmup schedule the sender enforces rather than suggests, and marketing kept off your transactional IP.

A dedicated IP means your sending reputation is yours: nobody else's bad week affects you, and your good record is not diluted. It also means the reputation starts at nothing, and a new address that sends a million messages on day one is a new address that gets filtered. The warmup here is a schedule the sender enforces, not a page of advice.

## Seventeen days, and the cap is real

The ramp runs 50, 100, 500, 1,000, 5,000, 10,000, 20,000, 40,000, 70,000, 100,000, 150,000, 200,000, 300,000, 400,000, 500,000, 750,000, and then a million a day. Capacity is reserved per message with a compare-and-swap against the day's counter, so the cap is arithmetic rather than a warning. If a send fails the slot is given back.

## Overflow spills onto the shared pool instead of failing

Hitting the day's cap does not bounce your mail. The planner returns a warmup overflow and the message goes out on the shared pool of the same class, which is a pool with an established reputation. Your ramp stays intact and your mail still arrives, which is the outcome you actually wanted from a warmup schedule.

## A day you barely used does not count

The schedule advances daily, but a day that used less than a quarter of its allowance repeats instead of advancing. Warming an address is about showing a receiving server a rising volume of wanted mail, and stepping from 50 to 100 to 500 while sending nine messages a day teaches it nothing.

## Marketing and transactional never share an address

Pools are named for their class and the class is derived from the send itself, not from a field a caller can set: anything that is a broadcast or a list send is marketing, always. A pool name that cannot be parsed makes its address eligible for nothing rather than defaulting to something. Your receipts do not sit behind a promotion in a filter.

## You do not need to touch SPF

Your SPF record already includes amazonses.com, and a dedicated address is inside that. Reverse DNS is set up for you as part of provisioning and the API reports the live forward-confirmed lookup, so you can check it rather than trust it.

## The API

| Endpoint | What it does |
| --- | --- |
| `GET /v1/ips` | Your addresses, the shared pools for both classes, the default region, and the residency statement. |
| `GET /v1/ips/:id` | One address, plus a live forward-confirmed reverse DNS check. |
| `PATCH /v1/ips/:id` | Pause it, or set a daily cap. Both only ever narrow: nothing raises the schedule. |

## Where an address is in its warmup

warmup_state is one of pending, warming, ready, paused, or retired.

```bash
curl -sS https://emails.sh/v1/ips \
  -H "Authorization: Bearer $EMAILSSH_API_KEY"

# Each entry carries ip, region, region_label, mail_class, pool_name,
# warmup_state, warmup_day, daily_cap, sent_today, day, assigned_at,
# warmup_started_at, and warmup_completed_at.
#
# To hold an address back while you investigate a spike:
curl -sS -X PATCH https://emails.sh/v1/ips/$IP_ID \
  -H "Authorization: Bearer $EMAILSSH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"paused": true}'
```

## What this does not do

### Buying one is self-serve; provisioning it is not instant

It is a paid add-on you buy from the billing screen, per address per month. What follows is not an API call: we acquire the address, publish its forward record, get the reverse DNS set, and assign it, and only then does it appear at GET /v1/ips. There is no POST to create one, so the REST API is for reading an address and for narrowing what it may do, never for provisioning.

### One address per class per workspace

Assignment is one to one. A workspace can hold a transactional address and a marketing address, not a pool of six with traffic split between them.

### Nothing raises the cap

PATCH accepts a daily cap, and it can only be lower than the schedule's. There is no override, no "we know what we are doing" flag, and no support ticket that produces one. A ramp you can skip is not a ramp.

### No per-IP reputation metrics

Reputation is reported per domain, not per address. There is no Google Postmaster style per-IP score in the product.

### A dedicated IP is often the wrong answer

Below roughly a few hundred thousand messages a month, a shared pool with an established reputation beats an address of your own with none, and the intermittent volume that makes a dedicated IP attractive is exactly the volume that makes it perform worse. Ask us before you buy one.

## Questions

### Do I need to change my DNS?

No. Your SPF record already includes amazonses.com, which covers a dedicated address, and reverse DNS is set up on our side. If you have a custom tracking domain that is a separate CNAME and is unrelated to this.

### What happens if I exceed the day's warmup cap?

The message goes out on the shared pool for the same class instead of failing. Your ramp is unaffected and your mail is delivered.

### Can I use one IP for both marketing and transactional mail?

No, and refusing that is deliberate. A complaint rate driven by a campaign should not be able to reach the address your password resets go out from.

### How long until it is at full speed?

Seventeen days if you use each day's allowance. A day below a quarter of its allowance repeats, so a slow ramp takes longer, which is the correct behaviour rather than a penalty.

### What does a dedicated IP cost?

A per address, per month add-on, bought from the billing screen on any workspace with a subscription rather than gated behind an enterprise agreement. The current figure is on the pricing page. It is still worth asking us whether you need one before you buy it, because below roughly a hundred thousand messages a month the answer is usually no.

## Related

- [Deliverability](https://emails.sh/features/deliverability.md)
- [Analytics](https://emails.sh/features/analytics.md)
- [SMTP relay](https://emails.sh/features/smtp-relay.md)

Docs: https://emails.sh/docs.md