Current sample
Sign-up verification sample
- Trigger
- Create a new, unverified account
- Required variables
- Name, six-digit code, expiry time, device details
- Pass criteria
- Email arrives; latest code works; previous code is invalid; readable on mobile
Transactional message lab
Start with the trigger. Define variables, delivery evidence, and pass criteria for sign-up, reset, order, and security notifications so every change follows a repeatable acceptance path.
Scenario matrix
Each sample should validate one critical path. Don’t change the subject, variables, layout, and links in the same send.
Current sample
Run protocol
Evidence lets the team reproduce issues and determine whether failure occurred in the business trigger, email generation, delivery queue, or inbox rendering.
Record the environment, account state, action time, and request result.
Save the template version and check empty values, time zones, and language branches.
Record the message ID, acceptance time, retries, and rejection reason.
Check the subject, sender, and both HTML and plain-text parts.
Document the decision, screenshots, owner, and conditions for the next retest.
Failure library
Precise classification keeps template, backend, and delivery teams from guessing at one another.
The application did not create an email job. Check conditions, permissions, idempotency keys, and event logs instead of refreshing the inbox again.
The job exists, but variables, language, or template compilation failed. Save the input data and make the failure replayable.
The message was accepted by the service but remains queued or is being retried. Use the message ID and status timeline to determine what happened.
The email arrived, but the layout, images, links, or plain-text fallback is unacceptable. Review the same message on desktop and mobile.
Start a run
Choose a scenario, copy the address, trigger the send from your real system, then record the result across all five evidence types.
Start a sample run