← All posts

Testing your app's emails without bothering real people

October 12, 2026 · 2 min read

If you build software that sends email (sign-up confirmations, password resets, receipts), you need a safe way to test it. Sending tests to made-up addresses on real domains can land mail in a stranger's inbox. There are two better tools, for two different jobs.

Job 1: addresses that must never deliver

For unit tests, sample data and documentation, use names that are reserved precisely so they never belong to anyone:

• the domains example.com, example.net and example.org;
• the top-level names .test, .example, .invalid and .localhost.

These were set aside by an internet standard (RFC 2606) for testing and documentation. Mail to [email protected] will never reach a real person. That is the point, and also why you cannot read it.

Job 2: seeing what the email really looks like

Sometimes you need the message itself: does the layout hold up, does the link point to the right place, does the code appear in the subject? For that you need an inbox that actually receives. A temporary address works well:

1. Generate a random address on the home page.
2. Trigger the email from your app.
3. Open it here and check it with images off and then on.

A short review checklist

• The sender name and address look like your brand, not a server name.
• The subject makes sense in a crowded inbox, and codes are easy to spot.
• The message still reads well with remote images blocked.
• Links go to the right domain and are not broken by tracking redirects.
• There is a plain-text version, and it is not empty.
• Marketing mail has a working unsubscribe link.

Be a good neighbour

This is a shared, public service. Use it for checks by hand, not for automated load tests or bulk sending. A handful of test messages is fine. Thousands are not, and our Terms forbid it.