Illustration: code brackets and an SMTP plug feeding a captured test inbox

Testing Email with SMTP and MCP

There are two ways to make Tempx part of your test suite: point your application at an SMTP sandbox so every message it sends gets captured instead of delivered, or connect an AI agent over MCP so it can watch an inbox, read verification codes and compose test mail on its own. Both paths end in the same place — one disposable inbox that collects everything, shows the original recipients, and never leaks a single real email.

The model: capture, never deliver

Test runs should never send mail to real addresses. Tempx is a capture trap: your app authenticates with a personal test credential, the gateway accepts any recipient (to:, cc:, bcc: — any domain), and the message is stored in the inbox paired with that credential. The original headers are preserved so you can assert exactly what would have been sent, and nothing ever leaves the sandbox.

Both entry points — SMTP for your code, MCP for your agent — capture into one inbox. Nothing is delivered for real.

Path 1: SMTP sandbox for your application

Use this when your code sends the mail: framework mailers, background jobs, integration tests. Create a persistent inbox and an SMTP credential on the account page (the password is shown once), then point your mailer at the gateway:

MAIL_MAILER=smtp
MAIL_HOST=smtp.tempx.uk
MAIL_PORT=587
MAIL_USERNAME=tmtp_x9f3… YOUR_USERNAME
MAIL_PASSWORD=YOUR_PASSWORD
MAIL_ENCRYPTION=tls

Now send to any address — customer@example.com, ops@some-corp.net, a list of them. The gateway answers 250, captures the message, and it appears in the paired inbox within seconds with the original To/Cc intact and Bcc recorded on the envelope. Limits: up to 25 recipients per message, 10 MB per message. Your test assertions read the captured copy; your staging environment never emails a human again.

Path 2: MCP for AI agents and QA bots

Use this when an agent does the work: signing up on a site, completing an email-verification step, or watching a mailbox as part of a longer workflow. Pair from the account page (or the one-command Claude pairing): the connection is scoped to one inbox, carries explicit permissions (read, search, wait, optional send), expires on a date you choose, and can be revoked instantly.

The agent then gets a small toolbox: list_emails, get_email, search_emails, wait_for_email (a server-side long-poll that returns the moment a matching message arrives), and with the send permission send_email — which composes mail to up to 10 recipients and captures it in the same inbox, Mailtrap-style:

tools/call wait_for_email
{ "from_contains": "noreply@saas-app.test",
  "subject_contains": "Verify",
  "timeout_seconds": 60 }

tools/call send_email
{ "to": ["qa@example.com", "lead@example.com"],
  "subject": "Trial started",
  "text": "Welcome aboard — this copy is captured, not delivered." }

Because the token is scoped to one mailbox, a leaked or over-eager agent can never read anything else, and because sending is capture-only it cannot be abused to spam anyone.

A full agent test, end to end

The pattern below is the whole reason the MCP surface exists: an agent that completes a real sign-up flow without a human forwarding codes by hand.

An agent completing an email-verification step over MCP — no human in the loop, no real mailbox involved.

Which path should you use?

	SMTP sandbox	MCP connection
Best for	Your app, framework mailers, CI integration tests	AI agents, QA bots, interactive workflows
Credential	`tmtp_…` username + password	`tmcp_…` scoped token
Recipients	Any domain, up to 25 per message	Any domain, up to 10 per message
Reading mail	Inbox web UI or API	First-class: `wait_for_email` long-poll, search, get
Scope	One inbox per credential	One inbox per token, with permissions + expiry

They compose: run your app against the SMTP credential and let the agent watch the same inbox over MCP when a test needs both sides.

Good practice

One inbox per project or test suite — captured mail from different runs stays separable.
Rotate credentials per environment (staging vs CI); regenerating a password invalidates the old one immediately.
Give agent connections the shortest expiry that works, and the send permission only when the workflow really composes mail.
Never move an account you want to keep onto a disposable address — sandboxes are for flows you are testing, not accounts you depend on.

Set up your test inbox

Create an inbox, mint an SMTP credential, pair an agent — all under a minute.

Open account Try the inbox