How to Test Sign-Up Emails Without Spamming Your Own Inbox
Test registration, welcome and verification emails with disposable public inboxes instead of your real address. A practical workflow for developers and QA.
Every developer knows the problem. You build a sign-up flow, and to test it you need a fresh email address each time. Using your own address clutters your inbox. Using + tricks works until your app (rightly) normalises them. Asking colleagues for addresses does not scale. And inventing fake addresses means you never see the email at all.
A temporary inbox solves this. You pick any address name, your application sends to it, and you read the message in a browser a few seconds later.
What you need from a test inbox
For sign-up testing, an inbox must:
- Accept mail for any name without creating an account or mailbox first.
- Show new messages quickly, because you are waiting for a link.
- Let you read the full message, including the link, the headers and the plain-text part.
- Be disposable, so nothing accumulates.
Public temporary inboxes were made for this. The trade-off is privacy: because no login is needed, anyone who knows the address can read it. That is fine for test data and unacceptable for anything real. We cover that in what a temporary email address is.
A repeatable workflow
- Choose a naming scheme. For example
signup-test-1042@followed by the inbox domain, using a number from your test run. Unique names stop one run reading another run's mail. - Open the inbox page for that name in a browser tab, before you submit the form.
- Submit your sign-up form with that address.
- Watch the message arrive. Good inboxes update live, with no refresh needed.
- Open the message and check the sender, subject, body and the verification link.
- Click the link and confirm the account is activated.
- Repeat for the edge cases listed below.
What to check in each email
| Check | Why |
|---|---|
| From name and address | Recognisable, on your domain, not noreply@localhost |
| Subject | Clear, no leftover template placeholders like {{name}} |
| Plain-text part | Present, readable, and contains the link |
| HTML rendering | Buttons and images work; remote images do not hide the content |
| Link target | Points to the right environment (staging, not production, not localhost) |
| Link expiry | Works once, expires as designed |
| Arrival time | Seconds, not minutes |
| Headers | Authentication-Results shows pass for SPF, DKIM and DMARC |
The last row is easy to forget. Sending to a public inbox is a convenient way to inspect real delivery headers without exposing your own mailbox. See how to check SPF, DKIM and DMARC.
Edge cases worth testing
- Same address signed up twice. What does the second attempt do, and does the message avoid revealing whether the account exists?
- Resend verification. Is there a rate limit? Does the old link stop working?
- Expired link. Wait for the expiry and try it.
- Wrong or already-used token.
- Upper and lower case in the address.
- Very long names and special characters that the local part allows.
- Unsubscribed or blocked behaviour for marketing mail.
Automating it
For end-to-end tests in Playwright, Cypress or a similar tool, generate a unique inbox name per test, fill the form, then fetch the inbox page and extract the link. Because the inbox is public, no credentials are needed, which simplifies CI. Keep these rules:
- Never use a public inbox for real customer data or production accounts.
- Generate names that are hard to guess if the test content is even slightly sensitive. Anyone can read a guessable name.
- Do not poll in a tight loop. Wait with a sensible timeout and a few retries.
Pitfalls
- The sender is rate-limited or deferred. If your first message takes a long time, check your staging mail relay, not the inbox.
- Mail goes out but never arrives. Check that the sending domain is authenticated and that the staging environment uses a real sending configuration, not a dummy transport.
- Shared names collide. Two developers using
test@will read each other's mail. Always use unique names. - Expecting attachments. Most public test inboxes do not offer attachment downloads, for safety.
Try it with Mailions
Mailions has public temporary inboxes at /temp, with no login required. Choose an address name, or generate a random one, and new messages appear live without refreshing. Remote images are never loaded in the public view. Free inboxes delete each message 30 minutes after it arrives, they are receive-only, and anyone who knows the address can read them, so use them for test data only. If you need test mail kept permanently, contact us about paid retention.
Frequently asked questions
How can I test sign-up emails without using my own inbox?
Use a temporary inbox or a unique test address for each run, sign up with it and read the confirmation there. Plus-addressing in your own mailbox also works, but it fills your inbox and some sites reject the plus sign.
What should I check in a sign-up confirmation email?
The sender name and address, the subject, that the link or code works and expires as intended, the plain-text version, the mobile layout, and that SPF, DKIM and DMARC pass in the message headers.
Can sign-up email tests be automated?
Yes. Create a unique address per test, sign up through the browser or API, wait for the message in that inbox, then extract and follow the link. Remove the test accounts afterwards.