AI Email Testing: Let the Agent Break Your Signup Flow

By Denis · Published 19 Sep 2026. Updated 28 Sep 2026.

Hand-written email tests have a shelf life, and it is shorter than the code they test. You write the happy path (signup, code arrives, code accepted) because it is all you had time to test. Everything your happy path never tried ships to users: the expired code, the resent link that should have invalidated the first one, the verification URL pointing at localhost because someone's environment variable leaked between stages.

An agent with a mailbox can try those things for you. Not "AI writes your tests" (that is a different, noisier claim) but "an agent explores your email flows adversarially, with real addresses and real messages, and reports what breaks". This article is about wiring that up with Tempx and knowing what the agent is good and bad at.

Giving the tester a mailbox

The agent needs two capabilities: receive mail at a real address, and read it programmatically. Tempx's MCP server provides both in one connection, pair once in the browser (Claude Code and friends do this themselves), or mint a scoped tmcp_ token for a custom harness:

claude mcp add --transport http tempx https://tempx.uk/mcp
# the connection is scoped to ONE disposable inbox, read+wait by default

Scoping matters here more than convenience. A testing agent that can only see one throwaway inbox is an experiment; a testing agent with credentials to anything durable is a liability. Tempx connections default to exactly one inbox, expire on their own, and revoke with one click, keep them that way.

Give the agent a fresh inbox per scenario, not one shared box. Interleaved messages from parallel scenarios are the classic source of "my extractor read the wrong code" false alarms, and per-scenario boxes make every failure reproducible by construction.

The scenarios worth asking for

The value is in the awkward states humans forget to script. A short list that reliably finds bugs when handed to an agent with wait_for_email:

Expiry: request a code, wait past its validity window, then submit it. Accepting an expired code is a security bug, and it is invisible until something tries it.
Resend invalidation: request twice in a row, then use the first code or link. If both work, password reset has a double-validity hole.
Duplicate signup: register the same address twice. The polite flows say "you already have an account"; the buggy ones create a second one or leak which emails exist.
Link targets: read the actual URL in the mail, not the link text. Verification links pointing at the wrong host are the classic config bug, and only reading the message catches it.
Text part: check the plain-text alternative exists and isn't a placeholder, text-only clients still exist.
Arrival timing: if your codes expire in five minutes, mail arriving in six is a failed flow even though it "sent successfully".

Phrase these as goals, not scripts ("try to get an expired code accepted and tell me what happened") and let the agent choose the steps. The point of using an agent is the variance; the scenarios aim it.

The outbound half: capture, don't deliver

Email testing has two directions. Everything above is inbound, mail your app sends to the address. For outbound volume (templates, transactional blasts during load tests), don't read inboxes at all: point the app at Tempx's capture gateway over SMTP, or its Resend-compatible adapter, and everything the app sends is captured, never delivered.

Capture-only is what makes aggressive agent-driven testing responsible. A scenario that "signs up forty times and requests resets under load" is fine when the mails land in a sandbox; the same scenario against real delivery would be a mail incident. Tempx's gateway never relays, there is no configuration in which it becomes one.

The agent can close the loop on the outbound side too: the MCP send_email tool (with the send permission) captures a composed message in the same inbox, so "what did our reset template render" is a read, not a guess.

What the agent is bad at

Rendering judgement. An agent reading sanitized HTML can tell you the link host and the code format; it cannot meaningfully tell you how the template looks in Outlook or Gmail dark mode. For visual questions, humans and screenshot tooling stay in the loop, the MIME decoder and header analyzer cover the structural half.

Deterministic regression. A check that becomes a requirement should graduate from "the agent tries this" into a scripted test, deterministic, versioned, runnable in CI on every commit. The agent's role is finding the checks worth graduating; the Playwright guide shows where those landed for the framework crowd. Keep the two layers separate and each stays cheap.

And judgment about significance: an agent will report forty findings with equal confidence, of which three matter. Triaging is still your job, which is also why the reports should be specific ("expired code accepted on the login fallback path") rather than verdicts ("email flow seems broken").

The report format that turns findings into fixes

An evening of agent-driven testing produces its value in the report, and the format decides whether anyone acts on it. The format that works: one finding per item, each with the scenario in a sentence ("expired code accepted on the login fallback path"), the evidence that makes it checkable (the inbox address, the subject matched, what arrived and when), and a severity that reflects user impact rather than the agent's enthusiasm. Findings without evidence get re-run, not filed; verdicts without specifics ("email flow seems broken") get rewritten before they waste a triager's morning.

Keep the successes in the report too ("requested reset twice, first link correctly rejected" is a real result) because a report of only failures hides which scenarios were covered. The document you want at the end is a coverage map with wounds marked on it, not a list of wounds.

One evening, end to end

The worked shape of a first session, so the pattern is concrete. Pair the agent with a fresh inbox and read-only-plus-send permissions. Ask for the happy path first (signup, code, confirm) to establish the baseline. Then name the edges one at a time: expired code, reused reset link, duplicate signup, wrong-host link, text-part presence, arrival timing. After each, ask for the evidence. At the end, collect the findings into the report format above, and pick the one or two that merit graduation into scripted CI tests.

Second sessions get shorter: the agent remembers nothing between runs, but the prompt that worked is reusable, and each graduated scenario leaves the agent free to explore new edges next time. Over a few weeks the pattern converges, the agent hunts, the suite guards, and the email flows stop breaking in production because they broke in the sandbox first.

Drafted with AI assistance and reviewed against Tempx's editorial rules (no invented statistics, no competitor claims).

Create a temporary email address

Free, instant, no sign-up, messages auto-delete.

Go to your inbox