For Developers and Testers

Anyone building software that sends mail needs somewhere to receive it. A disposable address covers part of that need well and part of it badly, and the boundary is worth knowing before you build a workflow around it.

What it is genuinely good for

Checking a signup flow end to end. You need a real address, at a real domain, that a real mail server will accept, and you need to read what arrives. A disposable address gives you all of that in one click.

Testing multiple accounts. Registration, invitations, roles, shared documents. Any flow with more than one participant needs more than one address, and inventing them is instant.

Seeing what a message actually looks like. Not what your template renders in a preview, but what survives after the sending platform has processed it. The two differ more often than people expect, especially with images and links.

Confirming deliverability in a rough sense. If your message never arrives at all, something is wrong at your end, and knowing that early is useful.

Demonstrating something to somebody else. No account, no setup, works on their machine as well as yours.

Where it is the wrong tool

Automated test suites. Scraping a public service from a test runner is fragile, slow, rate limited and rude. Tools built for the job, or a mail catcher running locally, are better in every way.

Anything with real customer data. Test with fabricated data. A disposable mailbox is not a safe place for anything real, and neither is a shared staging environment.

Judging spam placement. Whether your mail lands in someone's spam folder depends on the receiving provider's assessment of your domain, your history and your content. A disposable service tells you nothing about how a large provider would treat the same message.

Testing anything time consuming. Mailboxes here expire in hours. A test that needs the same address next week needs a different arrangement.

Practical notes

Choose your own name. Instead of accepting a random address, type something meaningful. Testing an invitation flow is much easier when the addresses are recognisable rather than random words.

Watch the message body carefully. We display messages in a sandboxed frame with scripts disabled, which is how any sensible mail client behaves. If your template depends on script or on styles that get stripped, you are seeing roughly what a cautious client will show your users.

Remember attachments are filtered. Executable file types are refused outright, and anything over a few megabytes is skipped. That is a security measure, not a bug, but it means this is not the place to test large file delivery.

Do not automate against us. Hammering the service from a script gets your traffic blocked and does not produce reliable tests anyway. If you need programmatic access to received mail, run a local mail catcher.

What happens to your message before it is displayed

Reading the rendered message correctly means knowing what was done to it, so here is the pipeline in order.

The message is parsed on arrival and the HTML is cleaned once, at that moment, rather than every time somebody opens it. Cleaning is a strict allow list rather than a search for dangerous things.

Tags that survive are the ordinary document set: headings, paragraphs, lists, tables, links, images, and the usual inline formatting. Everything else is removed. Attributes are cut back to almost nothing: href and title on links, src, alt, title, width and height on images.

Style attributes are dropped entirely, and the contents of style, script, iframe and noscript blocks go with the tags rather than being left behind as loose text. Only http, https and mailto links are kept, so a data: URL in an image source disappears. Surviving links are rewritten to open in a new tab with rel="noopener noreferrer nofollow".

The result is then shown inside an isolated frame that forbids scripts, forms and network requests, with remote images allowed because otherwise most real mail looks broken.

For a template author the useful consequence is this: what you see here is close to a worst case client. Head styles are gone, inline styles are gone, and only the document structure and the attributes above are left. If your message reads correctly in that state, it will read correctly almost anywhere. If it collapses, you have found out cheaply that your layout depends on things a cautious client will not honour.

Size limits shape the test too. Anything over ten megabytes in total is refused before it is parsed, and individual files over five megabytes are skipped while the rest of the message still arrives. The full rules are on the attachments page.

A checklist for your own transactional mail

Since you are here testing, these are the things worth checking while you have a real inbox in front of you. Most teams check the first and miss the rest.

Does it arrive at all. The obvious one.

Does it survive without images. Many clients block remote images by default. If your call to action is inside a picture, a share of your users sees nothing.

Does the plain text part exist and make sense. Some clients show it, and an empty or auto-generated text part looks broken.

Is the important thing in the first line. Verification codes buried under a logo and three paragraphs of welcome copy are a support burden.

Does the subject line stand alone. People scan subjects. "Verify your email" beats "Welcome to our platform!" for a message containing a code.

Do links survive the sending platform. Tracking wrappers sometimes mangle parameters, and the failure shows up only in a real message, not in a preview.

Is the sender name recognisable. In a list of messages, the sender is what people look at first.

Sending from your own tests

Everything above assumes your application already sends. If you are setting that up, two points save days later.

Send from a domain you control with the usual authentication records in place. Mail from a domain without them is treated as suspicious by every large provider, and the symptom is "works in testing, disappears in production".

Never send test mail to addresses you did not invent. Real addresses in a seeded database belong to real people, and a staging environment mailing them is a common and entirely preventable incident.

When your test message does not turn up

Before assuming the mailbox is broken, work through these in order. In practice the first one accounts for most of it.

Your own sending platform refused the recipient. Most delivery services keep a list of disposable domains and either reject the recipient when your code calls the API or accept the call and quietly drop the message. The evidence is in their response and their suppression list, not in any inbox. Check the log your application wrote when it sent, and check whether the message ever left.

The domain left the rotation. The domains offered here change over time as old ones are detected and retired. An address pasted into a test fixture months ago can point at a domain that no longer routes mail anywhere. Take the domain from the page at the moment you run the test rather than hard coding one.

The mailbox expired between setup and send. Without an account, a mailbox is removed one idle day after you last touched it. If your fixture made the address yesterday and nothing has opened it since, the message is being sent to nothing, and no failure report comes back to tell you, as what happens after expiry explains.

You replaced the address while waiting. Requesting a fresh one wipes the previous mailbox and its contents on the spot. Two tabs and one impatient click is a common way to lose a message that had already arrived.

The better setup for a real project

For anything beyond manual checking, run a mail catcher in development. Several mature options exist: they accept everything on a local port, store it in memory, and expose it through an interface and an API your tests can query. No network dependency, no rate limits, no cleanup, and messages that stay put until you clear them.

Use a disposable address for what it is: a fast way to look at real mail passing through real infrastructure when you are checking something by hand.