Email testing for applications
Email testing on the receiving side means opening the message your application actually produced and checking it: the recipient, the subject, the content, the links and the attachment. DemoPost gives you a private inbox with distinct addresses per test user, so you can do that without routing test mail through personal or company mailboxes.
What “receiving side” testing covers
Most teams verify their sending configuration: the provider accepted the message and the log says sent. That tells you the handover worked. It does not tell you whether the right template was used, whether the merge fields were filled, whether the invoice PDF was attached, or whether the reset link points at the right environment.
Reading the received message closes that gap. You are looking at exactly what left your application, in the state it arrived.
A repeatable setup
1. Give each test user its own address
Put yourprefix+signup@in.demopost.net, yourprefix+invoice@in.demopost.net and so on into the test records of your application. Each reference makes it obvious which scenario produced a message.
2. Trigger the flow the way a user would
Register the account, place the order, generate the invoice. Use the application's own interface rather than calling the mail provider directly — you want to test the flow, not the provider.
3. Read the result
Open the message in DemoPost, work through the checklist below, and delete the message or leave it to expire after 30 days.
Manual checklist
- Recipient: the message went to the address of the test user you expected, including the reference after the plus sign.
- Sender and reply-to: the from name and address match the environment you are testing.
- Subject: no untranslated keys, no empty placeholders, no leftover “TEST” prefixes you forgot to remove.
- Merge fields: names, amounts, dates and order numbers match the record you created.
- Links: every link points at the correct environment and the correct object, not at localhost or a stale domain.
- Attachments: the expected file is present, opens, has a sensible filename and contains the same figures as the message body.
- Plain-text and HTML: the message is readable when images are not loaded.
- Timing: the message arrived when you expected it, not fifteen minutes later from a stuck queue.
- Repeat runs: triggering the flow twice does not produce duplicate or conflicting messages.
What DemoPost cannot verify for you
What DemoPost does not do
- Inbox placement. A message arriving in DemoPost says nothing about whether Gmail or Outlook would place the same message in the inbox or in spam.
- Rendering in every email client. You see the received message in a browser, not a matrix of client previews.
- Automatic assertions. There are no test assertions, no CI/CD integration and no API-driven pass/fail; inspection is manual.
- Outbound behaviour. DemoPost receives only; it does not send, reply, or intercept messages addressed to real customers.
- Production data hygiene. It does not sanitise your database — you decide to use test data.
Related reading
Try it on your next release
Start a 7-day trial, point one test user at a DemoPost address and walk the checklist above.
Try Email for 7 days. Then €19/month, excluding applicable tax. Cancel before your trial ends to avoid the subscription charge.