A Test Email Address That Does Not Change Between Runs
Use one stable email address across every test run instead of a rotating temp-mail domain that can vanish mid-suite.
Why do QA and automation need a real, stable address?
Signup flows, invite flows, and account recovery flows all need a real inbox to verify against. A temp-mail domain that rotates or expires between test runs turns a flaky test into a flaky product bug report: nobody can tell which one failed.
A fixed address removes that variable. The same mailbox name and domain show up in every test run, every environment, and every re-run after a fix.
How does a permanent address fit into a test suite?
Because the address never expires, it can be hardcoded into fixtures, seed data, or environment variables without a rotation script keeping it alive. That removes one moving part from the test infrastructure.
Set up a test address in your pipeline
- Sign in with Google and claim a mailbox name that maps to its role, such as "qa" or "staging".
- Store that address in your test config or secrets store, the same place other fixed test fixtures live.
- Point signup and verification flows at it and check the mailbox after each run to confirm the expected email arrived.
Temp-mail service vs. a permanent test address
| Aspect | Rotating temp-mail | Permanent test address |
|---|---|---|
| Address lifetime | Minutes to hours | Does not expire |
| Reuse across runs | Requires re-generation | Same address every time |
| Traceability | Hard to correlate to a specific run | One fixed identity to search logs for |
Reading the verification email during a test
regmail.me does not publish an email-retrieval API. Treat the mailbox as a manual or browser-scripted checkpoint for now: open the web interface to read the message, rather than assuming a program can pull it automatically.
What if a test suite runs more than five checks a day?
The free tier allows 5 received emails per mailbox per day. A suite that triggers more verification emails than that in one day needs paid overflow turned on for that mailbox, at 1 Energy per email past the allowance, or a second mailbox at 5 Energy.
Does a permanent domain avoid being blocked by the platform under test?
No service can promise how a third-party platform treats any given email domain, since that policy is theirs to change. What a permanent address provides is a stable, non-expiring target: mail sent to it within the daily free allowance is received and stays readable, which is what a test actually needs to verify.
Frequently asked questions
Can multiple test environments share the same address?
Yes, but verification emails from parallel runs land in the same mailbox and can be hard to tell apart. A separate mailbox per environment, at 5 Energy each beyond the free one, keeps runs isolated.
Does the mailbox reset between test runs?
No. Old emails stay until deleted. Clear the mailbox manually, or design tests to match on the newest message, if leftover mail from a previous run could cause a false match.
Can this address send a reply as part of a two-way test flow?
No. regmail.me is receive-only, so it cannot send outbound mail. It fits verification, OTP, and notification checks where only receiving matters, not flows that require an automated reply.
Is there a risk of hitting the daily quota during CI runs?
Yes, if a suite runs many signup flows in one day. Turn on paid overflow for the CI mailbox before a heavy test day, or split load across a few mailboxes.
Get your own receive-only mailbox
Free, permanent, and ready in seconds — no setup required.