How does testmail.app provide unlimited email addresses and mailboxes?

testmail.app gives you unlimited addresses by making the address itself the mailbox. After you sign up and receive a namespace, any address in the form {namespace}.{tag}@inbox.testmail.app is valid, where {tag} can be anything you choose. Each distinct tag is a separate email address and mailbox, so you create them on the fly without registering or provisioning anything. This applies to every plan, including the free forever plan (100 emails/month, no credit card required).

The addressing model

The service separates two parts of every address:

So [email protected] and [email protected] are two independent mailboxes, both belonging to the same namespace. There is no list of pre-created mailboxes to manage — the tag is the mailbox.

Because the tag is arbitrary, you can generate addresses programmatically: use a test run ID, a timestamp, a UUID, or a user identifier. This is what makes the count effectively unlimited.

Why this matters for testing

The intended workflow is to send test emails to these addresses instead of to real customers. testmail.app receives, parses, spam-tests, and indexes each message so you can retrieve it later through an API. That turns email verification into a normal API call inside your end-to-end tests or CI/CD pipeline.

A typical loop looks like this:

1. Generate a unique tag for the test (for example, run-2024-06-01-001).
2. Use the address {namespace}.{tag}@inbox.testmail.app wherever your app sends mail — signup confirmation, password reset, transactional receipt.
3. Query the API for messages matching that tag.
4. Assert on the subject, body, links, or attachments.

Because each run gets its own tag, parallel test runs don't collide, and you don't need to clean up mailboxes afterward.

Retrieving and managing mail

You interact with mailboxes entirely through APIs, not a manual inbox UI:

• JSON API for straightforward queries.
• GraphQL API for more flexible queries, with an interactive GraphQL Playground for testing queries.
• Any HTTP or GraphQL client works, in any language or environment, including CI/CD pipelines.

Features that support real test scenarios include wildcard search, "live" queries that wait for a new email to arrive, sorting, pagination, attachments, and SpamAssassin reports. The live-query option is what lets a test block until the expected email shows up rather than polling blindly.

Teams and namespaces

You can invite team members by email and share test emails, API keys, and usage monitoring. Separate namespaces (and therefore separate mailboxes) can be created per project, which keeps projects isolated. Collaborators can be invited on all plans at no extra cost; managing multiple separate teams is an enterprise-plan feature.

Practical notes

• Signup is required to get your namespace and API key — the address format only works within your own namespace.
• The free tier is capped at 100 emails/month, so "unlimited addresses" does not mean unlimited message volume. Check the pricing page for current plan limits.
• Security posture: HTTPS/TLS is forced, data is encrypted in transit and at rest, logins are passwordless, and APIs are distributed across multiple data centers with a published 99.99% uptime SLA and a public status page.

The short version: unlimited mailboxes come from treating the tag portion of the address as the mailbox identifier, so you never create a mailbox — you just pick a new tag and query for it.