Why password reset emails go to spam (and how to fix it)

"The reset email went to spam" covers three different failures, and they have different fixes. Before changing anything, find out which one you have.

A 200 from your email API means the message was accepted for delivery, not that it reached the inbox. Wire delivery, bounce and suppression webhooks into your logs so support can answer "did we send it, and what did the receiving server say?" without guessing. On Groundmail those are email.delivered, email.bounced, email.delivery_delayed and email.suppressed (webhooks docs).

This is the most common cause and the first thing to check. Gmail, Outlook and Yahoo expect transactional mail to be authenticated, and Google and Yahoo now require SPF, DKIM and DMARC from bulk senders (sender requirements). Unauthenticated mail is filtered hard or rejected.

Passing SPF and DKIM isn't enough on its own. DMARC also needs them to align with the domain in the visible From address. Three different domains are involved in every message:

The classic failure: the From address says no-reply@example.com, but the message is DKIM-signed with the email provider's own domain and the return path is the provider's bounce domain. SPF passes and DKIM passes, but neither aligns, so DMARC fails. Reading the headers is the only way to see this; the email itself looks fine.

The fix is to verify your own domain with your provider, so it signs with d=example.com and uses a return path under your domain. Full setup, with copy-paste records, is in SPF, DKIM and DMARC for transactional email.

Mailbox providers keep a reputation for your sending domain, built from the DKIM-signed mail that carries it. A domain registered last week has no history, and receivers treat unknown domains cautiously. If you launched on a new domain, expect some early filtering until real users open and act on your mail.

Sending transactional mail from a subdomain, such as mail.example.com or notify.example.com, gives it a reputation that is partly separate from the root domain. If your marketing team sends newsletters from example.com and someone's campaign draws complaints, your resets on mail.example.com are better insulated. Keep the subdomain for transactional mail only, and keep the From address recognisably yours: no-reply@mail.example.com is fine; an unrelated domain is not.

Most providers send small senders' mail from shared IP pools. The IP reputation is the sum of everyone on the pool, so if the pool also carries cold outreach or bulk newsletters, someone else's complaint rate follows your resets. You can do everything right on your own domain and still inherit a bad neighbourhood.

Ask your provider what its shared IPs are allowed to carry. If the answer is "anything", that is worth knowing when resets land in spam with clean headers.

Filters look hard at links in messages that ask someone to act on their account, because that is exactly what phishing does. A reset email whose links point somewhere the sender doesn't is a red flag.

Content matters less than authentication and reputation, but a few habits help, and they also help the user act quickly.

How you send matters as much as what you send. Three patterns cause trouble:

Email providers keep a suppression list of addresses that hard-bounced or complained, and refuse to send to them again. That protects your reputation, but it means a user whose address bounced once (a typo they later fixed at their mail host, a full mailbox misread as permanent, an old complaint) will never receive a reset, and nothing looks wrong in your app unless you check.

When a user says "I never got it", check the suppression list before anything else. On Groundmail, a send to a suppressed address returns 422 with the address in details.suppressed and emits an email.suppressed webhook, so you can log it and show support a clear reason. Look an address up with GET /suppressions?email=..., and once you've confirmed the address now works, remove it with DELETE /suppressions?email=....

B2B products hit a separate set of problems. Microsoft 365 with Defender, and other secure email gateways, can quarantine a message so it never reaches the junk folder at all: the user often sees nothing, and usually only their admin can release it. If one customer's whole domain reports missing resets, ask their IT team to check quarantine and, if needed, allowlist your sending domain. Fixed sending IPs make that conversation easier, which is one reason B2B senders move to dedicated IPs.

These gateways also scan links. Many open each URL in a message, at delivery or at click time, to check where it leads. If your reset link consumes the token on a GET, the scanner uses it up and the user gets "this link has expired".

Groundmail is transactional email on our own mail servers and our own IP space, with a transactional-only shared pool on every plan and dedicated IPs or dedicated servers when you need isolation. Domains are verified with SPF, DKIM and a return-path CNAME under your domain, so mail is signed as you and aligns for DMARC. Open and click tracking are off by default on new domains; leave click tracking off on any domain that carries auth mail.

This sends a reset with a text part, a link straight to your own domain, and an idempotency key tied to the token so retries can't send duplicates:

A retry with the same key and the same body returns the original response instead of sending a second email. If a domain had click tracking turned on, turn it off with PATCH /domains/{id} and {"click_tracking": false} (domains docs).