Trigger
Application accepted the action
The signup or reset endpoint returns the expected state and identifies the mailbox that should receive the message.
Built for QA engineers
Test the email users actually receive, not only the send call.
Create an isolated address, trigger the product workflow, wait for delivery, inspect the message, and assert the state the user experiences.
Direct answer
QA teams can use mails0 to test end-to-end email workflows with real inboxes instead of mocking the application's send function. A robust test creates or assigns an isolated mailbox, triggers the user action, waits with a deadline, validates sender and content, follows the code or link, and cleans up its state.
Decision map
Assert delivery and user-visible content as separate outcomes
- 01Application accepted the action
The signup or reset endpoint returns the expected state and identifies the mailbox that should receive the message.
- 02The message reached the inbox
The test waits for an inbound email with an explicit timeout instead of assuming the provider accepted it.
- 03The message completes the journey
The code or link works, and the browser or API reaches the verified state a user needs.
Test contract
Assert delivery and user-visible content as separate outcomes
Deliver
The message reached the inbox
The test waits for an inbound email with an explicit timeout instead of assuming the provider accepted it.
Use
The message completes the journey
The code or link works, and the browser or API reaches the verified state a user needs.
End-to-end sequence
A repeatable email test has six bounded stages
-
01
Allocate a clean mailbox
Create a provisional inbox or reserve a unique address so previous messages cannot match.
-
02
Trigger the product behavior
Submit the form or API request and record the expected recipient and starting time.
-
03
Wait for inbound mail
Poll or subscribe with a deadline that is long enough for real delivery but short enough to keep CI actionable.
-
04
Validate the envelope and content
Check sender, recipient, subject, required copy, link host, and any code format.
-
05
Complete the user action
Follow the link or enter the code and assert the final application state.
-
06
Clean up and retain evidence
Delete disposable state while keeping message IDs, timings, and redacted test evidence for failures.
Flake control
Most email-test flakiness comes from identity and timing ambiguity
A shared inbox accumulates stale messages and forces tests to guess which result belongs to the current run. Fixed sleeps then hide delivery variance while making the suite unnecessarily slow.
Use unique recipients, record the trigger time, wait for a matching inbound message, and fail with clear diagnostics. If parallel tests share a domain, bind assertions to mailbox identity rather than subject text alone.
- Never use a production employee inbox in automated tests.
- Prefer event or bounded wait APIs over fixed sleeps.
- Validate links before navigating to prevent test-controlled phishing behavior.
- Keep provider acceptance, inbox delivery, and final user verification as separate assertions.
Coverage map
Email workflow coverage by risk
| Flow | Minimum assertion | Higher-confidence assertion |
|---|---|---|
| Signup verification | Code or link arrives. | Link verifies only the intended pending account and cannot be reused. |
| Password reset | Reset message arrives. | Token expires, is single-use, and does not disclose account existence. |
| Invitation | Invite identifies organization and inviter. | Wrong recipient cannot accept; revoked invite fails. |
| Receipt or confirmation | Expected transaction data appears. | Amounts, currency, identifiers, and attachments match source records. |
| Delivery failure | Application records a failure state. | Retry, suppression, and user-visible recovery paths are exercised. |
Evidence
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.
- mails0 source repositoryImplementation, license, and deployment source
- mails0 Playwright workflowBrowser verification example
Questions and answers
Questions that come up in practice
Why not mock email in every test?
Mocks are useful for unit tests, but they cannot prove DNS, provider, routing, parsing, template, link, or inbox behavior. Keep unit mocks and add a smaller end-to-end email suite.
How long should an email test wait?
Use an explicit timeout based on the environment and expected provider latency. Record arrival time and fail clearly instead of using an unbounded poll or a fixed sleep.
Can tests run in parallel?
Yes, when each test has an isolated mailbox or uniquely addressable recipient and the assertions bind to that identity.
Should CI use provisional or permanent mailboxes?
Use provisional mailboxes for isolated receive-only tests when limits fit. Use a controlled self-hosted or persistent test environment when suites require stable domains, sending, or higher volume.
Start with a bounded inbox
Give the agent an inbox, then prove the workflow.
Start with a receive-only temporary mailbox. Move to a permanent identity or self-hosted deployment only after the workflow reaches a real email value event.