Our recommendation, up front. We make Proxy Mail QA, so we’re not neutral. In this article we recommend it for one job: giving an AI agent real test inboxes and ready-made test values, so it can check every field of your registration page and finish the registration through the email. Proxy Mail QA doesn’t review your page’s design, wording, accessibility, speed or security, and it doesn’t fill in or submit the form: the agent does that with its own browser tools. For the rest, see What it won’t catch.
An AI coding agent, such as the one in Qoder, can open your registration page, read its fields and try values in them. Two things usually stop it from doing a proper review:
- It has no inbox. The page says “Check your email”, and the review ends there. Nobody finds out whether the email arrives or the link works.
- It tries the same few values.
test@example.com,John SmithandPassword123!pass on almost every form. The names and passwords real people type are the ones that break it.
This article covers what a field-by-field review should check, and how to give the agent what it needs to check it.
What a field-by-field review checks
| Field | What to try | What should happen |
|---|---|---|
Capitals, a plus tag, an apostrophe (o'brien), the 64-character maximum; and invalid ones, such as two @ signs |
Valid ones are accepted and the email arrives. Invalid ones are refused before anything is sent | |
| Names | O'Brien, Smith-Jones, José, 李, محمد, one letter, exactly the field’s maximum and one over |
Real names are accepted as typed. One over the maximum is refused with a clear message |
| Names, as code | <b>Jane</b>, <script>alert(1)</script> |
Stored and shown as plain text, never run |
| Password | Exactly the minimum, exactly the maximum, one under, one over, each kind of symbol, a space inside | In-rule passwords are accepted and sign in afterwards. Out-of-rule ones are refused, at the field, with the rule |
| Date of birth | An adult, someone under 18, someone who turns 18 tomorrow | Your age rule applies on the right day |
| Country | Each country your rules treat differently | The right terms, content or refusal |
| Confirm fields | A confirm email or password that doesn’t match | An error at the field |
| The whole form | Submitting twice; an address that’s already registered | One account and one email. Wording that doesn’t confirm whether someone has an account, if that matters for your app |
What Proxy Mail QA gives the agent
- A real test address for each run. The verification email lands in a private, receive-only inbox. The agent waits for it with
wait_for_codeorwait_for_linkand gets back only the code or link, never the email’s text, so it can finish the registration instead of stopping at “Check your email”. - Values that fit each field.
form_valuestakes what the page says about each field (its type, label, name, placeholder, autocomplete, pattern, minimum and maximum length, and a drop-down’s options) and returns what to type or pick: the email, names, a username, a password that fits the field’s rules, a date of birth in the field’s format and a country the drop-down offers. A field it doesn’t recognise, such as a terms box, comes back empty with a note, and the agent decides what to do with it. - Awkward values, grouped by what should happen.
get_name_variantsreturns values in four groups:accept,reject,store_as_textanddecide(apps reasonably differ, so note what yours did).get_password_variantsuses the same groups, withoutstore_as_text.get_address_variantsgroups addresses asdelivered(the mail still reaches the inbox),undeliverableandinvalid. Pass the field’s maximum length, and the password’s minimum and maximum, so the edges match your form. - Accounts of an exact age or country.
create_addresstakes anage(under13,under15,under18,turns18tomorrow,turned18today,adult,over21) and acountry(such asGBorDE), and the test persona’s date of birth and country match. - A report.
start_runandfinish_runrecord the session and return it as Markdown, ready to paste into a pull request.
To try many names or passwords without making an address for each, give each attempt its own plus tag: k7f2x9ab12cd+name1@mailclub.dev, +name2 and so on. To your app each is a new account, and the mail still arrives in the one inbox. If your app refuses plus tags, that’s a finding in itself.
Connect it in Qoder
- In the Qoder Marketplace, open Proxy Mail QA in the Connectors tab (global site, China site) and connect it. Or install the Proxy Mail QA plugin, which adds the same tools and eight skills.
- Sign in to Proxy Mail QA in your browser when Qoder asks, and choose the project the agent may use. A free account is enough.
- Set Qoder’s permission level to Ask every time, not Auto approve, and approve each Proxy Mail QA step when asked.
Two of the plugin’s skills fit this review: signup-form-email-validation (addresses, names and passwords) and age-and-region-testing (age gates and country rules).
Ask for the review
Review the registration page at https://staging.acme.dev/register with Proxy Mail QA.
Start a run. Use form_values for the fields, register once and finish the verification
with the code or link from the email.
Then try the values from get_address_variants, get_name_variants (with each name field's
maximum length) and get_password_variants (with the password field's minimum and maximum)
in their fields. Use a plus tag on the address for each new attempt.
Make one account with age under18 and one with age turns18tomorrow, and check what the
form does with each.
Finish the run and give me a table: field, value, what it tests, what the app did, and
what to fix.
The agent types the values and presses the buttons. Proxy Mail QA never presses anything on your page.
Reading the results
acceptvalues (anddeliveredaddresses) that were refused are the bugs real people hit: a form that refusesO'Brienor a plus tag turns away real customers.rejectvalues (andinvalidaddresses) that were accepted mean the field’s limit isn’t enforced. Check whether the server enforces it, not only the page.store_as_textvalues that changed the page (bold text, an alert) need fixing before anything else.decidevalues have no right answer. Agree what your app should do, then keep it that way.- For passwords that were accepted, sign in with them. A password that’s trimmed or cut short on the way in won’t sign in as typed.
What it won’t catch
- Design and wording. The agent can comment on labels and copy, but Proxy Mail QA adds nothing there. Look at the page yourself, on a phone as well.
- Accessibility. Use axe DevTools, WAVE or Lighthouse, and try the form with a screen reader and the keyboard alone.
- Speed. Use Lighthouse or PageSpeed Insights.
- Security. Checking that HTML and SQL are stored as text is a useful sign, not a security test. Use a scanner or a penetration test for that.
- SMS codes, CAPTCHAs and social sign-in. Proxy Mail QA is email only. Turn CAPTCHAs off on staging or use your provider’s test keys.
- Fields only your app has, such as company size or “How did you hear about us?”.
form_valuesleaves them empty, so the agent fills these itself, from what the page shows.
Before you start
- Review a staging or local copy of an app you build or are allowed to test. Each accepted value makes a real account in your app, so delete them afterwards.
- Your email provider has to be able to send to any address. In sandbox or test mode (Amazon SES before production access, Resend without a verified domain, a Mailgun sandbox, Postmark before approval, or Supabase’s built-in email) it only sends to addresses you’ve verified, so nothing arrives.
check_deliverytells the agent when that’s the likely cause. - Proxy Mail QA doesn’t work with a few big consumer services, such as Google, Instagram, TikTok, Amazon and PayPal. It’s for testing your own app.
More detail: unusual addresses, unusual names and passwords and the MCP server.