How to Create Test Email Addresses for Signups and Password Resets

A test email address gives your signup, password reset or notification a real place to arrive while you test the application. With MailSlurp, you can create a private inbox, use its address for a test account and read the resulting messages in the dashboard or through the API.

The useful result comes at the end of the journey: the account is verified, the new password works, or the correct customer receives the expected receipt. Checking an email's subject helps identify the message, but it doesn't establish any of those outcomes on its own.

Choose the kind of address your test needs

There are three common choices, and they solve different problems.

• A private inbox per test receives real verification emails and reset links, with separate mailboxes for parallel tests. Create it before the app sends and clean it up after the assertions.
• A plus-tagged address, at a provider that supports it, organizes manual tests through an existing mailbox. Tags can share that mailbox, so a different address string doesn't automatically isolate messages.
• A format-only example, such as person@example.com, checks form validation, allowed characters or error messages. It supplies a string for the form rather than a mailbox you control for receipt.

For an automated signup or reset, start with a private inbox. MailSlurp's disposable email API creates addresses you can control in a test, while the temporary email API explains how to choose an expiry around the workflow.

Keep form-validation fixtures separate from recipients that will receive mail:

Input	Check to make
An empty value	The required-field error appears and the form does not submit
person@	The application rejects the incomplete address before sending
person@example.com	The form handles a well-formed example according to its validation rules; do not wait for mail at this address
The address returned by a new test inbox	The application sends to that exact recipient and the test completes the delivered action

If you already have an address and need to check its syntax or domain, use the email address verification guide. Those checks answer a different question from creating a mailbox for your test.

If you're deciding between a manual account and an automated inbox setup, the test email account guide covers that broader choice. Here, we'll follow the address through an actual test.

Try the flow manually first

A quick dashboard check is useful while you're learning the application's behaviour:

1. Create a MailSlurp inbox and copy its email address.
2. Use that address in a test account on your development or staging application.
3. Trigger the action you want to check, such as requesting a password reset.
4. Open the received message in MailSlurp. Confirm the recipient, sender and request you just made.
5. Check that the verification or reset link points to your test environment before opening it.
6. Complete the action and inspect the application's result. For a reset, sign in with the new password; for signup, confirm the account is verified.

This also reveals details an automated test needs: the relevant message subject, the link to follow, and the screen or account state that means success. An email may contain tracking, preference and support links as well as the one your test should open.

Run a complete password reset example

The downloadable password reset example includes a local teaching application and two Playwright tests. Each test creates its own MailSlurp recipient inbox, sending inbox, application account and local server. The application sends reset emails between those new inboxes.

With Node.js 22 or newer, unzip the download, open its directory and run:

cd playwright-parallel-reset
npm ci
npx playwright install chromium
export MAILSLURP_API_KEY='your-test-account-api-key'
npm run typecheck
npm test

Use your own MailSlurp test-account key in the environment variable. The example uses your account's inbox and send allowance; it creates four expiring inboxes and sends four emails across the two tests. It doesn't use existing customer inboxes or accounts.

The test follows two reset requests for each account. It first receives an earlier email, then demonstrates that this old message cannot satisfy the wait for the current request. Once the new message arrives, it:

• confirms the recipient, sender and exact request identifier;
• extracts the reset link and checks its allowed origin and path;
• verifies that the previous link is invalid under the example application's resend policy;
• changes the password, rejects the old password and signs in with the new one;
• checks the signed-in account and rejects replay of the consumed reset link.

That final account assertion is the reason to receive the email in the first place. The example tests real email receipt and a local application's reset behaviour. To cover your own service, replace the teaching application's forms and sending callback with your staging application and normal email provider.

The Playwright walkthrough explains how to set up and run the test. Provider inbox placement needs a separate check; receiving the reset email here doesn't tell you where other providers will file it.

Check reset expiry separately

The downloadable example verifies resend invalidation and replay rejection. Add a separate scenario for your application's token lifetime; a consumed token and an expired token are different failure cases.

Request a fresh reset email, retain its intended link without opening it, and advance the application's controlled test clock beyond the token's configured expiry where supported. Submit the new password through that link and verify rejection, then confirm that the existing password still works. Use a fresh browser session so an earlier login cannot satisfy the account assertion.

If the application has no controlled clock, use a documented short lifetime in its isolated test environment and wait beyond that actual boundary. Keep this policy test separate from the successful delivery test. Also test existing-session invalidation separately if your product promises it; the sample's new-password login alone does not establish that all old sessions were revoked.

Make sure you read this test's email

A new address is a useful first boundary, but a resend can still leave multiple messages in the same inbox. Match the current request as well as the recipient.

In the example, the application includes a request identifier in the subject. The test captures a start time before submission and waits for that exact subject in its own inbox. Your application might use another stable identifier; choose something it actually sends rather than inventing a field that only exists in the test.

Keep waits bounded. A timeout should tell you which expected message was missing. It shouldn't silently fall back to an older email or treat an authentication or quota error as an ordinary delivery timeout.

The inbox ID and email address also have different jobs. Give the address to your application; use the inbox ID to retrieve messages through MailSlurp. Keep both attached to the same test so one worker cannot accidentally query another worker's inbox.

If your tests use Cypress, follow the Cypress email-testing guide for inbox creation and browser assertions.

When do plus addresses help?

A plus address adds a tag to an existing address, such as qa+signup@example.com. At a provider that supports this routing, it can help you organize messages for a manual signup, reset or notification check.

The tag doesn't necessarily create another mailbox. If qa+signup and qa+reset route to the same inbox, your test still needs to distinguish their messages. Check your receiving provider's alias behaviour and whether your application preserves the tag, rejects it or treats the addresses as the same account.

For parallel automated tests, separate private inboxes make this isolation easier to reason about. For ongoing routing into a shared destination, see email aliases and the plus-addressing routing guide.

Plan expiry and cleanup around the whole test

Set an inbox lifetime long enough for setup, message delivery, browser actions and debugging. An inbox that expires while the app is sending can make a good application look broken.

The downloadable example sets a ten-minute inbox expiry and also deletes the inboxes during teardown. Explicit deletion and expiry are separate controls: deletion performs cleanup after the test; expiry closes the inbox to further sending and receiving if the process is interrupted. Expiry is not proof that retained messages were deleted. Cleanup failures are reported rather than hidden.

Retain only the evidence you need to understand a failed test. Reset URLs and verification codes can grant access, so avoid publishing raw email bodies or browser traces containing them. Keep the test's application account separate from any real customer identity.

Deleting the inbox doesn't delete the user from your own application. Clean up that test account through the application's supported test-data process, or deliberately retain it when testing returning-user behaviour.

Diagnose a test that didn't finish

No email arrived

Check that the application used the address from this run and actually triggered its send. Inspect the sending provider's outcome, then compare the inbox ID, time filter and expected subject. A message can be present but excluded by an incorrect test filter.

The link opens the wrong environment

Inspect the exact link before navigation. The example allows only its local application's origin and /reset path. Use your staging origin and the intended verification/reset path when adapting it, including any deliberate redirect behaviour.

The email is correct, but verification fails

Check the application's expiry, resend and one-time-use policy. A new request may invalidate the previous link. The test should submit the current message and assert the resulting account state rather than retrying old tokens until one succeeds.

Tests fail only when run together

Look for shared inbox IDs, shared application users or teardown that deletes another test's resources. Run two distinct accounts concurrently and assert the final identity for each. Passing twice in sequence doesn't demonstrate parallel isolation.

Common questions

Is testing an email address the same as validating it?

Format validation checks whether an address string is acceptable. Ownership verification asks the recipient to use a delivered link or code. An end-to-end test exercises your application's send, receipt and resulting action. Choose the check that matches the behaviour you're trying to prove.

Can I keep the same inbox for repeated tests?

Yes. A reusable inbox is useful for a persistent test identity. Match fresh messages to the current request and serialize access or otherwise isolate concurrent tests. For independent signup tests, a new private inbox per test is usually simpler.

Does receiving a test email prove it reaches Gmail's inbox?

Receipt confirms delivery to the controlled test inbox. Use inbox placement testing for sampled provider-folder outcomes, and device previews when you also need to check how the delivered message looks.