Why Transactional Mail Lands in Spam — and the Fixes
Your receipts and password resets are ending up in spam. Here are the causes that actually matter — authentication, reputation, content — ranked by how much they move the needle.
"Our password resets are going to spam" is one of the most common — and most fixable — deliverability complaints. It's also one where people reach for the wrong lever first, spending a day rewriting copy when the actual problem is a missing DNS record. Inbox placement is decided by a handful of signals, and they're not equally weighted. This is those signals, ranked, so you fix the thing that matters before the thing that doesn't.
People rewrite the subject line when the real problem is an unaligned DKIM signature. Fix the signals in order of weight, not in order of how easy they are to change.
Rank the causes before you touch anything#
| Cause | Impact | Typical fix |
|---|---|---|
| Not authenticated / not aligned | Highest | SPF + DKIM aligned to From:; publish DMARC |
| Shares domain/reputation with bulk mail | High | Isolate transactional onto its own domain/subdomain |
| Weak or cold sending-domain reputation | High | Warm up; send consistently; a reputable provider's infrastructure |
| Dead addresses / complaints not suppressed | Medium-High | Suppress bounces and complaints; keep spam rate < 0.3% |
| Message looks like marketing | Medium | Text-first, minimal HTML, no image-only, sane links |
From: / reply-to inconsistency | Medium | Consistent, real, authenticated From: domain |
| No PTR / broken reverse DNS | Medium | Valid PTR matching forward DNS |
Notice the top of the table is infrastructure, not copy. That ordering is the single most useful thing here.
1. Authentication (and alignment — not just presence)#
The biggest single reason legitimate transactional mail gets filtered is that it isn't provably from you. Mailbox providers want SPF or DKIM to pass and align with the domain in the visible From: address, backed by a DMARC policy. "We have SPF" isn't enough if it doesn't align to your From:.
Get the basics right (the foundations are in the existing SPF, DKIM and DMARC minimum guide):
- DKIM signing on your
From:domain, aligned. - SPF listing every service that sends as your domain, aligned.
- DMARC published — at least
p=none, advancing toward enforcement (see DMARC rollout).
A provider that authenticates your domain does most of this for you, but the DNS records are yours to publish. This step alone rescues a large share of "going to spam" cases.
2. Isolation from bulk mail#
If your receipts and your newsletters leave from the same domain, they share one reputation — and the newsletter's spam complaints drag the receipts down with them. Time-critical transactional mail should not inherit the volatility of marketing sends. Move it to its own domain or subdomain so its reputation is built only on mail people actually want and expect. (We cover the mechanics in when to split sending domains.) This is the highest-impact change after authentication, and it's structural — no amount of content tuning substitutes for it.
3. Reputation: cold and inconsistent domains get filtered#
A brand-new sending domain has no reputation, and a burst of mail from it looks risky. Two habits help:
- Warm up. Ramp volume gradually on a new domain/IP rather than launching at full blast.
- Send consistently. Erratic volume (nothing for weeks, then a spike) reads worse than a steady pattern. Transactional mail is naturally steady, which works in your favour once the domain is established.
Sending through a provider whose infrastructure already has standing reputation shortens the cold-start, but your domain's own history still matters.
4. List hygiene: stop mailing the dead and the annoyed#
Every hard bounce you re-send to, and every complaint you ignore, is a signal that you don't maintain your list — and providers act on it. Keep your spam complaint rate under 0.3% (Gmail's stated line) by suppressing hard bounces and complaints the moment the webhook fires (see bounce & complaint handler). Clean-list senders get the benefit of the doubt; dirty-list senders get the spam folder.
5. Content: make it look like a system message, not a campaign#
This is last on the list for a reason — it's real, but it's rarely the dominant cause. Still, don't sabotage yourself:
- Text-first, light HTML. A receipt or code shouldn't look like a promo blast.
- No image-only messages. A message that's one big image with almost no text is a classic spam pattern.
- Sane links. Avoid link shorteners and mismatched display-vs-actual URLs; keep the count low.
- Skip tracking on OTP. A tracking pixel on a verification code adds nothing and can hurt.
- Consistent, real
From:. A stable, authenticated sender address people recognise beats a rotating cast of addresses.
A troubleshooting order that works#
When something's landing in spam, work top-down:
- Check authentication first. Send a test to a seed address and inspect headers: does SPF pass and align? DKIM? Is DMARC published? Most cases end here.
- Check isolation. Is this domain also sending marketing? If so, that's likely your reputation drag.
- Check the complaint/bounce rate in Postmaster Tools. Over 0.3%, or trending up? Fix suppression.
- Only then look at content. If 1–3 are clean and it's still filtered, examine the message shape.
Doing this in order saves you from rewriting copy to fix a DNS problem.
Example scenario: the receipt in the spam folder#
(Illustrative scenario, not a customer case.) Users report that order receipts land in spam. The team's first instinct is to rewrite the subject and trim the template — a day's work, no change. A header inspection then shows the receipts are DKIM-signed for the provider's domain, not aligned to the app's From: domain, and no DMARC is published. Two DNS changes later — aligned DKIM and a p=none DMARC record — placement recovers. The copy was never the problem; the mail simply couldn't prove it was from them. Checking authentication first would have found it in ten minutes.
Editorial disclosure: Drafted with AI assistance; reviewed, fact-checked and edited by Alkım Kaplaner. Next scheduled review: .
Frequently asked questions
Why is my transactional email going to spam?
Most often because it isn't authenticated and aligned — SPF/DKIM not matching your From: domain, or no DMARC — or because it shares a domain and reputation with bulk mail that draws complaints. Weak domain reputation, un-suppressed bounces, and marketing-like content follow. Check authentication before anything else.
Does rewriting my email content fix spam placement?
Rarely on its own. Content is a real but lower-weight signal. If your mail isn't authenticated or shares a domain with complaint-heavy bulk sends, no subject-line change will rescue it. Fix authentication and isolation first; tune content only once those are clean.
Should transactional and marketing email use the same domain?
No, ideally. Sharing a domain means sharing reputation, so marketing complaints can send your receipts and resets to spam. Isolating transactional mail on its own domain or subdomain protects the mail that must arrive. It's the highest-impact change after authentication.
How do I check why a specific email went to spam?
Send a test to a seed inbox and inspect the headers: confirm SPF passes and aligns, DKIM passes and aligns, and DMARC is published. Check your complaint rate in Postmaster Tools. Work top-down through authentication, isolation, reputation, then content.
How much does sender reputation matter for transactional mail?
A lot. Providers meter unfamiliar or cold domains and filter senders with rising complaint rates. Transactional mail's naturally steady volume helps once a domain is established, but a new domain needs warming and a clean complaint record to earn inbox placement.
Send transactional email you can rely on
Notifiva gives you a REST API and an SMTP relay, SPF/DKIM signing, delivery webhooks and per-message logs — so the mail your users are waiting on actually arrives.