Sending limits

What limits how much you can send, and what happens when you reach a limit.

Send responses carry ratelimit-limit, ratelimit-remaining and ratelimit-reset for the monthly quota. When a daily limit applies, they also carry ratelimit-daily-limit, ratelimit-daily-remaining and ratelimit-daily-reset (Unix time of the next 00:00 UTC), so you can see a limit coming before you reach it.

New accounts ramp up

New accounts ramp up their sending over their first days. Mailbox providers judge new sending volume by its history, and our sending IPs are shared, so a sudden large send from an account with no history can hurt delivery for everyone on them, you included. Ramping up keeps your mail landing in the inbox.

How it works:

• You start at 1,000 recipients a day of product email (category product) and 3,000 a day of transactional email (sign-in codes, receipts, alerts; the default category). The two are counted separately.
• The limit doubles each day after a day where you used at least half of it, as long as your bounce rate stays under 2% and your complaint rate under 0.1% over the last three days. Rates are only judged once you have sent at least 200 emails in that window.
• If bounces or complaints are high, the limit holds until they come down. It does not grow on a quiet day either: it grows when you need the room.
• The ramp ends once your daily limit reaches your plan's monthly volume (for example 50,000 on Pro 50k). From then on only your plan's limits apply.
• Counted: recipients (to, cc and bcc) per UTC day, across the API, batch sends, SMTP, scheduled sends and automations. Sends to your own account email from the sandbox address are not counted.
• Days roll over at 00:00 UTC, when the count resets and the limit can grow.

So a sender who keeps bounces and complaints low and uses the room can go from 1,000 to 64,000 product emails a day in about a week.

Why transactional email gets more room. Sign-in codes and password resets have to arrive even on a busy first day, so transactional email has three times the product limit and its own count: a product announcement can never use up the room your login codes need. It still has a limit because transactional is the default category, so a large first send that does not set a category is treated as transactional.

Free plan. Free's own limit of 100 emails a day is lower than where the ramp starts, so the ramp only begins when you move to a paid plan.

Moving an existing sender over? If you already send at volume elsewhere and need more on day one, email support@groundmail.dev with your current volume and we can raise or lift the limit. Upgrading your plan does not change it.

You can see your current stage and today's usage in Settings → Billing, and Home shows a notice when you have used most of a day's limit.

When a send would go over the limit

The send is refused with a 429 and code daily_ramp_limit. Nothing is sent, so it is safe to send the same email again after details.resets_at.

{
  "error": {
    "code": "daily_ramp_limit",
    "message": "New accounts ramp up their sending: today's limit for product email is 4,000 recipients, and this send would go over it. It resets at 00:00 UTC and grows as you send clean mail. Need more sooner? Email support@groundmail.dev.",
    "hint": "New accounts have a daily sending limit that doubles each day they use at least half of it with bounces under 2% and complaints under 0.1%. …",
    "docs_url": "https://docs.groundmail.dev/errors#daily_ramp_limit",
    "details": {
      "stream": "product",
      "daily_limit": 4000,
      "used_today": 3998,
      "recipients": 3,
      "ramp_stage": 3,
      "resets_at": "2026-10-20T00:00:00.000Z"
    }
  }
}

• stream: transactional or product, from the email's category.
• daily_limit: today's recipient limit for that stream. used_today: recipients already sent on it today. recipients: recipients in this send.
• ramp_stage: the current stage (1 is the first day's limit).
• resets_at: the next 00:00 UTC, when you can send the rest.

Batch sends (POST /emails/batch) check the limit for each email in order: emails that fit are sent and the rest come back with this error in their item. A scheduled email that would go over the limit when its time comes is not failed: it moves to just after the next 00:00 UTC (within 15 minutes of it), its scheduled_at shows the new time and its last_event is daily_ramp_deferred. It is moved at most 3 times; if it is still over the limit after that, it is marked failed with last_event daily_ramp_limit. An automation's send step waits for the reset the same way, and the run fails after 3 moves.

SMTP answers a message over the limit with a temporary 451 4.7.1 reply, for example 451 4.7.1 Daily sending limit reached for this account; retry after 2026-10-20T00:00:00.000Z. Your mail server keeps the message in its queue and sends it again later, so nothing is lost; most servers keep retrying for several days.