PureTempMail

Temporary Email for Testing: How Developers and QA Teams Check Sign-Up Flows

A manual test run, a 12-point checklist and the real limits of a public temp inbox for QA, plus the tools to use when the test needs automation or secrets.

PureTempMail Team

The engineers who build and run PureTempMail

Short answer

A temporary email address is a quick way to check a sign-up flow by hand: verification, password reset and welcome emails arrive in a real inbox on the public internet, in seconds, without touching anyone's personal mailbox. For automated tests, real customer data or anything carrying secrets, use a local mail catcher or a testing sandbox instead.

Every product that sends email needs someone to sign up, again and again, with a fresh address. Developers reach for their own Gmail with a plus tag, QA testers keep a spreadsheet of throwaway accounts, and product managers borrow a colleague's inbox. A temporary email address for testing is faster than any of those for one job: seeing exactly what a new user receives from your production or staging mail setup.

We run PureTempMail's mail servers, so the limits below are our real settings rather than guesses. This guide covers where a public temp inbox fits in a test plan, a manual run you can do in five minutes, the checklist we would use on our own sign-up emails, and the cases where you should use a different tool.

Where a temp inbox fits among your testing options

There are five common ways to give a test account an address. Most teams end up using two or three of them at different stages of the same release.

Email testing options compared by what they are good at and where they fall short
OptionBest forReal delivery over the internetAutomationWatch out for
Public temp inbox (such as PureTempMail)Manual checks of staging or production email, exploratory testing, demosYesNone on our side: you watch the inbox in a browserAnyone who learns the address can read the mail, and it expires after an hour unless extended
Local SMTP catcher (such as Mailpit)Development machines and CI, where the app sends to a fake SMTP serverNo: mail never leaves your machine or networkYes, through its HTTP APISays nothing about DNS, SPF, DKIM or how real providers treat your mail
Hosted testing sandbox (such as Mailtrap or Mailosaur)Staging environments and end-to-end test suitesDepends on the product: captured over SMTP, or received on the vendor's test domainYes, with SDKs for common languagesPaid plans for serious volume, and another vendor holding your test data
Plus addressing on a team mailboxLong-lived test accounts you need to log back into next monthYesOnly through that mail provider's APIMany sign-up forms reject the plus sign, and every test lands in one shared inbox
Your own catch-all test domainLarge numbers of durable test accounts under your controlYesYes, if you read the mailbox through IMAP or an APIDNS and mail hosting to set up and maintain

A temp inbox earns its place in one gap the others leave: a real message, sent by your real mail provider, landing on a domain you do not control, viewed in a browser in seconds. That is the closest you get to what a new customer sees, without creating yet another account somewhere.

A manual test run with PureTempMail

This is the run we suggest for checking a sign-up flow by hand. It takes about five minutes per pass.

  1. Open a fresh mailbox for each test user

    Open PureTempMail in a separate browser window. A new address is created on load. The mailbox is remembered per browser, so press New for each test user, or use a private window when two testers share a machine.

  2. Record the address next to the test case

    Paste the address into your test case or ticket before you use it. If a tester asks later why the reset email never came, you need to know which mailbox it went to.

  3. Run the sign-up and trigger every email you can

    Complete the form, then request the emails a new user can cause in their first session: resend verification, forgot password, a magic-link login, a change-email request. Each one is a separate template that can break on its own.

  4. Watch the inbox without refreshing

    New mail is pushed to the page over a live connection the moment our server accepts it, so the time a message appears is close to its real delivery time. Note how long each one took. How it works explains the delivery path.

  5. Open each message in both views

    Read it in HTML, then switch to Plain Text. The plain view is what some clients and screen readers fall back to, and it is where a missing text part or an unreadable code shows up first. Click every link and confirm where it lands.

  6. Extend if the flow is slow

    Drip sequences, delayed approvals and day-two nudges need more time. Press +1 hr to reset the timer to a full hour. You can keep doing that until 24 hours after the mailbox was created.

  7. Let it expire, then test the bounce

    After expiry, our server refuses mail to that address at the SMTP stage with a permanent "No such mailbox" error. Send one more email to it and check that your app or mail provider records a hard bounce and stops mailing that user.

The sign-up email test checklist

These are the checks we would run on any product's sign-up emails before a release. Each one is easy to spot in a real inbox and easy to miss in a code review.

  • Verification code or link. It arrives, the code is readable in plain text, the link works once, and a second click gives a clear message instead of an error page.
  • Magic links and one-time codes. A new link invalidates the old one, an expired link explains what to do next, and opening the link in a different browser behaves the way you intend.
  • Password reset. The email says which account it is for, the link expires, and requesting a reset for an unregistered address does not reveal whether that address has an account.
  • Welcome and drip emails. The first one arrives after verification, not before it, and later steps do not fire for users who never confirmed.
  • HTML and plain-text parts. Both exist, both say the same thing, and nothing important lives only in an image. Remote images load in our HTML view, so you can check them there and use Plain Text to see the message without them.
  • Attachments. Invoices and PDFs arrive with sensible file names and content types. Keep test files under 1 MB per message, or send a download link, which is kinder to real users anyway.
  • Link targets. No link points to localhost, an internal hostname or a staging domain from a production email, and tracking redirects resolve to the right page.
  • Unsubscribe headers. Marketing and drip emails carry a working unsubscribe link and, for bulk senders, the one-click List-Unsubscribe header described in RFC 8058, which Google's sender guidelines require from bulk senders. Transactional emails such as resets should not be blocked by an unsubscribe.
  • Delivery time. Verification emails that take more than a minute or two lose users. If one is slow, check whether your app queues mail behind other jobs or whether the provider throttles new senders.
  • Your own rate limits. Hammer the resend button. The app should cap it and tell the user to wait, rather than sending ten codes or failing silently.
  • Re-using an address. Sign up twice with the same address inside one session and check the second attempt: a clear "already registered" path, and no second account.
  • Your disposable-domain rule. If your product blocks temporary addresses, confirm the error message is clear and that it does not also block real providers by mistake. More on that below.

Our limits, and what they mean for a test

These are the actual settings on our servers. Plan test runs around them.

Lifetime
One hour from creation. +1 hr resets it to a full hour, up to 24 hours after creation. Enough for a session, not for a test account you will reuse next sprint.
Messages
Up to 50 messages and 5 MB per mailbox. New mail is turned away once either limit is reached, so a load test aimed at one address stops counting quickly. Open a new mailbox per test user.
Message size
Up to 1 MB per email, attachments included. Only the first 10 attachments are kept.
Receive only
The address cannot send or reply. Flows that need the user to reply by email, such as support ticket threads, cannot be tested end to end here.
Domain
One domain for every address. If your product blocks known temporary domains, it will block ours, which is useful when that is the behaviour you want to test.
New mailboxes
Five new mailboxes per minute from one IP address. A QA team behind one office connection shares that budget.
Deletion
After expiry, a cleanup that runs every five minutes deletes the mailbox, its messages and attachments. Take screenshots before the timer runs out if you need evidence for a bug report.
Automation
There is no public API for scripted access to mailboxes. PureTempMail is built for a person looking at a browser, which is why automated suites belong on the tools further down.

Checking SPF, DKIM and DMARC on your test emails

A message that renders well can still fail authentication and land in spam for real users. To check, send the same email to a mailbox that shows the raw source, such as Gmail's Show original, and paste the headers into our email header analyzer. It shows whether SPF, DKIM and DMARC passed, flags a Reply-To on a different domain, and shows where delivery was slow. The analysis runs in your browser, so the headers are not sent to us.

Testing your own disposable-domain block

Plenty of teams add a disposable-email check to their sign-up form and never test it with a real temporary address. A temp inbox is the obvious test input.

  • Check the wording. The rejection should tell people what to use instead, such as "Please use a personal or work address". A bare "Invalid email" sends honest users hunting for a typo that is not there.
  • Check for false positives. Try addresses at small regional providers and at custom company domains. Blocklists that match on patterns sometimes catch them.
  • Check every entry point. The same rule should apply to the sign-up form, the change-email setting, invitations and the API, or people will simply use the path you forgot.
  • Decide whether you need the block at all. Our article on why websites block disposable email covers the costs that justify it and the cases where it only loses you honest users.

When a public temp inbox is the wrong tool

Use something else in these cases.

  • Anything carrying real secrets or customer data. Production tokens, real invoices, admin invitations. Use a sandbox that only your team can read.
  • Automated tests and CI. Point the app at a local catcher like Mailpit in development and CI, and at a hosted sandbox such as Mailtrap or Mailosaur when tests must run against a deployed environment. MailHog, the older local catcher, is no longer maintained, and Mailpit is the usual replacement.
  • Staging environments with copies of real user data. The bug there is the copied data. Scrub it, and route staging mail into a catcher so a test never emails a real customer.
  • Test accounts you need to keep. A demo account for sales or a review account for an app store needs an address that works next month. Use plus addressing on a team mailbox or a catch-all on a test domain you own.
  • Fixtures that must never deliver. For seed data and unit tests, use the reserved domains such as example.com and the .test top-level domain set aside in RFC 2606. Mail to them goes nowhere by design.

Bottom line

Use a temporary email address for testing when a person needs to see a real email from a real sender, quickly, with fake data: release checks, exploratory testing and demos. Automate with a catcher or sandbox, keep secrets out of public inboxes, and use our other use cases page if you are deciding where else a throwaway address fits. To see what happens to a message after it reaches us, read how a temp mail service works inside.

Sources