Dummy Email Address Guide for Temporary Accounts and Signup Tests

A dummy email address can be a fictional value used in a form test or a working inbox used for signup verification, OTP checks and password resets. Choose a receiving inbox when the test needs to read a message; a plausible address string is enough only when you are checking input handling without delivery.

The important decision is not only whether the address is temporary. It is whether the inbox model is reliable, private, and controllable enough for the workflow you are testing. MailSlurp lets you start with a quick generated address, then move the same flow into API-managed inboxes, webhooks, and CI assertions when the workflow needs repeatable proof.

Use a reserved example such as person@example.com for a form fixture that never sends. When the test needs receipt, use the address returned by a MailSlurp inbox. Start with the fake email generator for a manual check, or create a private API inbox for a repeatable signup, OTP or reset test.

Three dummy-email models

Public temporary inbox

Fast for one-off manual checks, downloads, or exploratory signup tests.

Tradeoff: weaker isolation, less privacy, and harder automation control. Avoid public inboxes for sensitive data, customer-like payloads, billing messages, access links, or repeatable QA.

Alias on a real mailbox

Useful for personal filtering and lightweight account separation.

Tradeoff: still tied to your primary mailbox and identity. Aliases are convenient but often become noisy, hard to clean up, and difficult to parallelize in test suites.

Private API inbox

Best for team testing, support reproduction, and automation.

Tradeoff: requires implementation setup, but gives predictable behavior: one inbox per run, worker, customer scenario, or environment. MailSlurp private inboxes can be created, read, expired, tagged, and cleaned up through the API.

How to create a dummy email safely

Use this sequence when the address needs to work, not just look valid:

1. Generate a MailSlurp inbox or use the fake email generator for a quick manual check.
2. Paste the address into the signup, invite, password reset, or OTP flow you are testing.
3. Trigger the real application email.
4. Open the MailSlurp inbox and inspect the sender, subject, body, links, headers, attachments, and OTP or reset token.
5. Move the workflow into API automation when the same check needs to run in Playwright, Cypress, Selenium, Postman, backend tests, or CI.

For private workflows, create a MailSlurp account and use API-created inboxes so every test run has its own address and cleanup policy.

Dummy inboxes in CI: practical pattern

The helper below creates one private inbox, calls your application's signup action, waits for its exact verification subject and hands the received email to your final account assertion. Install mailslurp-client and set MAILSLURP_API_KEY in the test runner's environment. The two callbacks are adapters for your application: the first submits signup; the second follows the delivered link or code and checks the verified account.

import assert from "node:assert/strict";
import {
  MailSlurp,
  MatchOptionFieldEnum,
  MatchOptionShouldEnum,
  type Email,
} from "mailslurp-client";

export async function checkSignupEmail(
  expectedSubject: string,
  register: (emailAddress: string) => Promise<void>,
  verifyAccount: (email: Email, emailAddress: string) => Promise<void>,
) {
  const apiKey = process.env.MAILSLURP_API_KEY;
  if (!apiKey) throw new Error("Set MAILSLURP_API_KEY");
  const mailslurp = new MailSlurp({ apiKey });
  const inbox = await mailslurp.createInboxWithOptions({
    expiresIn: 15 * 60 * 1000,
  });

  try {
    const since = new Date();
    await register(inbox.emailAddress);
    const email = await mailslurp.waitController.waitForMatchingFirstEmail({
      inboxId: inbox.id,
      since,
      timeout: 30_000,
      unreadOnly: false,
      matchOptions: {
        matches: [{
          field: MatchOptionFieldEnum.SUBJECT,
          should: MatchOptionShouldEnum.EQUAL,
          value: expectedSubject,
        }],
      },
    });
    assert.ok(email.to?.includes(inbox.emailAddress));
    await verifyAccount(email, inbox.emailAddress);
  } finally {
    await mailslurp.inboxController.deleteInbox({ inboxId: inbox.id });
  }
}

Use the subject your application actually sends. If one test requests several similar messages, also match a request-specific value that the application includes; a subject alone cannot identify a resend. The complete Playwright reset example demonstrates matching separate requests and asserting the signed-in identity.

The finally block removes only this test's inbox, including when signup or verification fails. Clean up the application's user separately. Expiry is a fallback for an interrupted test, not confirmation that retained messages were deleted. Keep API keys, usable verification links and codes out of shared test output.

Check failures as well as receipt

Run two distinct signup scenarios together and verify each resulting account. Then test a missing message, an incorrect code and an expired or reused link according to your application's rules. A test that only checks whether something arrived will miss those failures.

For a failed run, retain the message ID and sanitized assertion details. If the email looks wrong, device previews let you inspect its delivered appearance separately from the account action.

FAQ

Can I make a fake email account for signup testing?

Yes. Use a MailSlurp generated inbox when you need a fake email account that can receive the signup or verification message. For repeatable tests, create a private inbox by API and wait for the expected email.

Is a dummy email the same as a temporary email?

A dummy address may be only a form fixture. A temporary email inbox can receive messages for a limited time. MailSlurp creates working inboxes for the tests that need receipt, with lifecycle settings you choose for the scenario.

What is a one-time-use email?

A one-time-use email is an address used for a single signup, download, test, or verification flow. Use explicit expiration and cleanup when the address is no longer needed.

Can dummy email accounts receive OTP codes?

Yes. MailSlurp inboxes can receive OTP, MFA, magic-link, and password reset emails. Automation can wait for the message, extract the code or link, and complete the flow.

Should I use a public dummy inbox for sensitive workflows?

Use a private MailSlurp inbox when messages include access links, billing information, customer-like data, internal credentials, or anything needed for repeatable QA.

For a complete browser example, follow the test-address signup and reset guide. For reusable API helpers, continue with the disposable inbox API guide.