Our recommendation, up front. We make Proxy Mail QA, so we’re not neutral. In this article we recommend it for the part of a sign-up review that happens after the button is pressed: whether the verification email arrives, whether its code or link finishes the sign-up, whether the email is sent and built properly, and whether exactly one arrives. Proxy Mail QA doesn’t judge how your page looks or how well it converts, it can’t receive SMS codes, and it doesn’t test social sign-in such as Sign in with Google.
Ask an AI agent to review a sign-up page and it will usually look at the form: the labels, the fields, the button. That’s the part that rarely breaks. The bugs that reach users are in what happens next:
- The verification link points to
localhost, so it works on your machine and nowhere else. - Nothing arrives, because the email provider is still in sandbox mode.
- Two emails arrive, because the form submits twice or two parts of the code both send one.
- The email says the link lasts 24 hours, and the server expires it after one.
- The link still works after it’s been used, or after a newer one was sent.
None of these show up until a real email lands in a real inbox. This article shows how to let an agent check them on every review.
What the agent checks
| Step | How | What a failure looks like |
|---|---|---|
| The email arrives | wait_for_code or wait_for_link waits up to 30 seconds, ignoring anything older than the sign-up (since) |
Nothing comes. check_delivery says what reached the address and the likely cause, such as a provider in sandbox mode or mail refused for failing DMARC |
| The code or link finishes the sign-up | The agent types the code or opens the link in its own browser, then checks it’s signed in | An error page, an expired link, or a sign-up that doesn’t complete |
| The email is sent properly | check_email: SPF, DKIM and DMARC, links to localhost or plain http, where the link goes (expect_host), a stated expiry, a plain-text part, its size, given phrases and its language |
local_links failed, or the link goes to production from staging |
| Exactly one arrives | count_emails with since |
A count of 2 |
| Used and replaced links stop working | The auth_regression_pack prompt or skill opens a used link again, and an older link after a newer one |
The old link still signs someone in |
Proxy Mail QA never opens links itself, so a single-use link is still unused when the agent gets it. The agent only ever sees the code or link and a few facts about it, never the email’s text.
Connect it in Qoder
- In the Qoder Marketplace, connect Proxy Mail QA from the Connectors tab (global site, China site), or install the plugin for the same tools plus eight skills.
- Sign in to Proxy Mail QA in your browser when Qoder asks, and choose the project the agent may use.
- Set Qoder’s permission level to Ask every time, not Auto approve, and approve each Proxy Mail QA step.
To add it by hand instead, open Qoder IDE Settings → MCP, choose + Add on the My Servers tab, and add:
{
"mcpServers": {
"proxymail-qa": {
"type": "http",
"url": "https://api.proxymail.qa/mcp"
}
}
}
Ask for the review
Review the sign-up at https://staging.acme.dev/signup with Proxy Mail QA. Start a run.
Sign up with a new address (use form_values for the fields), note the time just before
you submit, and finish the verification with the code or link from the email.
Check you're signed in. Run check_email with expect_host: staging.acme.dev, and
count_emails since the sign-up: exactly one email should have come.
Then request a second verification email, and check the first link no longer works.
Finish the run and give me the report, with what to fix first.
The server’s test_signup_flow prompt runs the sign-up, check_email and count_emails steps the same way (not the second verification email), in clients that show MCP prompts. With the plugin installed, the proxymail-qa skill covers a single sign-up, auth-regression-pack repeats sign-up, password reset and invitations the same way every time, and account-email-audit triggers every account email your app sends and lists what to fix.
The report
finish_run returns the session in Markdown: each step, what passed and what failed, with a one-line reason for each check. Paste it into the pull request. When you run auth_regression_pack again later, its report says what changed since the last runs, so a change that broke the reset email shows up as a change, not as a long list to read.
Common findings, and what to change
| Finding | Usual cause | Fix |
|---|---|---|
The link goes to localhost |
The link is built from a hard-coded URL | Build it from an environment variable for the app’s public URL. Fixes for Supabase, Firebase, Auth.js and others |
| Nothing arrives | The email provider only sends to verified addresses | Finish the provider’s production set-up, or verify the sending domain |
| Two emails | The form submits twice, or both your code and your auth service send one | Disable the button while the request runs; send from one place |
| The stated expiry is wrong | The template and the server have different settings | Take both from one setting |
| An old link still works | Tokens aren’t cleared when used or replaced | Make each link single-use, and invalidate older ones when a new one is sent |
To stop these coming back, give the agent a rule, in your project’s rules or at the start of an auth task:
When changing sign-up, login, password reset, invites or any email-sending code:
- Build links from the app's public URL setting, never a hard-coded localhost.
- Keep the expiry stated in an email equal to the one the server enforces.
- Make single-use links and codes stop working once used or replaced.
- Tell me which emails to test by hand after the change.
What it won’t do
- Review the page itself. Layout, wording, accessibility and speed need other tools, or a person. See How to review my sign-up page.
- SMS, authenticator apps and social sign-in. Proxy Mail QA receives email only.
- Create accounts or submit forms. The agent does that, with its own browser tools.
- Work with an email provider in sandbox mode. It can only show you that nothing arrived, and why.
- Test live sites of big consumer services, such as Google, Instagram or Amazon. It’s for apps you build or are allowed to test, on staging or locally.
More detail: testing email verification, the MCP server and Proxy Mail QA for Qoder.