Onboarding email flow testing

Verification and welcome emails are part of your signup flow, and when they break, new users never come back. This page covers what to test in onboarding emails, how to set up a test inbox, and a task your AI beta tester can run.

Who it’s for

  • SaaS teams with email verification or a welcome sequence
  • Teams that changed their email provider or templates
  • Growth teams running onboarding drip campaigns
  • Developers debugging "I never got the email" support tickets

Updated 2026-10-19.

Why onboarding emails need a beta test

Onboarding emails sit directly in the path of a new user, but they are easy to forget during testing. They live in a different system from your app, they are often edited by marketing in a separate tool, and the team never receives them again after their own signup. Onboarding email testing checks that the right email arrives, says the right thing, and sends the user to the right place, every time.

When one of these emails breaks, nothing in your app shows an error. The user just waits for a verification link that never comes, or clicks a button that leads to a 404, and quietly gives up.

The emails that matter most

  • Verification / confirm your email: blocks access until clicked.
  • Welcome email: sets expectations and links to the first step.
  • Password reset and magic link: the user is waiting for it right now.
  • Invite emails: a teammate's first contact with your product.
  • The first onboarding emails in a drip sequence.

Only test what the tester can reach

A beta tester, human or AI, can only open emails sent to an inbox it has access to. Set up a dedicated test inbox (a shared test mailbox or a disposable inbox service you trust) and give it to the tester. If no inbox is available, the tester checks everything up to "we sent you an email" and stops; it should not guess or skip verification.

How to run an onboarding email test

  1. List the emails and their triggers. For each one, write what action sends it and what it should contain.
  2. Prepare a test inbox that can receive several addresses (plus addressing works with many providers).
  3. Sign up as a new user and note the time each email is triggered.
  4. Open each email on desktop and on a phone-width view, and check content, links and rendering.
  5. Click every link and button and confirm where it lands and whether the user is logged in.
  6. Trigger the edge cases: resend, expired link, used link, password reset for an unknown address.
  7. Complete the nudged step and confirm the related reminder email stops.
  8. Report each problem with the email, a screenshot and the exact trigger.

Checklist for each email

Arrival and identity

  • Arrives within a reasonable time, and not in spam (check spam and promotions folders where available).
  • A recognizable sender name and a clear, specific subject.
  • The reply-to address goes somewhere a person actually reads, or is clearly no-reply.

Content

  • The right name, no raw variables like {first_name} or "Hi ,".
  • Matches the product's current name, logo, pricing and features.
  • The main call to action is obvious and says what happens next.

Links and tokens

  • Links and buttons work, go to the right page, and the user stays logged in or is asked to log in sensibly.
  • Verification and reset links work once and expire; an expired or used link explains what to do.
  • Links point to production, not a staging or localhost address.

Rendering

  • Readable on mobile without zooming, buttons large enough to tap.
  • Still makes sense when images are blocked.
  • A plain text version exists for clients that prefer it.
  • Marketing and drip emails have a working unsubscribe link; transactional ones are clearly transactional.

Timing and sequence

For drip sequences, check that the first emails go out when expected and that they stop or change once the user completes the step they are nudging. An email telling an active user to "finish setting up" feels broken. If the sequence spans days, consider a test mode that shortens the delays, so you can check the order and logic in one sitting.

Example bug report

Title: Password reset link points to staging domain
Environment: Gmail web on Chrome 129; also Apple Mail on iPhone-width view
Steps to reproduce:
1. Go to /login and click "Forgot password"
2. Enter the test address [email protected] and submit
3. Open the "Reset your password" email in the test inbox
4. Click "Choose a new password"
Expected: opens app.example.com/reset with a valid token
Actual: opens staging.example.com/reset, which asks for basic auth.
        The real user cannot reset their password.
Severity: Critical (blocks account recovery for every user)
Evidence: screenshot of the email, screenshot of the landing page, link URL

Common mistakes

  • Testing only the content in the email editor's preview, not the email that actually arrives.
  • Reusing the same test address, so "first time only" emails never fire again.
  • Ignoring the mobile view, where most people open these emails.
  • Checking the welcome email but never the reset, invite or resend flows.
  • Forgetting to test what happens after the link is clicked, which is where most breakage hides.

What to fix first

  1. Emails that block access: verification, reset and magic links that are missing, broken or expired too early.
  2. Wrong destinations: links to staging, 404s, or pages that lose the login.
  3. Broken personalization and content: raw variables, wrong names, outdated pricing or features.
  4. Rendering and timing: mobile layout, images off, reminders that fire after the step is done.

Deliverability is a separate job

Testing a flow shows whether emails arrive in your test inbox. Checking authentication records (SPF, DKIM, DMARC) and sender reputation is a deliverability task for your email provider's tools. A clean test inbox does not prove that every real provider will deliver to the primary tab.

Doing it manually vs with an AI beta tester

Checking these emails by hand is simple but tedious, and it tends to happen once at launch and never again. Meanwhile templates get edited, domains change and links break.

An AI beta tester like betatest.ing signs up in a real browser, opens the emails in the test inbox you provide, clicks every link and checks where it lands. Problems are filed with steps, severity and annotated screenshots, and you can schedule the run after each release so a broken reset link shows up the same day. Test logins are encrypted and never shown to the AI.

Honest limits: it only sees the inbox you give it, it can't tell you how real people's spam filters or inbox habits treat your emails, and it can't judge whether your copy actually persuades people to come back. Use it to keep the flow working, and use real engagement data to improve the messages.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Test the onboarding emails of [APP URL]. Use this test inbox for signup: [TEST INBOX]. If you cannot reach that inbox, stop at the "we sent you an email" step and report what you saw; never skip verification or use a real person's address. Sign up as a new user and check each email that arrives (verification, welcome and any onboarding emails within the session, plus a password reset request): how long it takes to arrive and whether it lands in spam, sender name and subject, personalization and raw variables, every link and button and where it lands, that verification and reset links work once and an expired or reused link explains what to do, rendering at mobile width, whether it still makes sense with images off, an unsubscribe link on marketing emails, and whether names, logos and pricing match the product. Log each issue with the email, the exact text or link, steps to reproduce and an annotated screenshot, and end with a short report per email.

Fill in your details

Here, or later in the chat with your tester.

  • [APP URL] Your app or signup page, e.g. https://app.example.com/signup
  • [TEST INBOX] A test mailbox the tester can open, e.g. a shared test inbox address and how to access it

What the AI beta tester checks

  • Arrival time and spam folder placement in the test inbox
  • Sender name, subject and personalization
  • Every link and button and where it lands
  • Verification and reset link expiry and reuse
  • Mobile rendering and images-off fallback
  • Unsubscribe links on marketing emails
  • Consistency with the product name, logo and pricing

What you get

  • A short report per email with what worked and what broke
  • Bugs with steps to reproduce and annotated screenshots
  • A list of broken or misdirected links
  • Suggested fixes for wording and timing

How to run it with betatest.ing

  1. Set up a dedicated test inbox the tester can open
  2. Add your app as a project and paste the task with the inbox details
  3. Send it; the tester signs up and follows each email it receives
  4. Fix the issues, then schedule a repeat after template changes

Tips

  • Keep one test inbox only for testing so results are not mixed with real mail
  • Trigger every transactional email at least once after a template change
  • Check emails at phone width: many users open them there first
  • Use your email provider's tools for SPF, DKIM and DMARC checks

Onboarding email testing: FAQ

Can the AI tester read my emails?

Only the test inbox you give it. Without an inbox it can reach, it stops at the email step and reports the flow up to there.

Can it test a drip sequence over several days?

It can check the emails that arrive during a session, and you can schedule follow-up tests to check later emails in the sequence.

Does this test deliverability?

It shows whether emails reach your test inbox and whether they land in spam there. Authentication records and sender reputation need your email provider's tools.

What is a raw variable?

A placeholder like {first_name} that was not filled in, so the user sees the code or an empty greeting such as "Hi ,".

Do I need a test inbox for onboarding email testing?

Yes, if you want the emails themselves checked. A dedicated test mailbox or a disposable inbox service you trust lets the tester open each email and click its links. Without one, the test can only confirm that the app says an email was sent.

Which onboarding emails should I test first?

Start with the ones that block access: email verification, password reset and magic links. Then test invites and the welcome email, and finally the drip sequence. A broken reset link locks people out, while a typo in day three of a drip only looks careless.

How often should I test onboarding emails?

After any change to templates, email provider, domains or authentication, and ideally on a schedule after each release. Emails break quietly because no error shows up in your app, so a regular check is the only way to notice quickly.

Related beta testing guides

  • Signup flow testing — Signup and onboarding are where most new users decide whether to stay. This page covers what to test in a signup flow, the edge cases teams usually miss, and a test task your AI beta tester can run on your app today.
  • Login testing — Login looks simple until a user is locked out at the worst moment. This page lists what to test in login, logout and password reset flows, the safe limits for testing them, and a ready-to-run task for your AI beta tester.
  • Website copy review — A typo on a pricing page or a confusing button label costs more trust than it should. This page covers what a thorough copy review checks beyond spelling, and a task your AI beta tester can run on every page and flow.
  • SaaS beta testing — In a SaaS product the beta test that matters follows a new customer from signup to the moment they get value and decide to pay. This page explains what to test at each stage, how to set up test accounts and billing test mode, and gives you a task your AI beta tester can run against your app.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in by test type