An email address for checking my sign-in form

Our recommendation, up front. We make Proxy Mail QA, so we’re not neutral. For testing a sign-in (log-in) form, we recommend it for test accounts whose email you can read: each has its password saved with it, sign-in codes and magic links arrive in a real inbox, and the password-reset email can be followed all the way through. It doesn’t test social sign-in (Google, Apple, Microsoft), SMS codes, authenticator apps or passkeys, and it doesn’t fill in or submit the form for an AI agent or a test: they do that.

What a sign-in form test covers

1. The right email and password sign in.
2. A wrong password gets a clear message that doesn’t say whether the email has an account. An email with no account gets the same message.
3. The email typed in capitals, or with a space at the end, signs in to the same account.
4. A sign-in code or magic link arrives, works once, and stops working when it expires or a newer one is sent.
5. Forgot password sends an email whose link works once. Afterwards the old password fails and the new one works.
6. After too many wrong passwords, the account is locked or slowed down, and any unlock email arrives.
7. Password managers fill the form: the fields have autocomplete="username" (or email) and autocomplete="current-password".
8. After signing in, the person lands where they were going, not always on the home page.

Test accounts you can sign in as again

• Make one with a saved password. In the API or from an agent, create an address with a password (password: true). In the app, use Generate a test password on the address and save it. With Proxy Mail QA for Chrome, sign up as usual: after you submit, it asks whether to save the password you used to that test address. Saved passwords are encrypted, and every time one is read it’s logged.
• Sign in as it again, by hand. On a sign-in form, the extension’s button offers your project’s test accounts, the ones used on that site first, and fills the email and its saved password.
• Sign in as it again, from an agent or a test. get_sign_in (MCP) or signInAccount (npm) returns the account used on that site and its password in one call. Both need an API key created with Can read saved passwords, and every read is logged. An agent connected through the Qoder Marketplace signs in to Proxy Mail QA with your browser instead of a key, and can’t read passwords saved earlier: it uses the password of an account it made in the same session, or you connect it with such a key (MCP server setup).
• After the password changes, save the new one with set_password (MCP) or setPassword (npm), so the next test signs in with the right one.
• When tests run in parallel, borrow accounts from the account pool: check_out_account gives a test an account in a known state (by tags such as verified, or by age, country or having a saved password) that no other test has until it’s returned.

import { ProxyMailQA } from 'proxymail-qa';

const qa = new ProxyMailQA(); // a key with "Can read saved passwords", in PROXYMAIL_QA_API_KEY

await qa.withAccount({ tags: ['verified'] }, async (account) => {
  const { secret } = await qa.savedPassword(account.address);
  await signIn(page, account.address, secret); // your own sign-in steps
});

Sign-in codes and magic links

For a form that emails a code or link instead of asking for a password:

• wait_for_code waits up to 30 seconds and returns the code; unused: true skips one already used, so a second request gets the second code.
• wait_for_link returns the magic sign-in link. Proxy Mail QA never opens it, so it’s still unused when you get it.
• check_email checks the email: SPF, DKIM and DMARC, that the link goes to the site you’re testing (expect_host), and whether it says when the code stops working.

The server’s test_sign_in_code prompt borrows a verified account and signs in with the code or link the app emails. More in testing one-time codes and testing magic links.

Capitals and plus tags

get_address_variants gives versions of a test address that still reach its inbox. Two matter at sign-in:

• Capitals (K7F2X9AB12CD@MAILCLUB.DEV). Signing in with them should reach the same account as the plain address. If it fails, people who type their email with a capital letter can’t sign in.
• A plus tag (k7f2x9ab12cd+work@mailclub.dev). To most apps that’s a different account. Decide whether yours treats it as the same one, and test that it does what you decided.

Password reset

The test_password_reset prompt borrows a verified account, resets its password through your app, checks the reset email, saves the new password on the account and returns it to the pool. Then check the old password no longer signs in. More in testing password resets.

Ask your agent

With Proxy Mail QA connected in Qoder (Marketplace):

Test the sign-in form at https://staging.acme.dev/login with Proxy Mail QA. Start a run.
Create a test address with a password (create_address, password: true), sign up with it
at https://staging.acme.dev/signup and finish the verification. Sign out.
Sign in with it. Then try a wrong password, an email with no account, and the address
in capitals, and compare the messages.
Use "Forgot password", finish the reset with the link from the email, save the new
password with set_password, and check the old one fails.
Finish the run and give me the report.

The agent keeps the password from create_address for the session, so this works with the Marketplace connection, which can’t read passwords saved earlier.

What it doesn’t cover

• Social sign-in. Sign in with Google, Apple or Microsoft uses accounts at those services, which Proxy Mail QA doesn’t make. Use each provider’s test accounts.
• SMS codes, authenticator apps and passkeys. It receives email only.
• Rate limits and lockouts at scale. You can check that a lockout email arrives, but load testing needs a load-testing tool.
• Your live site. It’s for staging or local copies of apps you build or are allowed to test.