How do I test email without sending it to a real inbox?

Point your application's mail at the capture-only SMTP gateway (smtp.tempx.uk:587) — every message lands in your paired Tempx inbox instead of being delivered. For receiving tests, any address at tempx.uk works with no setup: send to it through the gateway or any provider, then inspect the inbox in the web app, a browser extension, or over MCP.

Is Tempx free for developers?

Yes. Disposable inboxes, the SMTP capture gateway, the Resend-compatible endpoint and the MCP server are all free. The gateway and MCP authenticate with credentials minted from your account page; the web inbox and browser extensions work without any account.

Can my test suite create inboxes programmatically?

Named inboxes need zero setup — choose a fresh random name per run and it exists on first use. Private token-gated inboxes can be created in the browser or from your account; anonymous programmatic creation is protected by a Cloudflare Turnstile challenge, so it is meant for humans, not scripts.

Does Tempx ever deliver mail to real people?

No. Tempx is receive-only for the outside world, and the SMTP gateway is capture-only: it accepts mail for any recipient domain and stores it in your inbox. A test run can never email a real person.

Tempx for Developers

Test emails from your application or AI agent. Tempx is a free email testing toolkit: send mail through the capture-only SMTP gateway, watch it land in a working inbox, and inspect it — nothing ever reaches a real person. For AI coding agents and automated workflows, connect through MCP. Every surface is free to start.

app sends via SMTPTempx capturesinbox shows itassert / verify

# 1. Mint an SMTP credential for your inbox at tempx.uk/account
# 2. Send through the capture-only gateway - nothing reaches a real person:
swaks --to anything@yourapp.test --server smtp.tempx.uk:587 \
      --auth LOGIN --au "$TEMPX_SMTP_USER" --ap "$TEMPX_SMTP_PASSWORD" \
      --header "Subject: signup verification test"
# 3. Inspect the captured mail: web inbox, browser extension, or MCP wait_for_email

The surfaces

Capture-only SMTP gateway. smtp.tempx.uk:587 (STARTTLS) authenticates with tmtp_ credentials from your account and accepts mail for any recipient domain — then stores it in the paired inbox instead of delivering. Mailtrap-style sandboxing with zero configuration in the app under test. This is the primary integration for applications.
MCP server for agents. https://tempx.uk/mcp exposes list/search/read tools plus wait_for_email, a blocking long-poll built for verification codes. Pairing is one browser approval. The primary integration for AI agents. See the MCP integration.
Resend-compatible endpoint. Using the Resend SDK? Set its base URL to https://tempx.uk/resend and your Tempx connection token as the API key; resend.emails.send() is captured instead of transmitted. See the Resend integration.
Web inbox and browser extensions. Inspect captured mail anywhere: the app at tempx.uk/mail, or the Chrome and Firefox extensions that put the inbox in your toolbar.

How mail is read programmatically: the web app and the extensions read inboxes through Tempx's internal product API, which is reserved for first-party clients. Your integration path is SMTP in, MCP out — and for scripts you own, a private inbox authenticates its reads with a Bearer token.

Choosing a surface

Surface	Auth	Best for
SMTP gateway	`tmtp_` user + password (or an API key)	Framework mailers, staging apps, CI
MCP server	OAuth pairing or `tmcp_`	AI agents, prompt-driven testing, `wait_for_email`
Resend adapter	`tmcp_` token (send)	Apps already using the Resend SDK
Private inbox + token	Bearer token	Scripts you own reading raw JSON; keeping test mail away from public names
Web inbox / extensions	none	Humans watching a test run

Every auth mode and rate limit is catalogued in the developer documentation — generated from the same registry as the machine-readable llms.txt overview, so it cannot drift from the product.

Fresh inbox per run, zero cleanup

Named inboxes exist from the moment mail is sent to them, so a test suite can derive a unique address per run — ci-signup-8f3a1@tempx.uk — and never collide with a parallel job. Mail to any unused name is accepted by our MX and waits for its first reader. Inboxes and their contents are deleted automatically (named inboxes keep mail up to 7 days), so there is nothing to tear down in your pipeline.

Two design limits worth knowing up front: programmatic anonymous mailbox creation is Turnstile-gated — tests should derive names, not create inboxes — and the internal REST surface that powers the web app and extensions is not part of the developer contract. Your integration path is SMTP in, MCP out.

Start in three steps

Pick an address for your test run — any name at tempx.uk works, no sign-up.
Send mail to it: point your app's SMTP at the capture gateway, or just send from any real provider — our MX accepts it.
Inspect the captured message — in the web inbox, via a browser extension, or with wait_for_email over MCP — and assert on subject, sender or the code inside.

Open an inbox and send it something

The mail app is live at tempx.uk/mail — point the gateway at it and watch the capture land.

Open the inbox