Yes. Signed-in accounts can create inboxes and read messages through the REST API documented in the API reference.

Will my application's mail be accepted?

Mail addressed to our active domains is accepted and parsed. Whether your own provider allows sending to disposable domains is a separate question worth checking.

Attachments are stored separately from the message body and are reachable only by the inbox owner.

Is there sample data?

Sample message seeding is a development-only convenience and is not available in production.

For developers

Email testing for developers

Run registration, verification and notification flows end to end against a throwaway address you can recreate whenever a test needs a clean state.

By the InstantEduMail Editorial Team · Published 14 August 2026 · Last reviewed 14 August 2026

Create a test inbox API reference

HTTPS everywhereSite and API served over TLS
Owner-scoped accessRow-level security on every table
Guest inboxes expireSigned-out inboxes last 2 hours
Sandboxed HTML mailRendered in a restricted iframe
Built for educationCoursework and QA workflows
No card requiredCreate an inbox without payment

Real delivery path

Mail is accepted, parsed and stored the same way a real recipient's provider would.

Fresh address per run

Create a new inbox whenever a test needs an address with no history.

Inspect the message

Read the delivered body, headers and attachments rather than trusting your send log.

Scriptable

Signed-in accounts can drive inboxes and messages through the REST API.

Why not just use your own inbox

Testing against a personal or team mailbox is convenient once and painful thereafter. Test traffic pollutes a real inbox, an accidental unsubscribe hits a real account, and hardcoded colleague addresses outlive the person who added them. Worse, you never get a clean first-signup state, which is exactly the state most email bugs live in.

A disposable inbox removes all of that. Each run gets an address with no history, no filters and no prior relationship with the sender.

What to actually test

The interesting failures are rarely 'did it send'. They are whether the token in the link survived templating and URL encoding, whether the HTML still renders after sanitisation, whether the plain-text fallback exists at all, and whether attachments arrive intact and with the right filename.

Sign-up confirmation and the round trip of the verification link.
Password reset, including token expiry and single-use behaviour.
Transactional notifications triggered by application state changes.
HTML rendering after sanitisation, and the text/plain alternative.
Attachment type, size and filename handling.

Working with the reader

Messages appear live while the inbox is open, so a manual test rarely needs a refresh. Plain-text bodies are linkified, which means verification links stay clickable instead of arriving as dead text. HTML bodies are sanitised and rendered inside a sandboxed frame, so a template with remote scripts cannot reach the surrounding page — useful to know when a message renders differently here than in a desktop client.

Keep reading

Receive test emails
A step-by-step walkthrough of a full verification-flow test.
Disposable email for testing
How throwaway inboxes compare with a shared QA mailbox.
Education email testing
QA patterns specific to education software and course platforms.

Frequently asked questions

Ready to try InstantEduMail?

Create a mailbox in seconds — no card required — or subscribe for monthly notes on education email.

Create a free inbox