The auth email arrived. Did the user finish?

Seeing a message arrive feels like the end of email setup. For the person trying to use your app, it is the middle. The useful result is an account confirmed, a password reset or a session opened at the intended destination.

That distinction matters when hiring help. “SMTP configured” and “the selected user action completed” describe different acceptance criteria. Agree which outcome you are buying before the work begins, and avoid treating one successful message as proof that every authentication flow is covered.

Choose one path and name its finish line

For signup confirmation, the finish line might be a new test account confirming ownership and reaching the app’s expected next page. For password reset, it includes reaching the existing reset form, saving a new password and verifying the expected login behavior. For a magic link, define the intended session and destination. An invitation may include accepting access in an already implemented workflow.

Use a sentence the owner can check: “From this environment, the chosen test account completes this action and reaches this page or state.” Avoid “auth works” as an acceptance criterion. It hides differences between environments, account types, templates and application logic.

Confirm the path exists before configuring mail

Does the app already have the relevant request, callback and completion screen? If the reset link has nowhere to go, sender configuration cannot finish the job. The right next step is an application-work scope, not another SMTP provider.

Supabase documents how Site URL and allowed redirects influence the destination. Check the precise intended URL rather than permitting every preview host to make a test pass. A localhost destination left in a production configuration is a different issue from a frontend handler that receives the link but does nothing useful.

Configuration changes should be written down along with the original value. If the app code supplies its own destination, verify that it agrees with the configured expectation. Do not assume a dashboard value overrides all application behavior.

Use a small, owner-controlled test set

Choose the addresses with the owner and get authorization before sending. Two representative owner-controlled mailboxes can reveal a difference worth investigating, but cannot certify universal delivery. Record which addresses or mailbox types were tested without publishing personal information in a report.

Do not invite real customers into an experiment, repeatedly request resets or create unnecessary accounts to generate evidence. Respect the project’s rate limits and clean up test accounts through the owner’s normal process. A small test is easier to understand when something fails.

Observe the whole chain

Keep five independent fields: sender verification, Auth request outcome, provider event, actual mailbox observation and completed action. A green result in one field does not fill the next field automatically.

When the provider accepted a message but the recipient has not observed it, mark the mailbox field unknown or pending. When the email arrives in spam, record that location. Neither observation should be rewritten as “inbox success” for a tidy report.

Check links without exposing them

Authentication links may carry sensitive, short-lived values. Do not paste them into a public ticket, analytics event, screenshot or shared report. Record the shape of the intended destination and the outcome instead.

Supabase’s template guidance warns that email tracking can rewrite links. Resend also explains how a recipient-side scanner may visit a single-use link before the person does. Those are reasons to inspect the actual path and its settings, not to promise that every expired-link symptom has one cause.

If your chosen flow needs a custom intermediate page or a change to token handling, that is application work. Avoid quietly adding it to a small sender setup. A helper should explain the new requirement and obtain agreement before editing it.

Include one agreed negative case

A useful test plan also states what must not happen. For a link-based path, an already-used or expired link should not silently create a fresh unintended successful session. Choose a safe negative case appropriate to your implementation and evaluate the actual behavior.

This is a bounded functional check, not a security assessment. Unexpected access behavior should stop the acceptance review and be handled by a competent owner. Do not broaden the report into claims about RLS, tenant isolation or the app’s overall security.

Finish with an honest receipt

Your acceptance record should name the path, environment, test date, checked stages, changed settings and known exceptions. Add rollback and recheck instructions. The owner should be able to repeat the meaningful test later without guessing what “done” meant.

If the agreed outcome cannot be reached within scope, say the job is incomplete. A diagnostic handoff may be useful, but it is not interchangeable with a paid package promising completed action. Our service process explains the boundary, and the readiness brief helps define it before payment.