Why aren't my password reset emails arriving?

A user clicks "Forgot password", your site says "Check your inbox", and nothing arrives. Or it turns up in spam twenty minutes later, after the link has expired. Reset and verification emails are the messages users need most urgently, and they fail for a predictable set of reasons. This guide is for site and app owners: it lists the causes, walks through a diagnosis, and covers the fixes. If your problem is contact form mail reaching your own team, see website form emails going to spam, which covers PHP mail() and WordPress in detail.

Why do password reset emails go missing?

Your app hands the message to a mail system, and from then on it's judged like any other email. Receivers check whether the sending server is authorized for the From domain, whether the message is signed, and whether the server has a good reputation. Then they apply their own limits and filters.

The most common root cause is the first one. Your staff mail goes through Microsoft 365 or Google Workspace, which you set up carefully. Reset emails come from somewhere else: the web server, a framework's default mailer, a plugin, a forgotten SMTP account. That path often isn't in SPF and doesn't sign with DKIM for your domain.

What do the big mailbox providers require?

Google's sender guidelines apply to everyone sending to personal Gmail accounts, not just bulk senders. For all senders, Google requires:

• "SPF or DKIM email authentication for your sending domains."
• "Valid forward and reverse DNS records, also referred to as PTR records" for sending domains or IPs.
• "A TLS connection for transmitting email."
• Messages formatted to RFC 5322, and no impersonation of Gmail From headers.

Google warns that unauthenticated messages "might be marked as spam or rejected with a 5.7.26 error". It also notes that on a shared IP, "the activity of any senders using a shared IP address affects the reputation of all senders for that shared IP address."

If you send more than 5,000 messages a day to Gmail, DMARC and alignment are required too. A busy app's reset and signup mail can reach that volume. Our guide to bulk sender requirements covers Gmail, Yahoo and Microsoft.

How do you diagnose missing reset emails step by step?

1. Confirm the app sent anything. Check the application log for the reset request and a send event. If your framework queues mail, confirm the queue worker is running. A stopped worker looks exactly like a deliverability problem.
2. Check your provider's event log. A transactional service records each message as accepted, delivered, deferred, bounced or suppressed. "Accepted" or "sent" only means the provider took it.
3. Send a test through the same configuration. Our Email Deliverability Test gives you an address and a one-time code. The code must be in the subject, so send a test message through the exact mailer settings your app uses for resets (most frameworks and SMTP plugins can send a test message, or use a short script with the same credentials). The report shows SPF, DKIM and DMARC results, reverse DNS, blocklists, TLS and a spam verdict.
4. Read a delivered copy's headers. Trigger a reset to your own Gmail or Outlook address and open the full headers. Look for spf=pass or dkim=pass for your domain and dmarc=pass. The Email Header Analyzer reads them in your browser.
5. Read any bounce text. The code tells you which cause you have. See the table below.
6. Check the address. Look for typos such as a misspelled provider name. If the domain has no MX record, nothing can be delivered there. The MX Lookup shows it.
7. Check suppression. If an address bounced before, your provider may now skip it silently. Amazon SES, for example, says that for an address on the account-level suppression list, "SES accepts the message, but doesn't send it". Remove the entry once the user confirms the address works.
8. Ask the user to check spam and quarantine. In a company, the message may sit in an admin quarantine the user can't see.

Bounce and deferral codes worth knowing

Gmail codes are from Google's SMTP error reference; Yahoo's from its Sender Hub. Anything else, look up with the SMTP Error Code Lookup.

Why do reset emails arrive late?

Two things delay mail without bouncing it.

Greylisting. Some receivers temporarily refuse mail from unfamiliar senders and accept it on retry. RFC 6647, which documents greylisting, names the cost directly: "the imposition of delay on legitimate mail", adding that "some popular MTAs do not retry failed delivery attempts for an hour or more". RFC 5321 says a sender's retry interval "SHOULD be at least 30 minutes". Our greylisting guide explains the mechanics.

Rate limits. A burst of resets, or a user clicking "resend" repeatedly, can trip a receiver's limits or your provider's sending quota. Gmail's 421 4.7.28 and 450 4.2.1 responses are deferrals, so mail waits in a queue. See sending limits in Microsoft 365 and Google Workspace if you send through a business mailbox.

Design for this:

• Make reset links valid long enough to survive one retry cycle, while still expiring.
• Don't invalidate the previous link the moment a user asks for another, or the delayed first email becomes useless when it lands.
• Throttle resend requests per account and per IP, and show a message such as "We've sent it. It can take a few minutes."

How do you fix it for good?

1. Send through a transactional email service

Use a provider built for application email, with an API or authenticated SMTP, delivery events and bounce handling. Don't send resets from the web server's local mail program or through a staff mailbox. Microsoft plans to disable Basic authentication for SMTP AUTH by default in Exchange Online, which will break apps that log in to a Microsoft 365 mailbox with a password; see SMTP AUTH and Basic auth retirement.

2. Authenticate a domain you control, ideally a subdomain

1. Pick a sending domain, such as mail.example.com or account.example.com. A subdomain keeps transactional reputation separate from marketing and staff mail; see separate subdomains for transactional and marketing email.
2. Add the provider to SPF for the domain it uses as the envelope sender. Our SPF records by provider pages list the includes.
3. Turn on custom-domain DKIM so the provider signs with d= set to your domain or subdomain. Check it with the DKIM Checker.
4. Publish DMARC. Under relaxed alignment, mail.example.com aligns with a From address at example.com. Check with the DMARC Checker.
5. Use a From address on that domain, for example Example <no-reply@account.example.com>. Never put the user's own address in From.

3. If you must send from your own server

Give its IP a PTR record that resolves back to the same IP, as Google requires, and check it with the PTR Lookup. Check the IP against public lists with the Blacklist Checker. On shared hosting you usually can't control either, which is the strongest argument for a transactional service. Shared vs dedicated IPs explains the trade-off.

4. Keep the message plain and predictable

A short subject such as "Reset your Example password", your brand name, one link to your own domain, a plain-text part, and no attachments. Don't use link shorteners. Send only the email the user asked for.

5. Handle bounces and typos

Ask users to confirm their address at signup, and process bounce events. A hard bounce on signup usually means a typo; prompt the user to correct it rather than leaving the account stuck. Hard bounce vs soft bounce explains which failures are permanent.

What should you tell users while you fix it?

Give them something to do instead of waiting:

• Check spam and junk, and search for your brand name.
• At work, ask IT to check the quarantine and allow your sending domain.
• Wait a few minutes before requesting another link.
• Contact support through a channel that doesn't depend on that email.

Next steps

1. Trigger a reset to your own Gmail and Outlook addresses and read the Authentication-Results headers.
2. Send a test through your app's mail settings to the free Email Deliverability Test and fix every failed check.
3. Move reset and verification mail to an authenticated transactional service on a subdomain with SPF, aligned DKIM and DMARC.
4. Lengthen link lifetimes enough to survive a retry, and throttle resend requests.
5. If your business systems send notifications from your own domain, iBlockSpam's outbound relay DKIM-signs them, with 500 messages a month included; high-volume app mail belongs on a dedicated transactional service.

Browse more guides on running email day to day.