What a test email address is for
A test email address is a working, throwaway inbox you can paste into any form that asks for one. It receives real mail over real infrastructure, so you can confirm that a message arrived, read what it says, and check that the links inside it work. Then you discard it.
The point is not anonymity. The point is that verifying email behaviour with a personal inbox is slow, noisy, and quietly misleading, for reasons that are worth spelling out.
Why a personal inbox is a poor test target
- Threading hides duplicates. Gmail and Outlook group similar messages into one conversation. If you are testing that a password reset can be requested three times and produces three distinct tokens, threading actively obscures the thing you are checking.
- Image proxying changes what you see. Gmail serves images through its own cache. A tracking pixel or a broken image URL can look fine to you and be broken for everyone else.
- Clipping truncates long templates. Messages past roughly 102KB get clipped behind a "View entire message" link, which is a common surprise when testing a long receipt or a digest.
- Aggressive filtering. A staging server sending bursts of near-identical mail looks exactly like a spam source. Your test messages start landing in spam, or stop arriving at all, and you waste an afternoon before noticing.
- The inbox becomes unusable. A few weeks of testing leaves a personal inbox full of noise from every staging environment you have touched.
What you can check with a disposable inbox
Signup and verification is the obvious case, but transactional mail is where most template bugs actually hide, because it is written once and rarely reviewed again.
- Registration and verification. Confirm the message arrives, the code matches, and the link resolves to the right account rather than a generic landing page.
- Password reset. Check that a fresh request invalidates the previous token, that expiry works, and that the link is not reusable after a successful reset.
- Order and payment receipts. Verify totals, tax lines, and currency formatting render correctly, and that the order reference resolves.
- Invoices and billing alerts. Check that dates are formatted for the right locale and that amounts are not silently rounded.
- Shipping and status updates. Confirm the tracking link points somewhere real.
- Newsletters. Check the unsubscribe link genuinely works, which is both a legal requirement and one of the most frequently broken links in transactional mail.
A workflow that catches real bugs
Generating an address and glancing at the result catches the obvious failures. A slightly more deliberate pass catches the ones that reach customers.
- Read the plain-text part, not just the HTML. Many mail clients and most accessibility tooling render the text alternative. It is frequently empty or stale because nobody looks at it.
- Click every link, including the footer. Unsubscribe and preference-centre links are the most commonly broken, because they are the least often tested.
- Check the subject and preheader. A template that leaves an unrendered variable in the subject line is embarrassing and very easy to miss.
- Trigger the same action twice. Duplicate sends, stale tokens, and race conditions only appear on the second attempt.
- Test the failure path. Register with an address that is already in use and confirm the message is correct and does not leak whether the account exists.
Test address, plus-addressing, or a real mailbox?
Each of these has a place, and picking the wrong one wastes time.
| Approach | Best for | Main drawback |
|---|---|---|
| Disposable test address | Staging checks, automated suites, throwaway signups | Some sites reject disposable domains; no long-term retention |
| Plus-addressing on your own mail | Tracking which service leaked your address | Still fills your real inbox; increasingly rejected by forms |
| A mailbox on a domain you control | Anything long-lived, or sites that block disposables | Costs money and needs configuring |
If a service refuses disposable addresses, the last row is the answer. That refusal is a deliberate choice on their part, and working around it is not something we encourage.
Automating it
Everything above works by hand with the generator at the top of this page. Once the flow is stable, the same inboxes are available over HTTP so your test suite can provision one per run. The email testing guide has working Playwright and Cypress examples.
One thing to keep in mind
A test address is for testing. Do not use it as the recovery address for an account you care about, and do not route anything sensitive through it. Messages live on infrastructure we do not control, inboxes are disposable by design, and there is no way to recover one once it is gone.