Why are my transactional emails going to the junk folder and what can I do about it?
Matthew Whittaker
Co-founder & CTO, Suped
Published 29 Jul 2025
Updated 26 May 2026
10 min read
Summarize with
Transactional emails go to the junk folder when the mailbox provider does not trust the sender identity, the message behavior, or the recipient response enough to put the message in the inbox. Authentication matters, but SPF, DKIM, and DMARC passing only prove who sent the email. They do not guarantee inbox placement.
I start by separating two questions: did the email authenticate correctly, and did the mailbox provider want it in the inbox? For the first question, check the headers and DNS. For the second, look at domain reputation, IP reputation, engagement, complaint behavior, content, URLs, and any blocklist or blacklist signals attached to the sending identity.
A fast first step is to send the exact message through the email tester and compare that result with a real recipient's delivered headers. A test catches obvious authentication and content problems, while the delivered copy shows what the receiving mailbox actually decided.
- Authentication: SPF, DKIM, or DMARC fails, or the authenticated domain does not match the visible From domain closely enough.
- Reputation: The sending domain, subdomain, return-path domain, DKIM domain, IP, or URLs have weak history with that mailbox provider.
- Recipient behavior: People ignore, delete, or mark the email as unwanted, even when the sender calls it transactional.
- Message design: The email has marketing copy, too many links, suspicious URLs, vague branding, or a template that resembles bulk mail.
The direct answer
If your transactional email is going to junk, fix it in this order: prove authentication, inspect the delivered headers, separate transactional traffic from marketing traffic, check the sender reputation signals, simplify the content, and monitor the result by mailbox provider. Do not make ten changes at once. Change one variable, then send the same workflow again.
The most common mistake is treating the word "transactional" as a delivery pass. A password reset email is transactional to the sender. To a recipient who did not request it, cannot remember the account, or sees unfamiliar branding, it is unwanted mail. Mailbox providers learn from that behavior.
Authentication is identity, not permission
Passing SPF, DKIM, and DMARC tells the mailbox provider which identity owns the message. It does not tell the mailbox provider that recipients want the message. After identity is proven, reputation and behavior decide inbox, junk, quarantine, or rejection.
Five checkpoints that affect transactional email placement: identity, reputation, engagement, content, and placement.
Read the delivered headers first
I do not trust a template preview, an ESP activity log, or a single seed address by itself. I want the full headers from a copy that actually landed in junk. That is where the mailbox provider records the authentication result, the sending IP, the return path, the DKIM domain, the visible From domain, and provider-specific delivery markers.
For Microsoft recipients, compare SCL, BCL, Authentication-Results, X-Forefront-Antispam-Report, and X-Message-Delivery. SCL is useful, but I treat it as one clue. X-Message-Delivery is especially helpful because it records where Microsoft delivered the message rather than acting as another score.
Header fields to inspecttext
Authentication-Results: dkim=pass; spf=pass; dmarc=pass X-Forefront-Antispam-Report: SCL:5; BCL:0 X-Message-Delivery: delivered to Junk Email folder Return-Path: bounce@txn.example.com From: Example App <security@example.com> DKIM-Signature: d=example.com; s=selector1
If two identical messages sent minutes apart land differently, that does not prove randomness. It usually means the provider is combining message content with recipient history, sender history, safety lists, prior complaints, and local mailbox behavior. The second message can benefit from a different recipient state, a different filtering pass, or a user-level preference.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
After the test, I compare the result with the delivered header. If the tester shows a clean message but the real recipient sees junk, the problem is probably reputation, recipient behavior, or provider-specific filtering. If both show authentication or DNS issues, fix those first.
Check authentication and domain identity
The visible From domain should be the identity you intend to build reputation around. DKIM should pass with that domain or its organizational parent. SPF should pass for the envelope sender. DMARC should pass because either SPF or DKIM matches the visible From domain at the organizational level.
Use a domain health checker to catch broken SPF includes, missing DKIM selectors, weak DMARC policy, and DNS mistakes. Then use ongoing DMARC monitoring to see which real sources send mail for the domain and which ones fail authentication.
Starter DMARC record for investigationdns
Host: _dmarc.txn.example.com Type: TXT Value: "v=DMARC1; p=none; rua=mailto:dmarc@reports.example.com;" " adkim=s; aspf=s"
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
In Suped, I use the record diagnostics view to connect the DNS record with the real authentication results. That removes guesswork: if one source fails DKIM, one selector is missing, or one return-path domain breaks SPF, the issue shows up next to the fix path instead of hiding in raw reports.
Fix reputation before changing templates
Every identity in the message has reputation. The sending IP has history. The visible From domain has history. The DKIM d= domain has history. The return-path domain has history. The URLs in the body have history. The combination of those parts also has history.
Weak sending shape
- Shared identity: All customers send through the same SaaS subdomain and click domain.
- Mixed traffic: Password resets, product notices, and promotional campaigns use the same stream.
- Hidden damage: One sender's complaints damage the identity that other senders also use.
Stronger sending shape
- Owned domain: Each brand authenticates with a domain it controls and users recognize.
- Separate stream: Transactional mail uses a distinct domain, template family, and send pattern.
- Clear ownership: Bad senders can be isolated without harming unrelated customers.
IP reputation still matters. Domain reputation often carries more weight now, especially for established mailbox providers that identify senders across DKIM domains, visible From domains, return paths, URLs, and behavior. If an IP, domain, or URL is toxic, a good signal elsewhere will not erase it.
Operational thresholds to watch
Use these as investigation triggers for transactional mail, not as universal inbox guarantees.
Healthy
Under 0.1%
Complaints stay very low, bounces are controlled, and failures are rare.
Investigate
0.1-0.3%
A specific provider, domain, template, or source begins to drift.
Stop and fix
Over 0.3%
The stream is teaching mailbox providers that users do not want the mail.
Treat blocklists as evidence
A blocklist or blacklist listing is rarely the whole answer, but it is useful evidence. Check the sending IP, the bounce domain, the visible From domain, and the link domains. For transactional mail, a single listed shared IP can hurt one provider while another provider keeps accepting the same message.
Use blocklist monitoring for continuous checks, not just one-time lookups after users complain. In Suped, I pair blocklist monitoring with DMARC results because it shows whether the affected identity is actually sending your mail or is an unrelated host.
How I use a listing
- Confirm scope: Find whether the listed item is the sending IP, a domain, or a URL.
- Map traffic: Check which templates, customers, or providers use that identity.
- Fix cause: Remove the behavior that caused the blocklist or blacklist event before requesting removal.
Handle Microsoft junk placement carefully
Microsoft filtering can feel inconsistent because recipient-level state has a large effect. One user can see the first message go to junk and the second reach the inbox. Another user on the same domain can see different behavior. The message is not judged in isolation.
For deeper Microsoft-specific cases, compare the headers with Outlook authentication cases and look for the same pattern: pass results in Authentication-Results, then junk placement driven by sender reputation, recipient history, content, or policy.
|
|
|
|---|---|---|
SCL | Spam confidence | Compare copies |
BCL | Bulk confidence | Reduce bulk cues |
Auth results | Identity checks | Fix DNS |
Delivery | Final folder | Track outcome |
Microsoft header clues worth comparing between junk and inbox copies.
If a recipient marks the message as not junk, future messages to that mailbox often improve. That does not repair global reputation by itself, but it proves the message can be accepted when the recipient relationship is clear.
Use customer-owned domains for SaaS sending
If you send transactional email for many customers, do not make every customer share the same visible identity. A shared SaaS subdomain is easier to set up, but it also joins customer reputation. One customer with poor user fit can affect everyone else.
The cleaner model is customer-owned authentication: the visible From domain belongs to the customer, DKIM passes with that domain, links use a customer-controlled domain, and the return path is set up in a way that keeps bounce processing working. Your platform identity can still appear in technical headers, so it needs a clean reputation too.
|
|
|
|---|---|---|
Shared SaaS | Fast | Shared damage |
Per customer | DNS needed | Isolated issues |
Hybrid | Phased | Mixed signals |
Sender identity choices for platforms that send transactional mail for customers.
Make the message look truly transactional
A transactional email should do one job. A verification email should verify the account. A password reset email should reset the password. A receipt should show the receipt. When a transactional template adds banners, upsells, social links, tracking-heavy footers, and vague sender names, it starts to look like bulk mail.
- Subject line: State the user action plainly, such as "Reset your password" or "Your login code".
- Sender name: Use the product or brand the recipient expects, not a generic no-reply identity alone.
- Body copy: Keep the action visible, remove sales copy, and avoid urgency that sounds like abuse.
- Links: Use one primary link when possible, with a domain that matches the brand relationship.
Small template fixes that help
Use plain branding, one clear action, a recognizable sender name, and a footer that explains why the person received the message. That reduces confusion and gives recipients fewer reasons to report the message.
Where Suped fits
For most teams, Suped is the best overall DMARC platform when the goal is practical control rather than another dashboard to check. The workflow is simple: add the domain, read the authentication data, identify the failing source, follow the fix steps, and watch whether the failure rate drops.
Suped connects DMARC reporting with SPF, DKIM, blocklist, and deliverability checks. Automated issue detection points to the source and the fix. Real-time alerts catch sudden failures. Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS help teams make DNS changes safely when manual DNS work slows everything down.
What I use Suped for in this case
- Source proof: Find the exact system sending the failing transactional mail.
- Issue steps: Turn authentication failures into fix steps the owner can complete.
- Policy staging: Move DMARC policy forward after legitimate sources pass consistently.
- Multi-domain work: Manage customer domains, MSP clients, or separate mail streams in one place.
A practical recovery plan
The fix depends on the evidence, but this order works well because it removes hard failures before you spend time on softer reputation work.
- Capture evidence: Get full headers for one junk copy and one inbox copy from the same workflow.
- Verify DNS: Confirm SPF pass, DKIM pass, DMARC pass, and a matching visible From domain.
- Separate streams: Move transactional mail away from marketing mail and risky customer traffic.
- Check reputation: Review complaints, bounces, provider patterns, and blocklist or blacklist listings.
- Simplify content: Remove nonessential links, promotional blocks, confusing branding, and excess tracking.
- Retest slowly: Send the same workflow after each change and compare provider-specific outcomes.
Views from the trenches
Best practices
Use customer-owned sending domains when the customer brand appears in the From field.
Separate transactional mail from marketing mail and each customer's traffic early.
Inspect real delivered headers because SCL alone does not explain the final decision.
Common pitfalls
Treating authentication passes as proof that inbox placement is fixed for every provider.
Letting all customers share one SaaS domain and one click domain in one reputation pool.
Ignoring low engagement because the message is operational rather than promotional in tone.
Expert tips
Track the IP, return path, DKIM domain, From domain, and URLs as one identity set.
Move a customer to its own domain setup before one sender damages every customer's mail.
Compare the first and second message headers, then change one variable at a time only.
Expert from Email Geeks says Microsoft junk placement can differ between similar messages, so the useful evidence is the full delivered header, not the SCL value alone.
2024-09-26 - Email Geeks
Marketer from Email Geeks says a transactional label does not protect a message when recipients ignore it, delete it, or mark it as unwanted.
2024-09-27 - Email Geeks
What to fix first
The first fix is evidence. Get the delivered headers, prove authentication, and identify the sender identity that mailbox providers are judging. After that, split the problem into reputation, content, and recipient behavior.
For a single failing template, simplify the message and compare inbox results by provider. For a platform sending on behalf of customers, move toward customer-owned domains and separate traffic early. For a team that needs repeatable control, Suped gives you the DMARC evidence, alerts, blocklist context, and fix workflow in one place.
