What breaks
Confirmation email not sending: find the cause
New users sign up, see a screen that says check your inbox, and no email comes. This page shows how to tell a sandbox limit, a suppressed address and a broken link apart, and what a simulated visitor can confirm.
Why is my confirmation email not sending?
A confirmation email usually fails inside the mail service, not inside the signup form, and the screen tells the new user to check their inbox either way. The mail service's send log shows whether each message was sent, refused, bounced or suppressed, and the result for a new address often differs from the result for your own. A simulated visitor signs up with its own working inbox, and the run reports whether the confirmation arrived and whether its link opens.
What this looks like in a report
“The screen said check your inbox to confirm. My inbox had new messages, but none from them. I checked spam, then tried again with a different address and got the same screen.”
The fix. Send the confirmation from a verified sender address on your own domain, and show 'We could not send your email, so try again or contact us' when the send call fails. Then sign up from two new addresses at different mail providers and confirm both messages arrive and open.
An illustration. Run a test to see your own.See a real sample report
The app waits for a code that never comes
A new user signs up, sees a screen asking them to check their inbox, and waits. Nothing arrives, or it arrives after they have given up. The owner's own signup often works, because the owner's address was verified or has received mail before. A stranger's address does not, and the app shows the same reassuring screen either way. The confirmation can fail in the mail service, in a sending domain that was never verified, in a suppression list left over from earlier bounces, or in a send call the app never checked.
- Does a confirmation reach your own address but not a new address you have never used?
- Does the send log show the message as sent, refused, bounced or suppressed?
- Does the sender address use a domain the mail service has marked as verified?
- Does the app's server log show an error from the send call, even though the screen said check your inbox?
- Does the link in the message point to your live address, not a test or local address?
A mail account in sandbox mode sends only to addresses you verified
Some email services start a new account in a sandbox that delivers only to addresses the account owner verified first. Your own address works because you verified it, and the team's addresses may work for the same reason. A brand new user's address is not on that list, so the service refuses the send, and the error may never reach the screen. The send log can show a success for your own inbox and a refusal, or no record at all, for everyone else. It is easy to miss, because your own test still passes. To see which case you have, send the test from a new address and compare its row in the send log with yours.
To check, sign up with an address you have never verified and read the app's server log for an error from the send call. Then open the mail service's account status, which states whether the account is in sandbox mode. Leaving sandbox mode usually takes a request to the service, so start it before launch, not after. Until then, only addresses you verified receive mail.
A suppressed address gets no email, even when the send call works
Mail services keep a list of addresses they have stopped sending to, usually after a bounce, a complaint or an unsubscribe. Once an address is on that list, later sends to it are skipped, and the app's call may still report success. A user who signed up earlier with a mistyped address, or who once marked a message as spam, can come back and never receive a confirmation. The send log shows that address as suppressed, with no attempt to deliver.
Check the suppression list before you change any code. Remove an address only when its owner asks for it, or when the bounce was a typing error you can fix with the user. A visitor with a fresh working inbox can show whether a new confirmation arrives for a clean address, which tells you whether the list is the cause.
The message arrives, but the link inside points at the wrong address
Sometimes the email arrives and the fault is in the link. A template that builds the link from a setting can carry a staging host, a local address or an old domain, so the user taps a button that opens a page nobody can reach. The shopper blames the email, not the template. A run shows whether the message arrived and where its link leads, which separates this case from the ones where nothing arrives.
Read the host in the link before you test the flow again. A link that starts with localhost, a staging name or a preview address was built from the wrong base setting, and that setting usually lives in the mail template or an environment variable. Preview deploys are a common source, because each one has its own address. Fix the setting, then send one message to a fresh address.
What you get with Mimiq
- 01
Run it by hand, or on every pull request
Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.
- 02
Bugs and usability problems in one report
The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.
- 03
Visitors that behave like your audience
Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.
- 04
A prompt to fix each problem
Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.
- 05
Follow every visitor
See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.
The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.
A new mail provider or sending domain can cut off confirmations again
A changed sending domain, a rotated API key or a move to a second mail service can stop confirmations again while the signup screen looks normal. Rerun a signup from a new address after each change to the mail setup, and read the send log, not only the screen. With paid credits, visitors can open a protected preview, so each deploy gets the same signup check.
Starter
Try it on one launch
About 4 tests of 5 visitors
- Visitors on your landing page, signup and checkout
- Where they left and why, with a fix to copy for each problem
- Run it in the app or on every pull request
- Ask any visitor a question, included
- Test accounts and protected previews
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Can the test show that my confirmation lands in the inbox and not the spam folder?
It shows whether the confirmation reached the visitor's working inbox, and whether its link opens. It cannot tell you how other providers filter your domain for a different address, and it does not predict how many new users will confirm. Check spam placement with a few real mailboxes at different providers after each change.
Why does my own signup get the email while new users do not?
Your address is usually verified with the mail service, on an allow list, or has received mail before, so the service delivers to it. A new user's address may be none of those things. Sign up with an address you have never used, and read the send log for that address alone.
Should the app let users in before they confirm?
That is a product decision, and it changes the risk. Letting a user in before the confirmation arrives means a failed email does not lock them out, but it also lets a mistyped address into the product. If you keep the gate, put a resend button and a way to change the address on the same screen.
Does the test confirm the account is saved correctly?
It can open the link or enter the code from the visitor's inbox, and report whether the app accepted it. It cannot tell you how your database stores the account afterward, so check that record yourself after each run.
Keep reading
Send visitors and see what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.