If you've ever tested a registration form with me+test1@gmail.com, me+test2@gmail.com, and so on, you know the pain: a cluttered inbox, aliases everywhere, and no clean way to automate it. Temporary email for developers solves this — every test run gets a fresh, real, disposable inbox you can read from the browser or over an API.
What temp mail is great for testing
- Signup & verification — confirm that activation emails and OTP codes actually send and arrive.
- Password reset — verify reset links generate and work end to end.
- Transactional mail — receipts, notifications, and welcome sequences.
- Edge cases — throwaway addresses across many domains without creating accounts.
Reading inboxes over the API
fmail exposes a public, CORS-enabled REST API with no auth keys — ideal for QA scripts and CI. Point a signup at a generated address, then poll the inbox for the code:
# get a random address
curl https://fmail.men/v1/random
# → {"username":"ember4821","domain":"fmail.men","address":"ember4821@fmail.men"}
# poll the inbox for arriving mail
curl "https://fmail.men/v1/inbox/ember4821?domain=fmail.men"Full endpoint reference lives in the developer docs.
Why devs like disposable inboxes
- No real mailbox to pollute or clean up.
- A fresh empty inbox per test run, on demand.
- Scriptable: automate signup → poll → assert the code arrived.
- No API keys or account setup to block your CI pipeline.
Practical tips
- Generate a unique username per test so runs never collide.
- Poll with a short backoff; most mail arrives within a second or two.
- Remember inboxes are semi-public — never send real secrets through them in tests.
- Mail is retained for 12 hours, so debugging a failed run later is still possible.
Need a throwaway inbox right now?
Pick any name on 26 domains, read mail live, and let it self-destruct. No signup, ever.
Create your address →