This kit is for developers testing email flows in an application they control. It separates three questions: did the app generate the right email, did transport deliver it, and did the app accept or reject the token correctly? One passing step does not prove the other two.
1. Run the local fixture checks
Download the Node.js test kit. Save the file, then run node --test email-qa-test-kit.mjs with a supported Node.js installation. It uses only Node's built-in test and assertion modules. It does not contact a server, submit credentials, send email or register accounts.
The examples cover an OTP with a leading zero, delayed arrival from an older request, matching the intended recipient, and rejecting an email from a different test run. Replace the synthetic records in your own test project with records produced by your application; never put real codes or passwords in shared test logs.
2. Test one real delivery you control
- Create one fresh inbox and save its credentials privately. Record a local test-run reference that contains no customer data.
- In your own application, request exactly one verification message. Record the request time, time zone and recipient internally.
- Wait for that message in the same inbox. Confirm the recipient, expected sender and purpose before opening links.
- Record the observed arrival delay without recording the active code or reset URL in a public report.
- Compare the plain-text alternative and HTML view at a mobile width. Confirm the essential action remains understandable if images do not load.
- Complete the verification in your application. Confirm that it updates only the intended test account.
- Test return access with saved mailbox credentials in a separate browser session. Remove the controlled fixture after the test if it is no longer needed.
3. Exercise failure cases in your application
| Case | Assertion owned by your application |
|---|---|
| Second request before first email arrives | Follow your documented token-invalidation policy; do not infer request order from arrival order |
| Expired token | Reject it and provide a safe fresh-request route |
| Token submitted a second time | Enforce single use when your flow requires it |
| Code belongs to a different account | Reject it without exposing account details |
| Wrong address entered by the tester | Do not mark verification complete merely because the send call succeeded |
| Sender refuses a temporary domain | Use an allowed test address; do not bypass the sender's policy |
The inbox cannot assert token expiry or account state for another website. These checks belong in your application tests. See expired-code troubleshooting for the user-facing distinction.
What we have tested, and what we have not
On September 14, 2026, our release checks exercised a controlled mailbox on our server: durable creation, the local receiving adapter, duplicate-delivery suppression, authenticated message reading, return login and local Postfix transport. Separate isolated-database tests covered restart durability and uncertain database acknowledgements. The synthetic mailbox was removed after the check.
These are server-local tests. They do not measure delivery from every public email provider, prove universal third-party acceptance, or guarantee uptime. Public-domain MX lookups are separately available on the domains page. Record sender, environment, date, sample size and failure cases whenever you publish your own results.
Keep test evidence useful and private
Use generated test accounts and recipients you control. Redact email addresses, message bodies, credentials and tokens before sharing diagnostics. Retain aggregate pass/fail results and timings instead of live secrets. For multi-inbox work, use bulk creation; for a reviewer who needs temporary access, use a revocable share.