Using temporary email addresses to test a signup flow
Anyone who has built a registration flow has hit the same wall: you need a fresh, working email address, and you need another one ten minutes later. Using your own address stops working almost immediately, because most systems enforce uniqueness and you cannot re-register.
The plus-addressing trick, and why it runs out
The standard first move is plus addressing. Mail to
you+test1@gmail.com arrives at you@gmail.com, which
gives you unlimited unique addresses at no cost. It is genuinely useful and
worth knowing.
It fails in three common situations. Some signup forms reject + as
invalid. Some applications normalise it away specifically to prevent this.
And it only tests your provider — you learn nothing about how the mail
renders elsewhere, and every test message lands in the inbox you actually use.
A disposable address avoids all three. As it happens, this service also folds
+tag into the base inbox, so
abc123+signup@fake-email.org and
abc123+reset@fake-email.org both arrive in the
abc123 inbox. You get tagged addresses without needing a separate
inbox for each.
What disposable addresses are good for in testing
- Manual QA of registration. A new address per run, with no database cleanup between runs.
- Verifying that mail actually sends. The fastest way to confirm a newly configured provider is delivering at all.
- Checking rendering. Real HTML mail, viewed outside your own client, is a useful sanity check on a template.
- Testing password reset and verification links end to end.
- Demos. Walking a client through a signup without using anyone's real address.
What they are not good for
Automated test suites. Do not point CI at a public disposable service. There is no API contract, no delivery guarantee, and no rate limit you are entitled to. Use a purpose-built mail sandbox — a local SMTP catcher in development, or a hosted testing service with a proper API — which gives you deterministic assertions and no external dependency.
Anything with a secret in it. The inbox is readable by anyone with the address. Never send a staging admin invitation or a production credential to one.
Testing deliverability or spam scoring. The result tells you nothing about how a major provider would treat the same message, because the filtering is completely different.
Long-lived test accounts. The inbox expires; a fixture account that needs a working reset path will break.
A workable approach
- Local development: a mail catcher that intercepts everything SMTP and shows it in a local UI. Nothing leaves the machine and there is no risk of mailing a real person.
- Automated tests: a testing-mail API with per-run inboxes, so assertions are deterministic.
- Manual and exploratory QA on staging: disposable addresses. Fast, disposable, and genuinely external.
- Pre-release rendering checks: a dedicated preview service that renders your template across many real clients.
Things worth testing that teams routinely skip
- The plain-text part. Many templates ship with an empty or broken text alternative. Open a message here and check the text view.
- Rendering with images blocked. This is the default in a great many clients, including this one. If your call to action is inside an image, a large share of recipients see nothing.
- Link expiry. Verification links should stop working after a sensible window. Test the expired path deliberately.
- Repeated requests. Ask for five password resets in a row and confirm rate limiting behaves.
- Long and unusual addresses. Dots, dashes, and long local parts break naive validation regularly.
- Subject line truncation on a narrow screen.
If your own service wants to block disposable addresses
A fair decision in some contexts, but be deliberate. Blocklists are always out of date, they reject legitimate users with privacy-conscious habits, and they are trivially bypassed by anyone determined. If the real goal is preventing trial abuse, a payment method or a phone check does far more. If the goal is deliverability, validating that the domain has an MX record does most of the work with far fewer false positives.
Grab an address from the inbox page and you can have a signup flow under test within a few seconds.