What is email testing?

Almost every application sends email: a signup confirmation, a one-time passcode, a password-reset link, a receipt, a nightly digest. That mail is part of your product’s critical path — if the reset link is broken or the OTP never arrives, the user is stuck at your front door. Yet outbound email is famously easy to ship without ever looking at. It leaves your servers and lands in someone else’s inbox, out of view of your test suite.

Email testing is how you close that gap. Instead of assuming the message went out fine, you send it to an inbox you control and inspect exactly what arrived — the subject and body a real recipient sees, the rendered HTML, the working links, and the headers that reveal how it authenticated. It is a quality-assurance discipline aimed squarely at the mail your product emits, not at reading other people’s mail.

What developers actually test

“Email testing” covers several distinct message types, each with its own failure modes. The common ones:

• OTP & 2FA codes — that a one-time passcode is generated, arrives fast, and matches what your verification step expects. See testing OTP & 2FA email.
• Password resets — that the reset link is well-formed, points at the right environment, and its token still works when clicked. See password-reset testing.
• Verification & confirmation email — signup confirmations and address-verification flows that a new account depends on to proceed.
• Transactional receipts — order confirmations, invoices, and notifications where the numbers, dates, and copy have to be exactly right.
• Delayed, cron & digest mail — scheduled sends where the hard part is confirming the job fired at all, and hours later. See testing delayed & cron email.
• Template rendering — that the HTML body renders the way you intend, with variables filled in and no broken markup.
• Authentication (SPF, DKIM, DMARC) — that a receiving server can verify the message really came from your domain, so it lands in the inbox rather than spam. See SPF, DKIM & DMARC explained.

Manual vs. automated testing

There are two broad ways to test email, and most teams use both.

Manual (interactive) testing means a developer or QA engineer triggers the flow by hand — signs up, requests a reset, places a test order — and then opens the resulting message in a real inbox to look at it. It is the fastest way to answer “does this actually work and look right?”, and it is where most email bugs are first caught: a wrong link, a missing code, a template that renders as raw HTML. You see precisely what a recipient would see.

Automated testing wires email assertions into a test suite or CI pipeline: a script triggers the send, then programmatically fetches the message via an API and asserts on its contents — the code matches, the link resolves, the subject is correct — with no human in the loop. That is the right tool for regression coverage and end-to-end flows you want to guard on every commit. Dedicated services in this space, such as Mailosaur, are built around that API-driven, CI-first model.

Neither replaces the other. Automated checks stop regressions; manual inspection is how you understand a new flow, debug a weird delivery, and confirm the thing genuinely renders and behaves for a real person.

Where Perenmail fits

Perenmail is built for the manual side: it gives developers private, registered-only inboxes on real domains that you point your own application’s mail at, then inspect what arrives. You create an address, use it as the recipient in your signup, OTP, password-reset, or transactional flow, and read the message the moment it lands.

A few things make that inspection loop fast:

• Persistent by default — inboxes never expire on their own. They stay until you deliberately archive or delete them, so the address you wired into a staging config keeps working next week and next month.
• Live delivery — a listening indicator and poll heartbeat surface new mail at the top the instant it arrives, with no reload; unread state updates in place.
• One-tap OTP & link capture — verification codes and every link in a message are extracted for you, so you can copy the code or open the link in a single click.
• Safe rendering — HTML bodies render in a locked, script-free sandboxed iframe, and you can toggle between Rendered, Text, and Source.
• Raw source, headers & auth results — the full RFC822 view with synthesized SPF, DKIM and DMARC results, for debugging your own outbound. (Raw source, headers and attachments are part of Personal+.)

Because addresses are private and tied to a signed-in account — not a public, browsable stream — the mail you test stays yours. You can group inboxes into projects, label them with markers, and search across everything. Ready to try a flow end-to-end? Our guide to testing email in staging walks through wiring a private address into a non-production environment.