How to Test Sign-Up and Password-Reset Emails: A Practical Guide for Developers

By the MailGenerator Team · Updated November 8, 2026

Transactional emails, the sign-up confirmations, verification codes and password resets your app sends, are some of the most important messages your product will ever send. If they break, users can't get in. Yet they're often tested last, by hand, with someone's personal Gmail. This guide gives you a better routine.

Pick the right tool for each stage

There are three kinds of inbox you can test with, and each fits a different stage:

• A local mail catcher such as Mailpit or MailHog runs on your machine and captures everything your app sends, without delivering anything to the internet. Best for day-to-day development.
• An email testing sandbox (several email delivery providers offer one) captures mail in a hosted inbox your whole team can see, with tools to inspect HTML and spam scores. Best for staging environments.
• A real, public inbox, including a disposable one like MailGenerator, receives mail through the real internet. Best for end-to-end checks of the live sending setup: DNS records, deliverability and how the email looks in a real client.

Use local catchers for most work, and real inboxes for a final check before release and after any change to your sending domain or provider.

The sign-up email checklist

1. It arrives quickly. Time it. More than a minute will lose you users.
2. The sender name and address look trustworthy. "Acme" from no-reply@acme.com, not a raw server hostname.
3. The subject says what it is. "Confirm your Acme account" beats "Welcome!!!".
4. The link or code works once, and only once. Click it twice; the second click should explain the account is already confirmed.
5. Expired links fail gracefully with a button to send a new one.
6. It works across devices. Start sign-up on desktop, open the email on a phone. Does the link still work?
7. Plain-text version exists and contains the full link.
8. No private data leaks into the email or URL, such as the user's password or internal IDs.

The password-reset checklist

1. Same response for real and unknown addresses. The reset form should say "If an account exists, we've sent an email" either way, so attackers can't use it to discover which emails have accounts.
2. Tokens expire. A reasonable window is 15 to 60 minutes.
3. Tokens are single-use, and requesting a new reset invalidates the old link.
4. Changing the password signs out other sessions, or at least offers to.
5. A confirmation email is sent after the password changes ("Your password was changed. Wasn't you? Contact us.").
6. Rate limits are in place so the form can't be used to flood someone's inbox.

Check your sending domain is set up properly

Most "the email never arrived" bugs in production aren't code bugs. They're DNS. Before launch, confirm:

• SPF includes your email provider.
• DKIM signing is enabled and the DNS record is published.
• DMARC is published, starting with a monitoring policy (p=none) and tightening later.

Send a test to a real inbox and open the full headers. You want spf=pass, dkim=pass and dmarc=pass for your domain. Our guide How to Read Email Headers shows where to find them. Gmail and Yahoo now expect bulk senders to have these in place, and missing records are a common reason transactional mail lands in spam.

Testing with a disposable inbox: do's and don'ts

• Do use it to test your own app's emails end to end, especially on staging and right after deploys.
• Do use a fresh address per test run, so old messages don't confuse results.
• Don't send real customer data, passwords or production secrets to any public inbox. Temporary inboxes aren't password-protected.
• Don't use disposable addresses to create accounts on other companies' services at scale. That's abuse, and it breaks our Terms of Service.
• Note that if your own app blocks disposable domains (many do), you'll need to allow your test domain or use a catcher instead.

Automating it

For automated end-to-end tests, use a mail catcher or sandbox with an API, so your test suite can fetch the latest email, extract the link or code, and continue the flow. Keep one manual end-to-end check through a real inbox in your release checklist; automated catchers can't tell you whether real mailbox providers accept your mail.

Frequently asked questions

Why does my email work in the catcher but land in spam for real users?

Catchers don't run spam filters. Check SPF, DKIM and DMARC, avoid sending from a brand-new domain at high volume, and make sure your content isn't image-only or link-heavy.

Should verification links or codes be used?

Both work. Codes are easier when users switch devices; links are easier on a single device. Many apps send both in the same email.