Tempx.

How to Test Email Automation with n8n

By Denis · Published 2026-09-15.

n8n workflows that touch email have two halves to trust: the ones that read mail as a trigger, and the ones that send it as an action. Tempx gives you a real inbox and a capture-only mail server so both halves can be tested without touching a real recipient.

Side one: reacting to incoming mail

The watcher is five nodes: Schedule Trigger (every minute) → HTTP Request to GET https://tempx.uk/api/inbox?address=… → Split Out on messages → Filter on subject/sender → your action. Node-by-node settings are in the integration guide; the parts that make it production-shaped:

Side two: testing the mail your workflow sends

Workflows that notify people are scary to test, point them at real users and you spam; point them at a fake address and you test nothing. The capture-only SMTP gateway resolves it: create an n8n SMTP credential with host smtp.tempx.uk, port 587, your tmtp_ username/password, and every message the workflow "sends" is stored in the paired inbox with recipients preserved, nothing delivered, everything inspectable.

# then the assertion is a one-liner against the same inbox
curl -s "https://tempx.uk/api/inbox?address=alerts-7cq2@tempx.uk" \
 | jq -e '.messages[] | select(.subject | test("Invoice"))'

The end-to-end test loop

  1. Seed: send a test message into the watched inbox, by hand, from your app via the gateway, or with a one-off HTTP node.
  2. Run: trigger the workflow (or wait one schedule tick).
  3. Assert: check the workflow's output (Slack message, app record) and, for send-side steps, that the captured mail carries the right subject, recipients and content.
  4. Regression: keep the seed-and-assert pair as a scheduled canary, a workflow that silently stops matching its filter is worse than one that fails loudly.

Limits worth designing around

The watcher, node by node

For copy-paste convenience, the five-node watcher with its key fields spelled out, the shape that has survived real production use:

Two silent-failure traps: writing the watermark before the action succeeds means a failed run skips mail permanently (write it after, or key on idempotency); and a Filter that drops everything is indistinguishable from a working workflow, add a monthly "I am alive" check or a heartbeat message so silence is never ambiguous.

Testing the failure paths

A watcher that works when mail arrives is half-tested. The paths worth rehearsing: empty inbox (the Split Out receives zero items, confirm your workflow tolerates that rather than erroring); duplicate delivery (send the same message twice and verify the idempotency key prevents the double Slack ping); malformed or unexpected mail (a message with no match for your filter is fine, but one with a broken subject encoding should not crash the parse); and gateway auth failure (rotate the tmtp_ password in a dev copy of the credential and check the send step surfaces the 535 rather than swallowing it).

Each of those is a two-minute rehearsal with a disposable inbox: seed the failure condition by hand, run the workflow once, watch where it goes. The alternative is discovering the behavior during a real incident, which is a worse meeting.

Environment hygiene: dev, prod, and the credential wall

Keep the test mail path structurally separate from the real one. In practice: n8n credentials named for their environment (Tempx SMTP, dev versus the production sender), workflows exported with credentials unset, and the capture gateway as the only SMTP host any dev workflow may reference. The property that makes this relaxing is the gateway's design: it never relays, so a dev workflow pointed at it with any credential confusion still cannot email a customer. The wall is architectural, not disciplinary.

Between test sweeps, reset what the workflow remembers: static data (the watermark) belongs to the test run, not the workflow's identity, and a stale watermark from last week's rehearsal is the classic reason a "fresh" test processes nothing. Export the workflow as your artifact, treat static data as disposable state, and the difference between a demo and a test disappears.

Why a JSON inbox beats IMAP inside n8n

Teams arriving from IMAP-shaped tooling sometimes ask where the IMAP node fits: it does not need to. Reading a JSON endpoint over HTTP Request is stateless, needs no long-lived connection, plays perfectly with n8n's execution model (short-lived runs, static data for continuity), and returns already-parsed fields, no attachment decoding, no flag management, no idle timeouts. The IMAP version of the same watcher is more nodes, more failure modes, and a connection your platform holds open between executions for no benefit.

The same reasoning picks the read cadence: a minute-level schedule with a watermark is idiomatic n8n and comfortably within the inbox API's limits. Sub-minute polling buys you nothing (email was never that fast) and costs you headroom you may want for the send-side assertions later.

The one-screen smoke sweep

Before trusting any of this in production, a five-minute sweep that exercises every moving part: seed the watched inbox with one hand-sent mail and confirm the workflow acts on it; send a duplicate and confirm idempotency holds; point a scratch workflow's SMTP credential at the capture gateway and confirm the sent message appears in the paired inbox with recipients intact; then rotate that credential and confirm the next send fails loudly rather than silently. Four checks, one screen, and every failure mode that bites in production (missed triggers, double actions, silent capture, dead credentials) has been seen once in daylight.

Keep the sweep as a scratch workflow you can clone after any n8n upgrade or credential change; re-running it costs the five minutes, and it catches the class of breakage that version bumps cause quietly (node behavior changes, credential format drift) before a real alert does.

Create a temporary email address

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

Go to your inbox