My Transactional Emails Are Not Arriving

A user tells you they never got the password reset. You check your code, and the send function is right there, doing what it should. You trigger it yourself and the email lands in your inbox in four seconds. So either the user is wrong, or something between your server and their mailbox is quietly dropping messages.

It is almost always the second one, and "email is broken" is three separate failures wearing one coat. Your code can fail to call the provider. The provider can accept the message and fail to deliver it. The receiving server can accept it and file it under spam, or discard it outright without telling anyone. Fixing the wrong layer is why this bug drags on for weeks.

The distinction matters because only the first is a code problem. The other two are domain authentication and reputation, and they do not care how good your code is.

Find the layer in ten minutes

Your provider's dashboard answers this immediately. Every serious transactional service — Resend, Postmark, SendGrid, SES — logs each message with a status: accepted, delivered, bounced, deferred, complained, or nothing at all.

No record of the message. Your code never called the API successfully. This is a code and configuration problem: keep reading at "the send never happened".

Accepted but not delivered. The provider took it and the receiving server refused or deferred it. This is authentication or reputation.

Delivered, user says no email. It arrived and got filed somewhere the user is not looking. This is inbox placement — spam folder, Gmail Promotions tab, or a corporate quarantine.

Bounced. Read the bounce reason verbatim. A hard bounce on a valid address usually names the exact policy that rejected you.

Do this before touching code. Roughly two-thirds of the "emails are not sending" work we pick up turns out to be delivery, not sending.

When the send never happened

Four causes, in order of how often they turn out to be the one.

The API key is missing or wrong in production. Your local file has it; the host does not. The SDK throws, your code catches it and logs a friendly message nobody reads, and the request returns 200 as if all is well. This is the single most common cause, and it is part of the wider family covered in environment variables that are not working.

The sending domain is not verified. Providers refuse to send from a domain you have not proven you control. The API returns a clear error saying so, which your error handler swallows.

You are still on the built-in demo mailer. Hosted auth services ship with a shared sender that is aggressively rate-limited — enough for your own test accounts, not enough for real signups. This is why signup breaks for real users while every account you made yourself worked, a pattern covered in login working while signup does not.

The send is inside a request that timed out. Sending inline at the end of a slow handler means a request that dies takes the email with it. Transactional email belongs on a background path, which also gives you retries for free — see background jobs in an AI-generated app.

One thing to fix regardless of cause: stop swallowing the error. A failed send must log the provider's response and, ideally, alert. Silent email failure is the reason these bugs live for months.

When the provider sends and nobody receives

This is authentication, and there are exactly three DNS records that matter.

SPF lists which servers may send mail for your domain. Publish one record naming your provider. Do not publish two — multiple SPF records is a common misconfiguration that fails validation entirely.

DKIM cryptographically signs your messages so the receiver can verify they were not altered and really came from you. Your provider gives you the records; publish them exactly, including the selector.

DMARC tells receiving servers what to do when the first two fail, and asks for reports. Start with a monitoring-only policy so you get visibility without dropping legitimate mail, read the reports for a couple of weeks, then tighten to quarantine and finally reject.

Since 2024, the major mailbox providers require all three for bulk senders and increasingly enforce them for everyone. A domain without DKIM and DMARC in 2026 is not going to have reliable delivery, no matter how clean your code is.

Two more that get overlooked. Never send from a free-mail address like gmail.com as the From — those domains publish strict policies that make your mail fail their own authentication. And make sure the reply-to is a real, monitored address; no-reply senders take a measurable deliverability penalty and users hate them anyway.

When it is delivered and still invisible

Delivered mail that users cannot find is a content and reputation problem.

Send transactional mail from a different subdomain than your marketing mail. Reputation is tracked per domain, so a newsletter campaign that generates spam complaints will drag your password resets down with it if they share a sender. Splitting them is one DNS setup and it insulates the mail that actually matters.

Watch the content patterns that trigger filters: image-only emails with no text, link shorteners, mismatched display name and sender address, and single-word subject lines. Transactional mail should be short, plain, and specific — a working plain-text alternative alongside the HTML also helps.

Corporate mailboxes are their own category. Microsoft 365 and similar systems quarantine aggressively, and the user often has no idea a quarantine exists. If your users are on business email, expect to occasionally ask them to check with their IT admin, and expect a warm-up period before a new sending domain is trusted.

Symptom to cause

Make failures loud

Once it works, keep it working with three cheap things. Send provider webhooks for bounces and complaints back into your app and record them against the user, so you know an address is dead before a customer tells you. Alert when the bounce rate crosses a threshold rather than reading dashboards. And add an end-to-end test that triggers a password reset against a real inbox on a schedule — a synthetic check that catches an expired API key or a lapsed DNS record on the day it happens, which is the same principle behind monitoring and alerts for a small SaaS.

Frequently asked questions

Why do emails work in development but not in production? Development usually sends through a provider sandbox or a local catcher that accepts everything and shows it in a UI, bypassing authentication entirely. Production sends to real mailbox providers that check SPF, DKIM, DMARC, and your sending reputation. Nothing about the code changed — the audience did.

How long does a new sending domain take to become reliable? Authentication records take effect within an hour or two of DNS propagation. Reputation takes longer: a couple of weeks of steady, low-complaint sending before major providers treat you as established. Ramp volume gradually rather than sending your first thousand emails on day one.

Is a dedicated IP worth it? Not at low volume. Dedicated IPs need consistent traffic to build and hold reputation, and an under-used one performs worse than a well-managed shared pool. Below roughly one hundred thousand emails a month, stay on shared and spend the effort on authentication and content instead.

---

If password resets and receipts are landing in a void and you have already read your own send code five times, the break is almost certainly below your application. SprintX fixes transactional email end to end — provider setup, DNS authentication, background sending, and bounce monitoring — so the messages that keep customers in your product actually reach them. Send us your repo or domain.