mails0 vs testmail.app: tagged test inbox or agent identity?

Namespace tags and mailbox keys solve isolation at different layers

testmail.app documentation describes a namespace with wildcard test addresses. A test can add a unique tag to the address, send a message, and query for that tag. This is attractive in CI because the test runner does not need to create and delete a separate account for every recipient variation.

mails0 can create a separate provisional mailbox with its own credential. The identity is heavier than a tag, but it also becomes a security and lifecycle boundary. An agent can hold one mailbox scope, retrieve only its own data, and later discard or deliberately promote the identity.

Neither model removes the need for a trigger timestamp and an explicit timeout. Tags prevent cross-run collisions only when the application preserves the recipient and the query actually filters on the unique value.

Compare the smallest contract your automation needs

Make the test deterministic before optimizing the polling call

Create the unique recipient before the browser or API action. Record the trigger time immediately before submission. Query for the recipient, expected sender context, subject or message type, and received time. Stop at a bounded deadline and report whether the application failed to send, the provider delayed delivery, the parser failed, or the final verification rejected the value.

A fixed sleep is simple but slow and flaky. A live query, long poll, webhook, or bounded polling loop should end as soon as the matching message arrives. It should not keep the build alive indefinitely. Parallel jobs must never read from one unfiltered inbox and select the newest message globally.

The difference grows when the recipient acts outside the test runner

A pure test runner can compose API queries in code. A coding agent or MCP client benefits from higher-level operations with narrow outputs: create an inbox, wait for a code, search messages, fetch one thread, or download one approved attachment. Those operations reduce raw mailbox content in model context.

mails0 also defines a path from temporary receiving to a permanent identity and optional sending. That broader lifecycle is unnecessary for many tests. If tags and message retrieval solve the entire job, testmail.app may be the more focused choice.

• Prefer testmail.app when namespace addressing already maps cleanly to your test runner.
• Prefer mails0 when credentials and mailbox lifecycle are part of the agent boundary.
• Do not grant sending authority just because the receive test passed.
• Keep product-specific query code behind a small adapter if provider portability matters.

Map tag semantics before moving to mailbox semantics

A suite may generate thousands of tagged recipients under one namespace without tracking mailbox objects. Moving that suite to per-mailbox provisioning changes setup cost, cleanup, credential storage, and concurrency. Test those effects before converting every case.

The reverse move also changes authorization. A tag can identify a test message without being a credential boundary. If the existing system relies on per-mailbox revocation or separate retention, preserve those requirements in the application layer. Export enough message and run identifiers to compare both systems during a bounded dual run.

Sources and product scope

Product behavior is verified against the mails0 source and documentation. External comparisons link to official vendor documentation checked on 2026-08-15.

Related implementation paths