Why do my password reset emails go to spam?

Most often because transactional mail shares a sending domain with marketing mail. Complaint rates from campaigns attach to the domain, and the password resets inherit them. The other common causes are a DKIM signature that does not align with the From domain, a missing or unenforced DMARC policy, and a sending IP whose reputation was earned by someone else in a shared pool.

How do I stop transactional email going to the spam folder?

Separate transactional from marketing at the domain or subdomain level, make sure SPF, DKIM and DMARC all align on the service actually doing the sending, publish a DMARC policy stronger than p=none, and read your bounces. An audit tells you which of these is your problem rather than making you do all four blind.

Should transactional email use a subdomain?

Usually yes. A subdomain separates the reputation of your receipts and password resets from your campaigns, so one bad send does not take the other down with it. It is not free — a new subdomain starts with no reputation and has to warm up — which is why the answer depends on what you send today.

Does an email deliverability audit cover my sending provider?

Yes. The audit is stack-agnostic: SES, Postmark, SendGrid, Mailgun, Google Workspace, Microsoft 365, or your own Postfix or Exim. The protocols are the same everywhere and the protocols are what gets read.

Password resets and receipts landing in spam

Transactional mail fails quietly. Nobody complains that their receipt didn't arrive — they just don't come back, or they open a ticket about something else. By the time it shows up in a metric, it has been happening for weeks.

What this usually looks like

Password reset emails arriving in spam, or not at all
Signup confirmations delayed by minutes or hours
Receipts and invoices reaching some providers and not others
Support tickets that begin "I never got the email"

What the audit checks for this

Every audit covers the same ground. These are the parts that decide this one.

Whether transactional mail shares a domain with marketing — the single most common cause, because one campaign's complaint rate drags the password resets down with it
SPF, DKIM and DMARC alignment on the service actually doing the sending, which is often not the one you think
The bounce path: where rejections go, and whether anything reads them
Whether the sending IP or the shared pool has a reputation problem
Both the IPv4 and IPv6 paths, with reverse DNS on each

What this will not do

It will not fix an outage at your sending provider.
It will not raise a reputation that was earned by past sending; it will tell you whether reputation is the problem or whether the setup is.

Two SPF records, and everything fails at once

This is the most expensive five minutes in deliverability, because every free checker reports it differently and none of them say what it costs. A domain added a transactional provider without noticing it already had an SPF record.

```
$ dig +short TXT example.com | grep spf
```
```
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:sendgrid.net -all"
```
Two records. RFC 7208 says a domain publishes exactly one, and that a receiver finding more must return permerror — not a soft failure, not a merge of the two.
```
$ dig +short TXT _dmarc.example.com
```
```
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
```
DMARC is set to reject. On its own this is correct and responsible, and here it is what turns a DNS mistake into refused mail.

SPF returns permerror, so it cannot align. If DKIM is not also signing and aligning — and on transactional providers it frequently is not — DMARC fails, and p=reject means the receiver refuses the message rather than filing it in spam. The password resets stop arriving entirely, no bounce reaches the application, and the dashboard at the sending provider shows the message as delivered to the relay. Deleting one TXT record fixes it.

Questions people ask about this

Why do my password reset emails go to spam?: Most often because transactional mail shares a sending domain with marketing mail. Complaint rates from campaigns attach to the domain, and the password resets inherit them. The other common causes are a DKIM signature that does not align with the From domain, a missing or unenforced DMARC policy, and a sending IP whose reputation was earned by someone else in a shared pool.
How do I stop transactional email going to the spam folder?: Separate transactional from marketing at the domain or subdomain level, make sure SPF, DKIM and DMARC all align on the service actually doing the sending, publish a DMARC policy stronger than p=none, and read your bounces. An audit tells you which of these is your problem rather than making you do all four blind.
Should transactional email use a subdomain?: Usually yes. A subdomain separates the reputation of your receipts and password resets from your campaigns, so one bad send does not take the other down with it. It is not free — a new subdomain starts with no reputation and has to warm up — which is why the answer depends on what you send today.
Does an email deliverability audit cover my sending provider?: Yes. The audit is stack-agnostic: SES, Postmark, SendGrid, Mailgun, Google Workspace, Microsoft 365, or your own Postfix or Exim. The protocols are the same everywhere and the protocols are what gets read.

Where this comes from

Everything above is checkable against the specifications that define it. These are the documents, not a summary of them.

RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Written by Philippe Namias, who runs the audit. Last reviewed August 2026.

Book the audit — €179

One domain, one report, by email within 48 hours of your intake. No account, no call.

Not sure it covers your setup? Ask before you buy: audit@strictmx.com