Disposable email for testing signup flows

Most people who land on TempsMail want to dodge a newsletter. Developers are the one group that shows up with a plan: they're testing a signup flow and they need twenty throwaway addresses before lunch.

We like these users. They're also the ones who hit the edges of the service fastest, so this is the page we wish they'd read first — what a disposable inbox is genuinely good for in a test suite, and the three places it will quietly waste your afternoon.

What you're actually testing

"Does registration work" is not one test. When a signup flow breaks in production, it's almost always one of these, and every one of them needs a real inbox to catch.

• The verification email never arrives. Queue worker died, template throws on a missing variable, provider silently drops the recipient.
• It arrives, but the link is wrong. The classic: a token built against localhost or a staging host, shipped to production. The email looks perfect. The link 404s.
• The token expires too fast, or never. Both are bugs. Only one gets noticed.
• A second signup with the same address does something strange. Duplicate account, or a password reset for a stranger.
• The unsubscribe link doesn't work. In a lot of places that's not a bug, it's a legal problem.

None of that shows up in a unit test with a mocked mailer. You need something that actually receives.

Four tests worth wiring up

1. Happy path, end to end. Create an address, submit the form, poll the inbox until the message lands, pull the confirmation URL out of the body, follow it, assert the account is active. This single test catches more real breakage than any other check in a signup suite.
2. Token expiry. Register, wait past the limit, then click. You want a friendly "this link expired, here's a new one" — not a 500.
3. Re-registration. Same address twice. Decide what should happen, then assert it. Most teams discover they never decided.
4. Every template that goes to a user. Welcome, reset, changed-email, receipt. Render each one into a real inbox once per release and look at it. Broken images and untranslated strings are invisible to assertions and obvious to eyes.

For the polling step, it helps to know the pattern we described for pulling one-time codes out of a temporary inbox — it's the same shape, just automated.

Where this is the wrong tool

Three cases. We'd rather tell you now than have you debug our service instead of yours.

Deliverability testing. If the question is "will this land in the inbox or in spam at Gmail", we can't answer it. We're a catch-all. We don't score SPF, DKIM or DMARC alignment the way a consumer provider does, and we don't produce a spam report. Use a tool built for that, or send to real mailboxes you control at the providers your users actually use.

Load testing. Please don't. Signup flow benchmarks that fire thousands of registrations will hit our rate limits, and rightly so — the limits are what stops the service being used to mass-create accounts somewhere else. For load tests, mock the mailer. You're measuring your app, not our inbox.

Long-lived fixtures. A seeded test account that your suite expects to still exist next sprint should not live here. Messages rotate out and addresses aren't permanent. Fixtures need a mailbox you own, ideally with sub-addressing so one real account gives you [email protected], [email protected] and so on, forever.

Doing it properly through the API

Scraping our web page in a test is fragile and we'll eventually change the markup under you. There's a documented API instead: create an address, get back a key bound to that address, then read messages with it. Details are on the API page, and you generate your own key from API access after signing in.

Two design choices worth knowing before you build against it.

It is receive-only. You cannot send from a TempsMail address, and that's deliberate — an open service that could send would be a spam relay within hours. If your test needs to verify an outbound reply, that's a different tool.

Reads are bound to whoever created the address, by IP and fingerprint, with a token. It stops a stranger reading an inbox just by guessing the address. In practice this means your test runner should create and read from the same place — a flaky suite that creates on CI and reads from a developer laptop will get a 401, and the 401 is correct.

Keeping your suite from breaking on us

Three habits that make the difference between a test that runs for a year and one that goes red next Tuesday.

Poll with backoff, and set a real timeout. Mail takes a second or two. A tight loop with no ceiling turns one slow delivery into a hung pipeline.

Treat a missing message as a failure of your app first. Nine times out of ten an empty inbox means your queue isn't running in CI, not that we lost the mail.

Generate a fresh address per test, never share one. Shared addresses across parallel runs is how you get a test reading another test's confirmation link and passing for the wrong reason.

Frequently asked questions

Can I use this in CI without a key?

No. The API needs a key from a verified account, which is a deliberate change from how it used to work. Anonymous automated access is exactly the pattern that gets abused, so the key is what lets us keep the service open for everyone else.

How many addresses can I create?

Enough for a normal test suite, not enough for a load test — address creation is rate limited separately and more tightly than reading. If a legitimate pipeline is hitting the ceiling, tell us what you're doing rather than working around it.

Can I pick the address instead of getting a random one?

You can choose the local part on the site. For automated tests, taking whatever the API hands you is more robust anyway — a hardcoded address is a collision waiting to happen when two branches build at once.

How long do messages stay readable?

Not long, and by design. Assert on the message in the same test that triggered it. Anything you want to keep, extract and store on your side before the test ends.

That's the whole shape of it: disposable inboxes are great for proving an email actually arrived and actually worked, and wrong for anything that needs to still be there tomorrow. If you're new to the service, how to get a temp mail covers the basics first.