Built-in inboxes and Mail Test Steps inside every Flow.
Your product sends mail. Your tests should catch it
Registration, verification, password reset, and magic-link login all depend on email arriving, reading correctly, and linking back to the app. Coded frameworks usually mean a separate mail API, custom parsing, and fragile parallel setup.
DoesQA includes test inboxes and Mail Test Steps in the product. Wait for the message, open it, click the link, and assert on the content in the same Flow.
Mail steps in the product
Two inboxes. One address per Test Case when you need it
Inbox mode | When to use it |
|---|---|
Shared inbox | Simple checks where isolation is not critical |
Unique address per Test Case | Parallel Runs and registration journeys that need clean mail |
Full journeys, not just "did SMTP fire"
Register and verify email
Forgotten password and reset links
Passwordless and magic-link login
Content checks on the open message
Inspect inboxes during a Run or after it finishes
See Email testing in Features for changelog-level detail.
Part of the platform, not a bolt-on
Email sits beside MFA, API steps, branching Flows, hosted Runs, and Results. Start from Platform or Test data when the journey also needs dynamic Values and APIs.
