Cypress specs that type into email fields inherit the same collision problem as every other runner, with a Cypress-shaped twist: custom commands, cy.session, and Dashboard recordings that happily capture whatever you typed. A throwaway address per spec keeps recordings free of personal mail and keeps parallel runs from stealing each other's codes.
Custom command habit
Recommended habit: a custom command that returns a fresh dummy address, used in before hooks before cy.session caches a user. For mail content, prefer cy.intercept, test-only token endpoints, or an in-cluster catcher. The dummyemails.org console is for authoring and staging walkthroughs: auto-mint, Copy, watch the animated empty inbox, open the message when it arrives.
When a spec fails on already registered, hit Change in the UI during debug or mint again in the command. Delete clears a burned session. Refresh polls. TLD chips stay short (.org, .com, .edu) and only include domains with real receive.
Cypress-specific guidance
Do not copy Playwright tracing advice here. Cypress owns Dashboard privacy, custom commands, and session caching language. Keep Acceptable use: authorized testing only. Document the command in your repo README so contractors do not invent qa@example.com again.
Ten versus twenty minute TTL matters when a human is babysitting a long Cypress Studio session. Homepage twenty minutes is the default. The ten minute email page exists for shorter fused timers and SEO intent around that phrase, still in a testing voice.
Receive honesty and environment bleed
Owned-domain receive turns the inbox into a real QA surface. Until the five customer domains are wired with MX, treat addresses as the uniqueness layer and stubs as the message layer. That honesty keeps doorway copy clean and engineers trusting the docs.
Also watch for environment bleed: if Cypress runs against an environment that shares production ESP credentials, disposable addresses reduce but do not erase risk. Fix the wiring. Use throwaways as the standard input anyway.
Throwaway email will not fix timing flakes by itself. It will fix the class of failures where two specs share one mailbox. That is enough reason to standardize the command across the repo and link this guide from your internal QA handbook.
Popular Articles
Short DummyEmails guides for QA labs, OTP checks, and browser automation.
Owned-domain temp inbox for QA
Why a hostname you control beats a public shared inbox when signup and OTP tests need a predictable allowlist.
OTP testing without your real mail
Mint a recipient, trigger the code from staging, read it in a short live window, and keep personal inboxes out of QA.
Playwright throwaway email
Give each browser worker a private identity so parallel signup specs stop colliding on one fixture.
Cypress throwaway email
Alias a fresh DummyEmails address per spec and keep retries from reusing yesterday's user row.
10 minute email for testing
Live 10-minute countdown inbox for short QA sessions.
Disposable email for signup forms
Burn-after-use addresses so staging signups never hit real CRM.
FAQ
- Should every Cypress spec mint a new address?
- Yes when uniqueness or one-time mail matters.
- Will addresses appear in Cypress Dashboard?
- Yes if typed. Throwaways avoid personal leaks.
- Custom command or fixture file?
- Custom command is usually ergonomic.
- Can Cypress depend on the public UI?
- Local debug yes. CI should stub or mint programmatically.
- How is this different from Playwright?
- Same idea, Cypress commands and Dashboard privacy.
For authorized testing and development only. Preview inbox uses demo mail until DNS/MX is live on domains Chirag owns. Do not use for fraud, impersonation, privacy anonymity, or production traffic.