SendGrid: sandbox mode
Set mail_settings.sandbox_mode.enable to true in the mail send request. SendGrid validates the request and answers 200 OK instead of the usual 202 Accepted; the email is never delivered, uses no credits and produces no events. Useful to check that your payload is valid, useless for checking that an email arrives.
Postmark: the test token and sandbox servers
Sending with the server token POSTMARK_API_TEST validates the request and delivers nothing.
A sandbox server goes further: messages are processed by Postmark but not delivered to real inboxes, and they do count towards your monthly sending volume.
Resend: test addresses
Resend has no sandbox switch. It gives you addresses that simulate outcomes: delivered@resend.dev, bounced@resend.dev, complained@resend.dev and suppressed@resend.dev, the first three with +label support. It also asks you not to send to made-up addresses, which can hurt your domain's reputation. You can confirm the API call and the event flow this way, but you never see the email itself.
Amazon SES: the account sandbox
Every new SES account starts in a sandbox, per region. While there, it can send only to verified addresses and domains or to the SES mailbox simulator, at most 200 messages per 24 hours and 1 per second. Staging on a sandboxed account silently can't reach a new test address until that address is verified.
Verifying an address means SES emails it a link. With a permanent test inbox you can open that email in a browser and click it, which makes a fixed set of test addresses usable from a sandboxed account.
What to do on staging
- Unit tests and local runs: keep the sandbox or test token. Nothing leaves, nothing costs.
- Staging E2E: send for real, through the same provider configuration as production, to test addresses you control. Only then does the test cover templates rendered by the provider, link tracking and authentication.
- Production: never point tests at real users. If a staging database has copied production data, scrub the email addresses first.