Temp Mail for Developers: Testing Signup and Email Flows

A disposable inbox is fine for a quick manual check: you've changed a sign-up email, you want to see it land in a real inbox on a real domain, and you don't want it in your own mail. For automated tests it's the wrong tool. You don't control the inbox, the domains get blocked, and public services have rate limits. This guide covers when each option makes sense, what to actually test in an email flow, and the extra checks for shops.

When a temp inbox is fine

There are a few cases where opening a throwaway inbox in a browser tab is the quickest way to check something:

• A one-off manual check on staging or production. You've shipped a new welcome email and want to see it arrive from your real sending setup, on a domain you don't own.
• Seeing your flow as a stranger would. A fresh address with no history shows the first-time experience: the first email, the first code, the first link.
• Checking that a code or link arrives at all. If a user says "I never got the code", a quick sign-up from a random address tells you whether the basic path works.

For these, a private random inbox like the one on this site is enough. Stick to private inboxes. Public "any name" inboxes, where anyone typing the same name can read the mail, are a bad idea for anything with a code or a login link, even in testing.

Why it's wrong for automated tests

Once a test runs on every commit or every night, a public temp mail service becomes a liability.

• You don't control it. The service can change its domains, go down, or change its API without notice. Your build then fails for reasons that have nothing to do with your code.
• Domains get blocked. Popular disposable domains end up on shared blocklists. If your own app, or a third-party auth or anti-fraud service you use, checks those lists, your test sign-ups get rejected.
• Rate limits. Shared services limit how many inboxes and requests you can make. A parallel test suite hits that fast.
• Mail retention is someone else's call. Messages can be deleted before your test reads them, or kept longer than you'd like.
• Public inboxes leak test data. If you use an "any name" inbox, anyone can read your test emails, including reset links and tokens for your staging environment.
• It's not fair use. Free services run on goodwill. Hammering them from CI isn't what they're for.

This site in particular is built for people reading a few emails by hand, and it isn't meant to be used from test scripts.

Better options

There are tools built for exactly this job. Pick based on where your tests run and whether you need real delivery.

Local SMTP catchers

Mailpit and MailHog run an SMTP server your app sends to, plus a web UI where you can read everything it caught. Nothing leaves your machine, so you can send as much as you like. Mailpit is the more actively maintained of the two at the time of writing. Running it with Docker:

docker run -d -p 8025:8025 -p 1025:1025 axllent/mailpit

Point your app's SMTP settings at localhost port 1025, then open http://localhost:8025 to read the mail. Mailpit also has an HTTP API, so tests can fetch the latest message and pull out a code or link. Check its docs for the endpoints.

Hosted test inboxes

Mailtrap and Mailosaur give you inboxes and APIs designed for QA, with features like spam scoring and HTML checks depending on the plan. Mailinator's paid plans give you private domains, which avoids the public inbox problem. Plans and features change, so check their sites.

Your own catch-all domain

Register a cheap domain just for testing and set it to catch all mail. Then every address you make up, like signup-test-4821@yourtestdomain.com, lands in one mailbox you control. Nobody blocks it as disposable, and you're testing real delivery.

Plus addressing on a domain you own works too, if your mail provider supports it: qa+run123@yourcompany.com arrives at qa@yourcompany.com, and the tag tells you which test sent it.

What to test in an email flow

Getting an email to arrive is the start. A full check covers:

1. Deliverability. Does it reach the inbox and not spam at the big providers? Are SPF, DKIM and DMARC set up for the sending domain?
2. Links. Every link works, points at the right environment (no staging links in production mail), and uses HTTPS.
3. Code and link expiry. Expired codes are rejected with a clear message. Used links can't be reused.
4. Resend limits. Pressing "resend" five times doesn't send five emails instantly, and the newest code works while older ones are handled the way you intend.
5. Templates in dark mode. Logos with transparent backgrounds and dark text can vanish in dark-mode mail apps. Check on at least one phone client.
6. Plain-text part. Multipart emails should include a readable plain-text version, not an empty one or raw template tags.
7. Unsubscribe. Marketing emails need a working unsubscribe link, and many senders also add a List-Unsubscribe header. Transactional emails like password resets shouldn't be blocked by someone unsubscribing from marketing.
8. Edge cases. Long names, non-English characters in names and subjects, and addresses with a plus sign in them. Some forms still reject +, which annoys anyone using plus addressing.

E-commerce flows

Shops send more transactional email than most apps, and people rely on it. Test each of these with test payments in your provider's test mode, sent to inboxes you control:

• Order confirmation. Correct items, prices, tax, delivery address and order number. Sent once, not twice if the payment webhook retries.
• Receipts and invoices. Totals match the payment, and any PDF attachment opens.
• Shipping and delivery updates. Tracking links work and point to the right carrier.
• Password reset. The link expires, works once, and doesn't reveal whether an email address has an account.
• Refunds and cancellations. The customer gets told, and the amount is right.
• Abandoned basket emails. They stop once the order is placed.

Real customers need all of these later, which is also why shoppers shouldn't use a throwaway inbox for actual orders. There's more on that in the guide to temp mail for shopping.

A note on the mail.tm API

The addresses on this site come from mail.tm, a public temporary mail provider. mail.tm has a documented public REST API: broadly, you can create an account on one of its available domains, get a token, and list messages. If you're curious, read its own documentation and terms, and respect its rate limits.

It's still a shared public service, with all the problems listed above. For a test suite your team depends on, a tool you run or pay for is the safer choice. Our temp mail API page lists its endpoints, mail.tm's usage rules and the free tiers of the testing tools above.

Quick summary for your team

• Manual spot check of a real email: a private temp inbox is fine.
• Local development and CI: Mailpit or MailHog.
• Shared QA with real delivery: a hosted test inbox or your own catch-all domain.
• Never: public "any name" inboxes for anything with a login link.

If you're testing how your sign-up form handles disposable addresses, it helps to know why temp mail gets blocked and how those checks work. And for the user's side of things, email aliases vs temp mail explains why many of your real users will sign up with a forwarding alias rather than their main address.