Use case · Transactional email

Know your sign-up email works before a customer tries it

Parcelpoint sends a verification email to every new user and a receipt with every order. In simmail, people open the verify links, a dead address bounces, and every email gets a health report.

Parcelpoint · sent mail
Parcelpoint's sent mail in simmail, with a receipt's health report open
Sign-up

Nobody replies. They click.

People treat a verification email the way real people do: it comes from a no-reply address and carries a code, so nobody answers it. Ada, Lena and Sam open their verify links instead, and your app sees real requests to them.

An old Hotmail address bounces back to no-reply@, so your bounce handling has something to handle. In your tests, wait for each email and take the code or the link straight from it.

The wait API · SDKs · Links

Parcelpoint · activity
The Activity timeline: verify links opened, a bounce, and emails people chose not to answer
Three verify links opened, one address bounced, and the reason for each.
Health

Broken images, caught on the first run

Every email your app sends gets a spam score with the rules that moved it, a check of every link and image, a client-compatibility report and an accessibility report. Parcelpoint's receipt links to three images that don't exist.

Mail that scores over a person's spam filter lands in their Junk folder. If a test times out waiting for an email, look there.

The health report · Junk

Parcelpoint · receipt health
Links and images in a receipt, three of them returning HTTP 404
banner.png, truck.png and a third image: all HTTP 404.
Failures

Does your queue retry, or drop the email?

Turn on greylisting, rate limits, full mailboxes, dropped connections or a provider's policy block, with the codes real providers send. Then watch whether your password reset still arrives.

Chaos and faults

simmail · chaos
Chaos: fault rules for greylisting and a full mailbox, and ready-made provider failures
Greylisting for everyone, and 552 Mailbox full one time in ten.
Connect

Your SMTP settings, pointed at simmail

Any SMTP client works. Your tests start a wait, click the button that sends, and get the email back with its codes and links already extracted. No sleeps, no shared inbox to clean up.

</> For developers: SMTP settings and a sign-up test
# Sending
SMTP_HOST=c1.simmail.dev
SMTP_PORT=2525
SMTP_SECURE=false        # STARTTLS on 2525; use 4650 with SMTP_SECURE=true for TLS
[email protected]
SMTP_PASS=a-long-password

# For your tests (the SDKs read these)
SIMMAIL_URL=https://c1.simmail.dev
SIMMAIL_API_KEY=smk_your_key

Read the docs →

Questions

Do I have to change my app to use simmail?

No. Point its SMTP settings at your universe’s host, port and login, the same way you would point them at a real provider. Any SMTP client works.

Can a test email reach a real customer?

No. simmail has no relay and no outbound SMTP client. Mail to any address, at any domain, stays inside simmail.

How are one-time codes found?

4 to 8 digits, or 6 to 8 letters and digits with at least one digit, shortly after a word such as code, OTP, PIN or verification. A line holding only 4 to 8 digits also counts. See how codes and links are found.

Will my sign-up tests create thousands of simulated people?

Not if you turn strangers off for your test domain. Mail still lands in a mailbox, so waits work, but nobody answers. See the CI guide.

Can I see what my receipts look like in Outlook?

The health report checks your HTML and CSS against caniemail.com’s data for real email clients and lists what fails or partly works where, with fixes. It does not render screenshots.

Put real behaviour between your app and its inbox

Start free with 25 AI actions a month, no card needed. Upgrade when you need more.