ShazaMail
Password Reset Email Testing
Verify reset-email delivery and application behavior without routing recovery messages through a developer’s personal mailbox.
Product documentation last reviewed: 2026-09-28
Use a controlled test account and isolated inbox
Password recovery is a security-sensitive workflow. Create a synthetic account whose email points to a dedicated ShazaMail test inbox, then start the reset flow through the same UI or API that production users would use. Keep the mailbox isolated per test run so the automation cannot accidentally consume a reset link generated by another scenario.
Test the request response for account-enumeration leakage
A reset endpoint should not reveal whether an account exists through obviously different response text or timing. In addition to checking email delivery for the valid synthetic account, run the same request against a non-existent address and assert that the public response remains appropriately generic. OWASP recommends consistent responses and rate limiting around password-reset requests to reduce enumeration and flooding abuse.
Wait for the reset message using delivery criteria
Use the ShazaMail wait endpoint with received_after plus a sender or subject matcher so the test only accepts a reset message generated by the current run. The API can return the message body and extracted verification data when available, but reset-link parsing should remain explicit in the test because URL structure belongs to the application under test rather than ShazaMail.
Assert token lifecycle, not just link presence
A strong reset test follows the link or submits the code and verifies that the user can choose a new password only while the token is valid. It should also cover expiry and replay: after a successful reset, the same reset token should no longer work. The reset message itself should never contain the user’s existing password, and the test should avoid writing full reset URLs to long-lived CI logs.
Confirm the post-reset security state
After changing the password, assert the behavior that your product promises: login with the new password, rejection of the old password, notification of the account change, and any session-invalidation policy your application implements. ShazaMail verifies the email side of the workflow; account authorization and session management remain the responsibility of the system under test.
Primary references
Common questions
Should a forgot-password page reveal that an email address is registered?
Generally no. OWASP recommends a consistent public response for existing and non-existing accounts to reduce user-enumeration risk.
What should a password-reset test do after using a reset link?
Verify the new password works, the old password no longer does, and the reset token cannot be reused after a successful reset.
Can ShazaMail validate whether my reset token is cryptographically secure?
No. ShazaMail receives and exposes the test email; token generation, storage, expiry, single-use enforcement, and session policy belong to the application under test.