> For the complete documentation index, see [llms.txt](https://docs.does.qa/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.does.qa/guides/email-testing-in-doesqa.md).

# Email testing in DoesQA

Many products send email during signup, login, checkout, or account changes. DoesQA includes test inboxes and [Mail Test Steps](/test-steps/mail.md) so those journeys stay inside one Flow. You do not wire a separate mail service into your tests.

## Two inbox types

| Inbox         | Value                                                                                               | Use it when                                                                  |
| ------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| **Test Case** | [`$testEmail`](/values/built-in-values.md) or [`$testEmailShort`](/values/built-in-values.md)       | The message belongs to one Test Case, such as registration or password reset |
| **Account**   | [`$accountEmail`](/values/built-in-values.md) or [`$accountEmailShort`](/values/built-in-values.md) | Several Test Cases should share one mailbox                                  |

Prefer **Test Case** for signup and reset flows. Each Test Case gets its own address for that Run, so parallel Runs do not read each other's mail.

## What you can do in a Flow

A typical email journey looks like this:

```mermaid
flowchart TD
  enter["Set value with $testEmail"] --> trigger["Submit the form"]
  trigger --> wait["Wait for email"]
  wait --> openMail["Open email"]
  openMail --> act["Touch, Check, or Validator steps"]
  act --> close["Close inbox"]
```

* [**Wait for email**](/test-steps/mail/wait-for-email.md) pauses until the message arrives.
* [**Open email**](/test-steps/mail/open-email.md) opens the message so the body is the active page.
* Use normal [Action](/test-steps/action.md), [Check](/test-steps/check.md), and [Validator](/test-steps/validator.md) Test Steps on the open message. Click links, assert copy, or run checks such as [accessibility](/better-coverage/add-accessibility-checks.md) on the email content.
* [**Close inbox**](/test-steps/mail/close-inbox.md) returns to the application window.

Open **Mail** in the left navigation to inspect the Account inbox or a Test Case inbox while you build a Flow, or after a Run to review what arrived.

## Common journeys

| Journey                          | Guide                                                                                           |
| -------------------------------- | ----------------------------------------------------------------------------------------------- |
| Register and verify email        | [Test registration and email verification](/guides/test-registration-and-email-verification.md) |
| Forgotten password               | [Test a forgotten-password flow](/guides/test-a-forgotten-password-flow.md)                     |
| Passwordless or magic-link login | [Test passwordless login](/guides/test-passwordless-login.md)                                   |
| Hands-on Mail steps              | [Interacting with emails](/guides/interacting-with-emails.md)                                   |

## Compared with coded frameworks

Teams using Playwright, Cypress, or Selenium often add a third-party mail API and custom code to receive messages, parse links, and keep parallel tests isolated. DoesQA ships inboxes, wait and open steps, and hosted runners as one product. See [DoesQA compared](/choosing-a-test-automation-approach/doesqa-compared.md#journey-capabilities).

## Related

* [Interacting with emails](/guides/interacting-with-emails.md)
* [Mail Test Steps](/test-steps/mail.md)
* [Built-in Values](/values/built-in-values.md)
* [Test registration and email verification](/guides/test-registration-and-email-verification.md)