Test Email Addresses and Accounts for QA

A test email address can mean two different things: a value to type into a form, or a working inbox that receives the email the form triggers. Choose the second when you need to test signup, a password reset or a notification. A plausible-looking address alone cannot complete those checks.

For one manual check, a mailbox you control may be enough. For repeated tests, especially parallel runs, each test needs an address and a way to find its own message without waiting for someone to open a mailbox.

MailSlurp lets you create private test inboxes in the dashboard or through an API. Use their addresses in your application, receive real messages, and finish the journey with the delivered link or code.

Your MailSlurp account owns the inboxes and API key. Each generated inbox is a recipient, while the test user you register in your application has its own credentials and account state. Creating another inbox does not require another MailSlurp login or automatically register another user in your application.

Choose an address for the check you need

For form validation or documentation, use a reserved example such as person@example.com. RFC 2606 reserves example domains for this purpose. The value illustrates an address; it does not give you a receiving inbox.

For a real signup or password-reset test, generate an inbox and use the address returned by MailSlurp. Do not invent an address at a domain you do not control or use a stranger's Gmail address: the test email could reach someone else.

Checking whether an existing address is valid is another job. Use email address verification for syntax and domain checks. To prove a user can receive and act on a verification message, send through your application's normal workflow and complete the received action.

When you need a test Gmail account

Use a Gmail account your team controls when the check specifically concerns Gmail: for example, whether Gmail displays your message correctly. Keep that provider-specific check alongside your broader application tests.

Google documents plus-address variations for organizing mail in one inbox. A plus tag can help label a manual test, but it does not create a separate mailbox. If two tests share that account, they still need message matching and coordination. Also check how your own application treats address variations when identifying users.

For signup and reset automation, create separate MailSlurp inboxes instead of making every worker share the same Gmail mailbox. That gives each test a recipient it can read through an API. Keep Gmail-specific display or placement checks as explicit provider tests rather than treating every received email as evidence about Gmail.

Create a working test email address

In the MailSlurp dashboard, create an inbox and copy its address. Use that address in your application's real signup or reset form, then return to the inbox to inspect the message. Check the recipient and intended action before following the link or entering the code.

For an automated signup, keep the setup in this order: create the inbox, register its returned address in your application, then wait for that application's verification message. For a returning-user test, prepare the existing application user and its persistent inbox instead. This avoids trying to reset an account that the test has never created.

The same inbox creation step is available in code:

// create a randomly assigned email address
const mailslurp = new MailSlurp({ apiKey });
const { id, emailAddress } = await mailslurp.createInbox();

The generated emailAddress is the value to submit to your application. The inbox id is how your test retrieves mail. Store both with the test's state so another worker cannot accidentally wait on the wrong inbox.

The temporary email API quickstart provides a complete send-and-receive script. For a browser test, the test email address walkthrough includes a runnable password-reset application and parallel tests. Use that example when you are ready to check the whole flow rather than just inspect a message.

Turn receipt into a useful assertion

For signup, open the verification link and check that the expected account becomes active. For a password reset, set a new password and sign in with it. For an OTP, extract the current code, submit it and check the account shown after login.

A notification has a different outcome. Check the intended recipient and the data the user needs: an invoice number, export link or attachment. Do not require a verification link in a message that is only meant to inform the user.

Use a bounded message wait with the current request time and expected sender or subject. A fixed sleep wastes time when mail arrives quickly and still fails when delivery takes longer. On a reused inbox, "latest email" alone can return a message from a previous attempt.

The Playwright email guide covers message matching and browser assertions. For Cypress, use the email testing walkthrough; for Java, see the Selenium inbox example.

When the application rejects the test address

First compare the submitted value with the complete emailAddress returned by MailSlurp. An inbox ID, a missing domain or whitespace copied into the field can fail before the application attempts to send.

Next, inspect your application's validation rule and the actual error. Syntax checks, domain checks and an organization's allowed-domain policy are separate decisions. When the scenario needs a company-owned domain, configure a custom test domain that you control and exercise the application's intended rule. Keep a separate test for addresses the application is supposed to reject.

If the form accepts the address but no message arrives, inspect the application's send attempt and its provider response before changing the inbox. The delivery checklist helps distinguish a send failure from an incorrect wait filter.

Keep test accounts separate between runs

Create a fresh inbox per test when tests run independently. A worker-level inbox can be useful when tests deliberately share a test identity, but its message matching must distinguish each request. Keep a persistent inbox only when the scenario needs the same address across sessions.

Delete short-lived inboxes during teardown and set an expiry for interrupted runs. Clean up the application's test user separately. If you need to inspect a failure before cleanup, retain only the necessary message details with access controls; OTPs and reset links can grant access to a test account.

The test email account guide explains these lifetime choices, including returning-user tests and notification checks.