# How SMTP Relay sending limits work

> How the monthly allowance, its buffer and the hourly limit work, and how the hourly limit rises as your relay sends clean mail.

Source: https://docs.coritan.com/mail/smtp-relay/sending-limits/

In the dashboard:

- /dashboard/mail/…/overview: https://www.coritan.com/dashboard/mail

An SMTP Relay service has two sending limits. The *monthly allowance* is how many emails the relay may send in a calendar month, and the plan sets it. The *hourly limit* is how many emails the relay sends in an hour. It starts small on every new relay and rises as the relay builds a clean sending history. Both are on the service's **Overview** tab in the dashboard.

## The monthly allowance

The free plan includes 3,000 emails a month and stops there. Each paid plan includes more and adds a 12% *buffer*: the relay can send 12% more than the plan's number before sending stops. On a plan of 25,000 emails a month, the allowance is 28,000. The [Mail page](https://www.coritan.com/solutions/mail) lists the plans and their prices.

We count like this:

- Each message we accept counts once, however many recipients it has. The send API sends a marketing message as one copy for each recipient, so each copy counts.
- A message counts when we accept it, whether it is later delivered, deferred or bounced. A message we refuse does not count.
- The count starts again at 00:00 UTC on the 1st of each month.
- We add up accepted messages once an hour, so the count trails your sending by up to about an hour.

The first figure on the **Overview** tab is **Emails this month**, or **Emails this month (with buffer)** on a paid plan. It shows the count against the allowance and when it resets. A relay that our staff set up with no monthly cap shows **No monthly cap**.

## What happens near the allowance

As the count rises, we email you at your account's address, and the **Overview** tab shows an alert:

| When the count reaches | Email subject | Alert on the Overview tab |
| --- | --- | --- |
| 80% of the plan's number | `SMTP relay #4812: 80% of this month's emails used` | **Monthly allowance almost used** |
| 90% of the plan's number | `SMTP relay #4812: 90% of this month's emails used` | **Monthly allowance almost used** |
| The plan's number, on a paid plan | `SMTP relay #4812: monthly allowance reached` | **Monthly allowance reached; sending from the buffer** |
| The plan's number, on the free plan | `SMTP relay #4812: monthly allowance reached` | **Sending has stopped for this month** |
| The allowance, buffer included | `SMTP relay #4812: sending has stopped for this month` | **Sending has stopped for this month** |

The subject starts with the relay's service ID. We send each email once a month. When the count passes several points between two counts, we send only the email for the highest. While the relay sends from its buffer, the alert says how many emails the buffer still covers.

Once the count reaches the allowance, we refuse new mail:

- Over SMTP, the relay answers `550 5.7.1 Monthly allowance and its 12% buffer are used up; upgrade the plan to continue`. On the free plan it answers `550 5.7.1 Monthly sending allowance reached; upgrade the plan to continue`.
- The send API answers `429` with the same text in `detail`.

Both check the count plus the recipients of the message in hand. Near the end of the allowance, a message to many recipients can be refused while a message to one recipient still goes out. Because the count trails by up to about an hour, a relay can go past its allowance by up to about an hour of sending before we refuse mail.

Sending starts again at 00:00 UTC on the 1st. Each alert has **Change plan**, which opens the service's **Billing** tab. The plan-change dialog there only moves a service between billing cycles of the same plan, and each relay plan is a plan of its own, so it cannot move the relay to a larger plan. To raise the allowance before the month ends, [contact support](/support/conversations/).

## The hourly limit

The hourly limit caps how many emails the relay sends in an hour, which protects the reputation of the addresses it shares with other senders. A new relay starts with a small limit, and a daily review raises it one step at a time. The steps are 100, 250, 500, 1,000, 2,500, 5,000, 10,000, 25,000 and 50,000 emails an hour.

Mail over the limit waits in the queue and goes out in a later hour. While it waits, the **Events** tab can show `deferred` events for it. If mail keeps arriving faster than the limit, the queue grows, and once six hours of mail at the hourly limit is waiting, we refuse new messages until the queue shrinks.

### How the limit rises

The review runs once a day and raises the limit one step when all of these are true:

- The relay has sent clean mail for its first 14 days, or has sent 5,000 clean messages sooner. Clean means the next rule holds.
- The relay is not under review, and its sending is not paused.
- Over the last 14 days, fewer than 2% of the messages it sent bounced and fewer than 0.1% drew a complaint.
- The relay has had its current limit for at least 2 days.
- In the last 14 days it sent at least 12 times its hourly limit, such as 1,200 messages at 100 an hour.
- The next step is not above the plan's automatic ceiling.

A raised limit takes effect within about an hour.

The *automatic ceiling* is the highest step at or below the plan's monthly emails divided by 25: a rate at which the relay could send the plan's monthly emails in about a day. A relay with no monthly cap can climb every step.

| Emails a month | Automatic ceiling |
| --- | --- |
| 3,000 | 100 an hour |
| 25,000 | 1,000 an hour |
| 50,000 | 1,000 an hour |
| 100,000 | 2,500 an hour |
| 250,000 | 10,000 an hour |
| 500,000 | 10,000 an hour |
| 1,000,000 | 25,000 an hour |

On the free plan, the limit does not rise above 100 on its own. Once the limit reaches the ceiling, the **Hourly limit** card says **This plan's automatic ceiling is reached; ask for more below**. To go higher, [request a higher limit](/mail/smtp-relay/request-a-higher-limit/): our staff can set any limit, above the top step too. Changing the plan does not change the hourly limit, only the ceiling the review can reach.

The limit can also go down. When a relay goes under review or has its sending paused, or when 2% of its messages in the last 14 days bounce or 0.1% draw a complaint, the next daily review can set its limit back to the starting limit.

### The Hourly limit card

On the **Overview** tab, the **Hourly limit** card shows:

**Current limit**
: The limit now, such as `250 emails an hour`.

**Next step**
: The step the review raises the limit to next. The card leaves it out once the next step is above the plan's ceiling.

**Set**
: How and when the current limit was set: **Starting limit**, **Raised automatically**, **Set by support** or **Reset after a reputation review**, then how long ago.

**Request limit increase…** asks our staff for more. See [Request a higher hourly limit](/mail/smtp-relay/request-a-higher-limit/).

## Dedicated sending addresses

A relay sends from addresses it shares with other relays unless it has a *dedicated address*: an IPv4 address that only your relay sends from, with a reverse DNS name of its own. Its reputation depends on your mail alone.

- Plans of 250,000 emails a month and more include one dedicated address.
- On plans of 100,000 emails a month and more, you can add dedicated addresses for $50 a month each. Each one you add is a service of its own, with its own invoice ([Dedicated IP add-ons](/mail/billing/#dedicated-ip-add-ons)).

You add one with **Order dedicated IP** on the **Sending IPs** card of the **Overview** tab, which opens the address's order page ([Order a dedicated sending IP](/mail/order-a-mail-service/#order-a-dedicated-sending-ip)). On a smaller plan the button is greyed out, and the card says which plan you need.

Until we have assigned an address, the card says **We are assigning your dedicated addresses**. Then it lists each address with its reverse DNS name and its current hourly cap, such as `500/h`. A **Warming up** badge shows until the address reaches its last stage ([Warm-up](#warm-up)). An address you bought on its own has an **Add-on** badge, and one that is turned off has a **Disabled** badge. From then on, the relay's mail leaves from its dedicated addresses.

When you [cancel](/billing/cancel-a-service/) a dedicated address you bought on its own and it ends, we release the address. When a relay's last dedicated address goes, its mail goes back to the shared addresses. Cancelling the relay does not cancel the addresses you bought on their own, so cancel those too.

### Warm-up

Mail providers distrust a new address that suddenly sends a lot. So each dedicated address starts with a small hourly cap, which rises in stages:

| Stage | Hourly cap | Emails to send in the stage |
| --- | --- | --- |
| 0 | 50 | 200 |
| 1 | 200 | 800 |
| 2 | 500 | 2,000 |
| 3 | 1,000 | 4,000 |
| 4 | 2,000 | 8,000 |
| 5 | 5,000 | 20,000 |
| 6 | 10,000 | 40,000 |
| 7 | 20,000 | 80,000 |
| 8 | None of its own | — |

We check once a day. An address moves up one stage when it has spent at least 2 days in its stage, sent the emails the table gives, and kept bounces under 2% and complaints under 0.1% in that stage. We can also hold every address in a region at its stage for a while, when large providers are filtering mail from that region. From stage 8, only the relay's hourly limit applies.

During warm-up, mail to Gmail, Microsoft (Outlook.com, Hotmail, Live and MSN), Yahoo (with AOL) and Apple (iCloud) has a cap of its own at each address: a quarter of the address's hourly cap, and at least 10.

Mail over a cap waits in the queue, as mail over the hourly limit does. A warming address can have a lower cap than the relay's hourly limit, so plan large sends for after the warm-up.

## With the API

[`GET /client/smtp-relay/{service_id}/usage`](/api/reference/client/mail/smtp-relay/#op-get-api-v1-client-smtp-relay-service-id-usage) returns the month's count, a daily series and the relay's limits:

```bash
curl "https://api.coritan.com/api/v1/client/smtp-relay/4812/usage?days=3" \
  -H "Authorization: Bearer $CORITAN_TOKEN"
```

`days` is how far back the series goes, 1–365 days, and 30 when you leave it out. A value outside that range answers `422`.

```json
{
  "series": [
    {"day": "2026-09-14", "sent": 1204, "delivered": 1187, "bounced": 6, "deferred": 23, "complaints": 0},
    {"day": "2026-09-15", "sent": 1318, "delivered": 1296, "bounced": 9, "deferred": 31, "complaints": 1},
    {"day": "2026-09-16", "sent": 612, "delivered": 598, "bounced": 3, "deferred": 12, "complaints": 0}
  ],
  "month_to_date_sent": 21460,
  "quota_messages_month": 25000,
  "quota_buffer_pct": 12,
  "monthly_allowance": 28000,
  "limits": {
    "monthly_messages": 25000,
    "quota_buffer_pct": 12,
    "monthly_allowance": 28000,
    "month_to_date_sent": 21460,
    "remaining": 6540,
    "over_quota": false,
    "sending_stopped": false,
    "free_tier": false,
    "domains": null,
    "credentials": null,
    "rate_per_hour": 250,
    "hourly_limit_since": "2026-09-11T04:15:09.482113+00:00",
    "hourly_limit_source": "auto",
    "hourly_limit_next": 500,
    "hourly_limit_auto_ceiling": 1000,
    "dedicated_ip_count": 0,
    "dedicated_ip_addon_eligible": false,
    "dedicated_ip_min_monthly": 100000
  }
}
```

`series`
: One entry for each day with mail, oldest first, from `days` days ago up to today (UTC). Each has the `day` and its counts: `sent` (messages accepted), `delivered`, `bounced`, `deferred` and `complaints`. Days with no mail are left out.

`month_to_date_sent`
: Messages accepted since the 1st, as of the last hourly count.

`quota_messages_month`, `quota_buffer_pct`, `monthly_allowance`
: The plan's emails a month, the buffer as a percentage, and the allowance they make together. A `quota_messages_month` of `0` means no monthly cap.

`limits`
: The relay's limits. The service summary, [`GET /client/smtp-relay/{service_id}`](/api/reference/client/mail/smtp-relay/), returns the same object.

The fields in `limits`:

`monthly_messages`, `quota_buffer_pct`, `monthly_allowance`, `month_to_date_sent`
: The same figures as at the top level.

`remaining`
: What is left of the allowance, never below `0`. `null` with no monthly cap.

`over_quota`
: `true` once the count reaches the plan's number, so the relay is sending from its buffer or has stopped.

`sending_stopped`
: `true` once the count reaches the allowance.

`free_tier`
: `true` on the free plan.

`domains`, `credentials`
: How many sending domains and SMTP credentials the plan allows. `null` means no cap.

`rate_per_hour`
: The hourly limit.

`hourly_limit_since`
: When the hourly limit was set.

`hourly_limit_source`
: How it was set: `start`, `auto` (the daily review), `staff` or `reset`.

`hourly_limit_next`
: The next step, or `null` above the top step. The review raises the limit to it only when it is not above `hourly_limit_auto_ceiling`.

`hourly_limit_auto_ceiling`
: The highest limit the review reaches on this plan.

`dedicated_ip_count`
: How many dedicated addresses the relay has, from the plan and bought on their own.

`dedicated_ip_addon_eligible`
: `true` when the plan allows buying more dedicated addresses.

`dedicated_ip_min_monthly`
: The emails a month a plan needs for that: `100000`.

The same operation is under [`GET /client/mail/{service_id}/usage`](/api/reference/client/mail/mail/#op-get-api-v1-client-mail-service-id-usage), which answers for both products. On a Mail Hosting service it returns the `series` and `month_to_date_sent` for the mail its mailboxes send. Mail Hosting has no monthly allowance, so `quota_messages_month`, `quota_buffer_pct` and `monthly_allowance` are `0`, and the answer has no `limits`.

## API

- `GET /api/v1/client/smtp-relay/{service_id}/usage`: Usage report (https://docs.coritan.com/api/reference/client/mail/smtp-relay/#op-get-api-v1-client-smtp-relay-service-id-usage)
- `GET /api/v1/client/mail/{service_id}/usage`: Usage report (https://docs.coritan.com/api/reference/client/mail/mail/#op-get-api-v1-client-mail-service-id-usage)