Accounts
Limits & account review
Two things apply to a brand-new account: it is reviewed before it can email people outside your own domains, and its daily sending limit starts low and rises over its first week. Both are temporary, 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 build your whole password-reset flow against your own inbox that afternoon. On Wednesday morning your account is approved and the same code sends to real users, unchanged.
Account review
Until an account is approved, 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. Review usually takes a few hours. 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 build the entire integration while you wait. Verify your domain and send to an address on it: that is the identical code path a stranger's address takes once you are approved — same endpoint, same headers, same webhooks, same delivery events. Nothing about your code changes on approval.
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
Separately from review, a 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 support@yourmail.dev 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. Note that endpoint reports your plan's daily cap; while the ramp is in force the enforced ceiling is lower than the figure it returns, so treat the 429 rather than day.limit as authoritative on a new account.
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.