MailSlurp lets you create inboxes on demand from the [API](/api/), SDKs, or dashboard. Most teams use this to generate clean test identities for each test run, isolate environments, and avoid cross-test mailbox pollution.

## What this solves

Creating inboxes programmatically helps you:

- Run deterministic signup, verification, and password-reset tests.
- Create one inbox per test or per CI job for easier debugging.
- Avoid exposing personal email addresses in QA workflows.
- Control mailbox lifecycle with expiration and cleanup policies.

## Pattern 1: create a random inbox

The default `createInbox()` call returns a unique address on a MailSlurp-managed domain:

```json
{
  "id": "32f88182-3b6a-4f6e-8a53-59819931033a",
  "emailAddress": "32f88182-3b6a-4f6e-8a53-59819931033a@mailslurp.com",
  "created": "2019-12-06T13:04:13.998Z"
}
```

This is usually the best choice for high-volume automation because every run starts with a clean mailbox.

## Pattern 2: create an expiring inbox

For short-lived QA jobs, set an expiration so stale inboxes are removed automatically.

Use this for:

- Branch-preview environments
- One-time UAT sessions
- Security-sensitive workflows where retention should be limited

## Pattern 3: create a specific address on your domain

If you need predictable addressing, pass an explicit `emailAddress` value (for example `billing-test@yourdomain.com`).

This requires a verified domain in MailSlurp. See [custom domain setup](/guides/custom-domains/).

Use this pattern when:

- You test strict sender/recipient allowlists.
- External systems can only send to known static addresses.
- You need audit-friendly mailbox naming per workflow.

## Test architecture recommendations

Avoid sharing a single inbox across your entire suite. A better model is:

1. Create inbox per test case or per worker.
2. Trigger application action (signup, reset, invite, OTP).
3. Wait for matching message criteria.
4. Assert subject/body/links/codes.
5. Delete inbox or rely on expiration policy.

For receive-side waits and assertions, use [receiving emails in code](/guides/receiving-email/).

## Lifecycle and cleanup

Use explicit cleanup for long-running test projects:

- Delete inboxes at the end of each run when possible.
- Use expirations for backup cleanup when test jobs fail early.
- Add naming conventions or tags so orphaned resources are easy to audit.

If you manage teams, pair this with [organization controls](/guides/organizations/) and API key scoping.

## Security and governance

Inbox provisioning is infrastructure, not just test data. Recommended controls:

- Separate API keys by environment.
- Avoid reusing production keys in CI.
- Keep retention policies aligned with compliance requirements.
- Route high-risk events to webhook-driven monitoring.

See [API key setup](/guides/api-key/) and [email webhooks](/guides/email-webhooks/).

## Next steps

- [Receive and parse emails](/guides/receiving-email/)
- [Send emails from code](/guides/sending-emails/)
- [Test OTP and MFA workflows](/guides/otp-one-time-password-email-test/)