Testing Email Delivery for Passwordless Sign-In

Testing Email Delivery for Passwordless Sign-In
L
posted by admin
June 27, 2026

We were adding passwordless sign-in to a client’s mobile and web app. Instead of a password, the user receives a sign-in link or a short code by email and enters it. It removes a stored credential and is usually fewer steps than a social login.

The approach depends on the email being delivered. The code has to reach the user’s actual mailbox. A send that the mail provider accepts is not the same as a message the user receives, and if the code does not arrive, the user cannot log in.

Verifying delivery

For the providers our users are on, this is easy to check. We keep test accounts on Office 365, custom Exchange, Gmail, Google Workspace, Yahoo, hey.com, Hotmail, MSN, and Proton, among others. We send a sign-in email and confirm it arrived and rendered correctly, because we can open every one of those mailboxes.

Corporate domains

Corporate domains are harder, for two reasons. Mail to them goes through Amazon SES to mailboxes we cannot open, so there is no inbox for us to inspect. And when something is wrong on the receiving side, the person who can see it is the company’s own email administrator, not us. We end up in the middle, relaying tests back and forth, which is slow for everyone.

What was missing was a way for the email admin to test the delivery path without us.

The tool

So I wrote a small tool for that. It isolates the SES part of the chain and removes everything else: the application, the SMTP library, the template, and the queue. It talks only to the AWS API, which keeps it simple enough to hand to someone who was not involved in building the app.

It is one Cloudflare Worker that signs SES API requests and serves a single page. It reports the account sending status, quota, and sandbox state. It lists the verified identities with their DKIM and MAIL FROM configuration. It sends a test message through the same SES action the application uses, which matters because SMTP credentials sign with SendRawEmail rather than the v2 SendEmail API. And it reads the account suppression list, where a single old bounce can leave SES discarding mail to an address while still reporting the send as successful.

An email admin can run all of this directly, see what SES is doing with a given address, and act on it, without needing me in the loop.

mailsend

The tool is not specific to the client, so we cleaned it up and published it as mailsend at github.com/ragelink/mailsend-ses under the MIT license. It runs as a Cloudflare Worker and needs an SES key and a region. When the key lacks a permission, the related feature is disabled instead of erroring, since the available permissions are often part of what you are checking.

Notes

  • Email-based login moves the reliability problem onto email delivery, including failures that do not surface an error.
  • The delivery paths that are hardest to test are the ones where you control neither the mailbox nor the receiving setup.
  • A debugging tool is more useful when it is simple enough to hand to the person who owns the other side, so they can test without you.

mailsend is open source at github.com/ConflictHQ/mailsend-ses under the MIT license, and runs on Cloudflare Workers. It is built by CONFLICT, an AWS Partner. Leo Mata is an AWS Certified Solutions Architect and AWS Certified DevOps Engineer (credentials).