Your Users Aren't Receiving Password Reset Emails. You Just Don't Know It Yet

Password reset is the email nobody thinks about until it breaks, and nobody notices when it breaks silently. The standard SaaS dashboard shows you delivered: 99.4% and a green check mark. What the dashboard doesn't show is where those 99.4% actually landed — Inbox, Spam, Promotions, or a provider-side greylist that will drop the mail after the user has already given up and gone to your competitor.

This is the cruelest kind of churn because it is invisible in every metric you normally look at. The user never complained. The email went out. Your database shows they exist. Your ESP shows the message was accepted by the receiving server. And yet the person stopped using your product because they could not get back in.

Why users don't tell you

When a password reset email doesn't arrive, the user's thought process takes about twenty seconds:

1. Click "Forgot password", enter email, wait.
2. Refresh inbox. Nothing.
3. Check spam. Maybe nothing, maybe it's there.
4. Try again. Same result.
5. Give up. Close tab.

There is no step 6 where they write a support ticket explaining the problem. The default behavior is silence. Add a competitor button in the next Google search, and you have lost the account with zero signal.

Why password resets get filtered more than marketing

Counter-intuitively, transactional email is not automatically trusted. Gmail, Outlook, and Yahoo do not treatnoreply@yourapp.com differently than newsletter@yourapp.com — the filters look at the domain's overall reputation, DKIM/SPF/DMARC alignment, IP reputation, and recipient engagement.

Password reset emails have several traits that work against them in spam filters:

• Short, template-heavy body. Filter models associate short bodies with the same text repeated across thousands of recipients — exactly what bulk campaigns look like.
• Long random-looking tokens. A URL with a 64-char hex token reads as suspicious to some filters, especially when the link domain is different from the From domain.
• Urgency language. "Expires in 15 minutes", "Act now", "Do not share this link" — all trigger heuristics originally tuned for phishing.
• Zero engagement signal. Users don't reply, rarely forward, and open in under a second. Filters interpret the lack of engagement as low-value mail.

What your ESP dashboard is actually measuring

Every ESP — SendGrid, Postmark, Mailgun, SES, Resend, you name it — reports three primary metrics: delivered, bounced, and complained. None of these three answer the question you actually care about: did the mail land in the inbox?

"Delivered" means the receiving SMTP server returned a 2xx response. It does not mean Gmail put the mail in the Inbox tab. Gmail can accept the message, silently file it under Spam or Promotions, and the ESP still counts it as delivered. From the ESP's point of view, anything past the handoff is not its problem.

# what the ESP sees                     # what the user sees
delivered: 99.4%                        Inbox:        61%
bounced:    0.4%                        Promotions:   18%
complained: 0.2%                        Spam:         19%
                                        Missing:       2%

The only way to know the actual Inbox/Spam/Promotions split is to send your real password-reset template to mailboxes you control on every provider that matters, and read the headers to see where the mail actually went.

A simple monitoring setup for password reset

Step 1. Send the real template, not a clean test

The single biggest mistake is testing with a generic body. Your spam filter score is driven by the exact HTML your users receive — the exact button, the exact copy, the exact link domain. Test with a fixture that renders the real template with a throwaway token.

Step 2. Hit every mailbox provider your users actually have

For a consumer product that means at least Gmail, Outlook.com / Hotmail, Yahoo, iCloud, and AOL. For CIS-facing products add Mail.ru, Yandex, Rambler. For B2B add Office 365, Google Workspace (different from consumer Gmail), Zoho, and Fastmail.

Step 3. Run it every hour or on deploy

Deliverability degrades gradually. A monthly check misses a three-day Gmail penalty. An hourly check — or at minimum a post-deploy check — catches the regression before it costs you a week of users.

# example: POST after every deploy
curl -X POST https://check.live-direct-marketing.online/api/tests \
  -H "Content-Type: application/json" \
  -d '{
    "email": "reset-probe@yourapp.com",
    "subject": "Reset your password",
    "html": "<rendered template here>"
  }'

Fixing what the test reveals

If the placement report shows more than a few percent in Spam for a given provider, the fix usually falls into one of three buckets:

• Authentication gaps. SPF covers the sending IP, DKIM signs the domain, DMARC aligns them. Missing any one of these is the single most common cause of password-reset mail hitting spam, especially at Gmail and Yahoo after their 2024 bulk sender requirements.
• Mixed traffic on one domain. Send transactional mail from a subdomain (auth.yourapp.com) separate from marketing (news.yourapp.com). A single bad marketing campaign should not burn your reset-password reputation.
• Template red flags. Remove all-caps urgency, ensure the link domain matches the From domain, cut inline images where possible. A minimal HTML template with a text alternative outperforms a richly-designed one for transactional mail every time.

FAQ