Accounts
Limits & account review
A brand-new account's daily sending limit starts low and rises over its first week. Separately, we can place an account under review, which confines it to your own addresses until we lift it. Both are listed here in full, and both can be lifted by asking.
Why use this
For example
You sign up on a Tuesday, verify acme.com, and send your first password reset that afternoon. A launch-day import of 5,000 users would hit the day-one ceiling, so you ask us to lift it, or schedule it for the second week.
Account review
Most new accounts are approved when they sign up; some are reviewed first, and we can place any account under review. While it is, live sends are limited to three kinds of recipient:
- Any address at a domain you have verified yourself.
- Your own account email address.
- The AWS SES simulator mailboxes, which are the supported way to force a delivery, bounce or complaint.
Anything else returns 403 account_pending_review. It is a policy decision, not rate limiting — retrying will never clear it, and your integration code does not need a retry branch for it.
You can keep building the integration while it applies. Verify your domain and send to an address on it: that is the identical code path a stranger's address takes once review is lifted — same endpoint, same headers, same webhooks, same delivery events. Nothing about your code changes when it lifts.
Test mode (from: no-reply@yourmail.dev) is unaffected. A test-mode send is already confined to your own inbox, so there is nothing for the review to restrict.
The first-week ramp
Every new account's daily ceiling starts below its plan's and reaches it over seven days:
| Since first send | Free | Pro |
|---|---|---|
| First day of sending | 20 | 100 |
| Days 2–3 | 50 | 500 |
| Days 4–7 | 100 | 2,000 |
| After 7 days | 100 | 5,000 |
Three things worth knowing about how it is counted. It is in recipients per UTC day, not messages — one email to 50 addresses spends 50. The clock starts at your first live send, not at signup, so waiting before you begin does not shorten it, and test-mode sends do not start it. And upgrading your plan does not lift the current stage — paying raises the figures in the Pro column, which are the same staircase.
Going over is a 429 whose message names the ramp and says when it lifts. Like the review 403, it is a ceiling for the rest of the day rather than backpressure, so do not retry-loop against it.
In practice, real transactional traffic — one message per user action — does not reach these figures on day one. A list import or a backfill does, and that is the case to plan for.
Getting either lifted
Email conor@mathersoftware.com from your account address. Approval and the ramp are two separate switches on our side and both are a single click, so say which one is blocking you — and if you are launching to a known volume on a known date, say that too, and we will clear it before you need it.
Plan limits after the first week
Once the ramp has lifted, your account is bounded by its plan's own monthly and daily allowances — see pricing for the figures, and GET /v1/usage to read your consumption at runtime. Its day.limit is the ceiling actually enforced today — the ramp's figure while it is in force, not your plan's — and day.count is metered in the same unit, so the two can be compared directly.
Passing your monthly allowance does not stop your mail dead. Sends continue into a bounded grace band above the limit — this is transactional email, and a hard stop on a password reset is an outage — and your application is told via the quota.exceeded webhook.
Last updated