Test the emails your users actually get
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.
Two inboxes. One address per Test Case when you need it.
Account inbox: shared mailbox for journeys that reuse one address across tests.
Test Case inbox: a unique address for each Test Case Run. Parallel Runs do not collide. Every test can register its own user without sharing mail.
Use $testEmail in the form. Wait for email. Open the message. Continue the journey.
Full journeys, not just “did SMTP fire.”
Register and verify email
Forgotten password and reset links
Passwordless and magic-link login
Content checks and accessibility on the open message
Inspect inboxes during a Run or after it finishes
Hands-on guides: Email testing in DoesQA, Registration and verification, Forgotten password, Passwordless login.
Part of the platform, not a bolt-on.
Email sits beside MFA, API steps, branching Flows, hosted Runs, and Results. One product. One place to maintain the journey.
