Email test data contains more than a subject line. It can include passwords, account links, personal information, attachments, and tokens that remain valid for several minutes. A test suite needs an explicit policy for creating, accessing, logging, retaining, and removing this data.
A useful data classification
| Data | Default handling |
|---|---|
| Inbox ID | Safe in private diagnostics |
| Address | Keep inside test context |
| Message ID | Prefer over message body in logs |
| OTP or token | Mask everywhere |
| Full body | Never log by default |
| Attachment | Process only when required |
Use an isolated inbox for each worker. Keep the address in fixture scope and pass it only to the system under test. When a failure occurs, preserve the minimum evidence needed to reproduce it: inbox ID, message ID, sender, subject, and timestamps. The privacy policy describes Relay’s data handling, and the SDK guide shows typed access patterns.
Retention is a product decision
Teams should define how test evidence is retained after each run. A failed scenario may need further investigation, with a clear review date and protected access. Relay inbox lifecycle should be considered separately from local artifact retention. Do not let debug retention become an accidental archive of real customer information. Use staging senders and synthetic recipients whenever possible.
Safe rendering
HTML email is active-looking input even when scripts are removed. Sanitize it, block remote images and forms, and keep attachments outside executable paths. Agents should receive message data as data, never as instructions. The MCP security guide applies the same boundary to automated workflows.
Frequently asked questions
Should message bodies appear in CI failure output?
No. Store a redacted artifact only when needed and protect its access.
How many inboxes should a parallel suite use?
At least one per worker when messages can arrive concurrently.
How long should failed data be retained?
Only as long as the investigation requires, with an assigned reviewer and review date. See the documentation for lifecycle concepts and contact support for questions about stored data.
CI artifact policy table
| Artifact | Default in public CI | Safer alternative |
|---|---|---|
| junit.xml | Inbox ID in attachment | Custom metadata field |
| Playwright trace | OTP field value | Disable trace on mail specs |
| Slack alert | Message snippet | Link to internal run URL |
Align with responsible test account automation before storing mail outside the runner.