Blog
Temporary Email for Testing Websites and Apps
A QA-oriented walkthrough of using disposable inboxes as test fixtures, the seven signup states worth covering, and the point at which you should stop and run your own mail server instead.
Testing a signup flow means running it repeatedly with addresses that have never been seen before. Most services reject a second registration on the same address, so "just use my own" fails at the second test case.
Disposable inboxes solve that neatly for manual testing, and badly for automated testing. Knowing where the line falls saves a lot of wasted effort.
The seven states worth covering
Teams test the happy path and stop. The interesting defects live in the other six.
- New address, correct code. The baseline. Account created, verification accepted, user lands wherever they should.
- Verification link clicked twice. Does the second click show a friendly "already verified" page, or a stack trace?
- Expired code. Wait past the stated window, then submit. Is the error clear, and is a resend offered?
- Wrong code, repeatedly. Is there a rate limit? Ten wrong guesses on a six-digit code should not be free.
- Resend pressed several times. Do you get four messages with four different valid codes? Do earlier codes get invalidated?
- Same address registered again. Does it say "account exists", or does it leak that the address is registered to somebody who is not you?
- Disposable domain rejected. If your product blocks throwaway domains, is the rejection message accurate and actionable, or a generic "invalid email"?
Item seven is the one most teams have never looked at, and it is a real conversion problem: a legitimate user with an unusual domain sees "invalid email" and concludes your form is broken.
A worked pass
Concretely, checking a password reset flow end to end:
- Open ShieldMail, copy the address, register on your staging environment.
- Refresh the inbox. Verification arrives in roughly five to ten seconds. Confirm the sender domain and the link target are the staging environment, not production — a surprisingly common misconfiguration.
- Complete verification, then immediately sign out and request a reset.
- In the reset message, check the link expiry is what the copy claims. Copy the link, wait past that window, then open it. The expiry message should be human-readable.
- Request a second reset, and confirm the first link is now dead. If both work, you have found a real defect.
- Press Change in ShieldMail for a fresh address and repeat the whole pass to confirm the behaviour is not stateful.
That sequence takes about four minutes and covers four of the seven states above.
Where disposable inboxes stop being the right tool
They are excellent fixtures until any of these becomes true:
| Signal | Why it breaks | What to use instead |
|---|---|---|
| CI runs the suite on every commit | No stable API, and polling a public service from CI is rude and rate-limited | A mail-testing API, or your own catch-all |
| You need to assert on HTML structure | You get a rendered view, not a parseable object | A service returning raw MIME |
| Tests must run offline or in a sealed network | Requires outbound internet to a third party | A local SMTP sink |
| The mail contains anything real | The mailbox is public | Never. Use a private catch-all |
| You need more than a handful of addresses per minute | Rate limits, and it is abusive | A wildcard domain you own |
The rule: manual and exploratory testing, yes. Automated suites, no. A public free service is not infrastructure, and treating it as such is both fragile and unfair to the people paying for it.
The cheapest durable alternative is a catch-all on a domain you already own. Every address at that domain reaches one mailbox, so signup-test-1@, signup-test-2@ and so on are all instantly available, private, and yours.
Two things to check that nobody checks
Does your verification mail render without images? Many clients block remote images by default. If your call-to-action button is an image, a real fraction of your users see a message with no visible way to continue. Open it in a reader that blocks images — ShieldMail's does — and see what survives.
Does the plain-text part exist and make sense? Multipart messages carry a text alternative that many teams leave as an empty string or an unrendered template. It is the version screen readers and text clients get.
Test data hygiene
Two rules that matter more than they sound:
- Never point a disposable inbox at production. Test accounts in a live system linger, and this one has a public mailbox attached.
- Never send real customer data through one. Anonymised fixtures only. If your staging environment holds a copy of production data, that is a separate and more urgent problem.
The related reading is responsible usage for the boundaries, and how to use temporary email safely for the mechanics.
FAQ
Can I automate against a public temporary email service?
You should not. There is no stable API contract, rate limits exist for good reason, and your suite becomes dependent on somebody else's free service. Use a mail-testing API or a catch-all domain.
How many test addresses can I generate?
Press Change for a fresh one whenever you need it, at a human pace. Programmatic hammering will be rate-limited and is exactly the behaviour that gets disposable domains block-listed everywhere.
Why does my staging mail never arrive?
Most often the environment is configured to swallow outbound mail, or your product rejects disposable domains before sending. Check the mail log first, then press Change and retry with a different provider.
Can I test attachments?
Reception works, but rendering support varies by provider and attachment handling is not the strong suit of any public disposable service. Use a dedicated mail-testing tool for attachment-heavy flows.
Is it acceptable to use these for load testing?
No. Load testing against a third-party free service is an attack on it, whatever the intent. Point load tests at infrastructure you own.