Email is one of the easiest parts of a product to overlook during testing. It sits outside the main application, often requires a separate inbox, and rarely appears in a sprint demo. Yet a broken welcome message or a dead verification link can block new users immediately.
A checklist keeps email testing consistent across releases and makes it easy to onboard new QA engineers. The sections below cover the areas that deserve a look before every significant release.
Before You Start
Preparation prevents most email-testing confusion. Confirm a few basics first:
- Identify every email the application can send
- Know the sending domain and expected "from" address
- Have a disposable inbox ready for each tester
- Confirm access to staging or a safe test environment
- Note which messages contain time-sensitive links or tokens
Using a dedicated Public Inbox per tester avoids collisions and keeps personal mail out of the process.
Content and Rendering Checklist
Email clients render HTML inconsistently, so content checks matter as much as functional ones.
- Subject line is correct, not truncated, and matches the trigger
- Preview text adds value instead of repeating the subject
- Greeting and personalization tokens resolve with real data
- No placeholder text such as "FIRST_NAME" or "[email protected]"
- Links use the correct environment and HTTPS
- Images load and include descriptive alt text
- Plain-text fallback is present and readable
- Layout holds up on mobile widths
Functional and Link Checklist
Every call to action should lead somewhere useful.
- Verification, reset, and confirmation links actually work
- Tokens are valid for their intended lifetime
- One-time links fail gracefully after use
- Unsubscribe links function and respect preferences
- Reply-to addresses route to a monitored mailbox
- Tracking parameters do not break the destination URL
- Footer contains required legal or contact information
Click each link rather than reading the HTML, since a valid-looking anchor can still point at a removed page. A quick way to keep these checks concrete is to record them as structured test data.
email_case:
trigger: user_signup
expected_subject: "Confirm your account"
required_links:
- verify_email
- unsubscribe
token_lifetime_minutes: 60
one_time: true
Deliverability and Configuration Checklist
Deliverability issues often appear only in production, but configuration can still be verified early.
- SPF, DKIM, and DMARC records are present for the sending domain
- The "from" domain aligns with the signing domain
- Test messages do not land in spam for major providers
- Bounce and complaint handling is wired to the application
- Rate limits are in place to prevent accidental floods
- Staging uses sandboxing so real users are never emailed
Some of these settings live in DNS and mail provider dashboards rather than in application code, so confirm ownership and record where each record is managed. A misaligned record can send otherwise correct messages straight to spam.
Accessibility and Formatting Checklist
Deliverability also depends on how the message is built.
- Use semantic headings instead of styled paragraphs
- Maintain readable contrast in text and buttons
- Set a sensible line length and font size for mobile
- Avoid image-only emails that break when images are blocked
- Confirm the message renders when CSS is stripped
Automation and Regression Checklist
Manual checks per release do not scale. Move stable cases into automation:
- Provision a fresh inbox for each test run
- Trigger the email through the application, not by calling the mailer directly
- Assert on subject, key content, and link targets
- Clean up test accounts and messages after the run
- Fail the build when an expected email never arrives
The Public Mailbox API makes these steps straightforward by letting tests read messages programmatically instead of relying on a shared human inbox.
Conclusion
A predictable email-testing checklist turns an often-neglected area into part of your normal release routine. Cover content, links, deliverability, and automation, and adapt the list as your product grows. Run it before every meaningful release so users never discover a broken email before you do.
