Signup Email Verification Testing

Create the inbox before the account under test

A signup test should create a dedicated ShazaMail test inbox before submitting the registration form. The API returns a real receiving address and inbox ID that belong to the authenticated developer account. Attach a run_id or external_reference so a failure can be traced back to the exact CI job. Isolating the mailbox per test prevents a code or link from a previous registration from satisfying the current assertion.

Submit the generated address through the real signup flow

Use the generated address exactly as a user would: enter it in the application signup form or API, submit the registration, and let the system under test send its normal verification message. This tests more of the real delivery path than replacing mail with a local stub. The test should still keep account-creation data synthetic and should never place production credentials or customer information in a disposable inbox.

Wait for the expected message, not an arbitrary delay

POST /api/v1/test-inboxes/:id/wait can match on sender, recipient, subject, verification-code presence, category, received_after, or internet_message_id. The wait engine performs an immediate lookup before subscribing for delivery and caps a single wait at 30 seconds. This is more deterministic than sleeping for a fixed number of seconds and hoping the email has arrived.

Assert ownership verification in the application, not only in the mailbox

Receiving an email proves that the application emitted a message to the test address; it does not prove that the application correctly validates the token or code. Continue the test by opening the verification link or entering the returned code, then assert the expected account state. Secure identity systems should use single-use, time-limited verification tokens and should not activate an account before ownership verification is complete.

Clean up and retain only useful failure evidence

Delete or allow the test inbox to expire after the scenario. On failure, preserve identifiers such as the CI run ID, inbox ID, HTTP status, and application trace IDs rather than dumping API secrets, complete tokens, or full message bodies into permanent logs. This keeps test artifacts useful without turning CI output into a credential store.

Primary references

• OWASP Email Validation and Verification Cheat Sheet

Common questions