Why are my transactional emails going to the junk folder and what can I do about it?
Published 29 Jul 2025
Updated 9 Oct 2026
13 min read
Summarize with
Updated on 9 Oct 2026: We updated our recommendations for transactional bounce handling, DMARC setup, and current mailbox-provider filtering requirements.
Transactional emails go to the spam or 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 confirm authenticated domains and DMARC alignment. They do not identify a person or guarantee inbox placement.
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 Suped's email tester and compare that result with a real recipient's delivered headers. A test catches obvious authentication and infrastructure problems, while the delivered copy shows the receiving mailbox's results.
- Authentication: SPF or DKIM fails, or neither passing mechanism has DMARC alignment with the visible From domain.
- 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.
What to fix first
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.
What authentication proves
Passing SPF, DKIM, and DMARC tells the mailbox provider which domains authenticated the message and whether DMARC alignment passed. It does not tell the mailbox provider that recipients want the message. After identity is established, reputation and behavior affect inbox, junk, quarantine, or rejection.
Transactional email passing identity, reputation, engagement, and content checks before inbox or junk placement.
Read the delivered headers first
Do not rely on a template preview, an ESP activity log, or a single seed address by itself. Get 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. Check what your ESP calls 'delivered': SMTP acceptance still needs recipient-side confirmation of inbox placement. Match Message-ID and timestamps to sending logs; check quarantine and mailbox rules when no inbox or junk copy exists.
For Microsoft recipients, compare Authentication-Results, X-Forefront-Antispam-Report, X-Microsoft-Antispam, and X-Microsoft-Antispam-Mailbox-Delivery when present. SFV records the filtering verdict, CAT identifies the threat category, and DIR indicates message direction. BCL is the bulk complaint level. In Microsoft 365 cloud filtering, SCL alone does not determine the action; use CAT, DIR, and the applied policy. Where stamped, dest:I indicates inbox delivery and dest:J indicates junk delivery. See Microsoft header guidance for documented fields.
Illustrative header excerpts to inspecttext
Authentication-Results: mx.receiver.example; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=txn.example.com; dmarc=pass header.from=example.com X-Forefront-Antispam-Report: SCL:5; SFV:SPM; CAT:SPM; DIR:INB X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Mailbox-Delivery: dest:J Return-Path: <bounce@txn.example.com> From: Example App <security@example.com> DKIM-Signature: ... d=example.com; s=selector1; ...
If two messages from the same workflow land differently, compare their sending IPs, authenticated domains, and message content before attributing the difference to recipient behavior. Check whether mailbox rules, Safe Senders, or administrator policies changed. Folder differences alone do not identify the cause.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After the test, compare the result with the delivered headers. A clean test does not rule out authentication failures on the production route. If the junk copy also passes authentication, investigate reputation, recipient behavior, and provider-specific filtering. Fix any authentication or DNS problems visible in either copy first.
Check authentication and domain identity
The visible From domain should be the identity you intend to build reputation around. DKIM should pass with a signing domain that matches it under DMARC, and SPF should pass for the envelope sender. DMARC passes when at least one mechanism passes and its domain matches the visible From domain under the configured alignment mode. Relaxed alignment permits an organizational-domain match, while strict alignment requires an exact domain match.
Use a domain health checker to check SPF and DMARC records and general DNS health. Check the DKIM selector actually used in the delivered signature; a domain lookup alone does not discover every selector. Then use ongoing DMARC monitoring to see which reported sources send mail for the domain and which fail authentication.
Monitoring DMARC example for a From address at example.comdns
Host: _dmarc.example.com Type: TXT Value: "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Use this example only when the domain has no valid DMARC record; preserve an existing enforcement policy. Replace the report address with your assigned reporting destination. The omitted adkim and aspf tags default to relaxed alignment under RFC 9989. This lets the example return path at txn.example.com match the visible From domain at example.com.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
A p=none policy meets the minimum DMARC policy requirement for covered high-volume senders, but their messages must still pass DMARC. It requests no quarantine or rejection based on DMARC failure; the rua destination enables reporting. Suped's record diagnostics view connects the DNS record with real authentication results so you can identify failing sources and investigate the relevant DKIM selector or SPF domain.
Check infrastructure and volume changes
Authentication does not replace basic sending infrastructure. Gmail and Yahoo require valid forward and reverse DNS for sending IPs, and Gmail requires TLS. Message formatting also needs to comply with SMTP and Internet Message Format standards. A clean DMARC result does not compensate for broken PTR records, a mismatched server identity, or malformed mail. See Gmail sender requirements for DNS, TLS, and formatting requirements.
Compare the sending pattern immediately before junk placement started. A new domain or IP, a changed DKIM signing domain, a new return path, or an abrupt volume increase can remove useful history or trigger throttling. Increase real, expected transactional traffic gradually on a new identity, and reduce the rate when deferrals or temporary failures rise. A dedicated IP is not an automatic fix for low-volume transactional mail; it needs a consistent sending history, and domain problems persist after an IP change.
- Forward and reverse DNS: The sending IP's PTR hostname should resolve forward to the same IP.
- SMTP identity and TLS: Use a resolvable HELO or EHLO hostname and an encrypted connection.
- Volume and cadence: Avoid sudden spikes after moving infrastructure, changing headers, or launching a new workflow.
- SMTP responses: Track hard bounces, soft bounces, deferrals, and provider error codes instead of retrying every failure at the same rate.
Protect recipients and transactional workflows
For transactional mail, list hygiene means sending the right event to a valid recipient. Repeated account-verification reminders, unexpected password resets, and automated retries generate complaints even when authentication passes.
- Bounce suppression: Stop sends to addresses with permanent invalid-recipient errors such as 5.1.1. Classify 5.7.x authentication or policy rejections separately so a sender problem does not erase a valid customer address.
- Complaints and preferences: Process available complaint feedback and stop optional notifications the recipient does not want. Investigate unexpected account messages rather than continuing the same automated sends.
- Workflow abuse: Rate-limit signup and password-reset requests by recipient and source. Confirm address ownership before starting ongoing notifications, and prevent repeated sends to someone who did not initiate the action.
- Retries and duplicates: Retry temporary 4xx failures with backoff and a limit. Deduplicate messages by application event, and stop retrying login codes or reset links after their useful lifetime expires.
Track successful account verifications and completed password resets alongside delivery errors. Tracking-pixel open rates are unreliable evidence of inbox placement; do not suppress necessary account mail solely because no open was recorded. Give users control over optional notifications.
Separate transactional and marketing sender reputation
The sending IP, visible From domain, DKIM signing domain, return-path domain, and link domains all contribute to sender reputation. Shared identities connect otherwise separate customers or mail streams.
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 sending subdomain or stream; use separate IP pools where practical.
- Clear ownership: Customer-specific issues are easier to isolate, while shared IP reputation still affects other customers.
Both domain and IP reputation matter; their relative weight varies by mailbox provider. A dedicated transactional subdomain helps organize traffic and reporting, but providers still associate related domains or shared infrastructure. Check link-domain reputation as well as the sender identities.
Google recommends keeping its user-reported spam rate below 0.1% and avoiding 0.3% or higher. Yahoo requires a complaint rate below 0.3%. These provider rates use their own denominators; an ESP complaint rate is not automatically equivalent. See Gmail sender requirements and Yahoo sender requirements.
Provider spam complaint thresholds
These bands use provider-reported spam complaint rates. They are investigation triggers, not inbox-placement guarantees or universal ESP benchmarks.
Target
Below 0.1%
Google's recommended spam-rate target; inspect bounces and authentication separately.
Investigate
0.1% to below 0.3%
Above the recommended Gmail target; identify the affected workflow and provider.
Stop and fix
0.3% or higher
At or above the provider ceiling; stop the problematic optional stream and address the cause.
Treat blocklists as evidence
A blocklist (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. Use Suped's DMARC data to compare a listed sending IP with sources in your reports. Investigate listed link domains separately because aggregate DMARC reports do not contain message-body URLs.
How to 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 Outlook.com consumer domains, Microsoft requires high-volume senders to pass both SPF and DKIM and to pass DMARC with at least a p=none policy. Its 550 5.7.515 support guidance identifies domains sending 5,000 or more messages as high-volume. Non-compliant mail is subject to rejection with 550 5.7.515. Passing those checks avoids that authentication failure, but reputation, content, policy, and recipient state can still put a compliant message in junk.
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 level | Do not infer the cloud action from SCL alone |
BCL | Bulk complaint level | Review bulk classification and recipient expectations |
SFV | Filtering verdict | Check whether filtering or a sender list supplied the verdict |
CAT and DIR | Threat category and message direction | Identify classification and compare applied policies |
Mailbox delivery | dest:I or dest:J, when present | Compare stamped delivery with current folder and mailbox rules |
Microsoft header clues worth comparing between junk and inbox copies.
A recipient can mark an expected message as not junk and add the sender to Safe Senders. That can improve placement for that mailbox, but it is a recipient-level workaround, not a repair for global sender reputation or authentication.
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 | Domain separation; shared IP risk remains |
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 recognizable HTTPS domain. Avoid URL shorteners and unnecessary click-tracking redirects on login or reset links.
Keep the action readable when images are blocked, use valid HTML, and include an equivalent plain-text part for recipients whose clients need it. Check MIME formatting and broken links; there is no universal image-to-text ratio that guarantees inbox placement.
Pure transactional messages such as password resets and one-time codes are excluded from Gmail and Yahoo one-click unsubscribe requirements. Recurring notifications and subscribed messages need preference controls when users can stop them. Classify the message by what it does, not by the label in the sending platform. The scope is explained in Gmail's unsubscribe FAQ and Yahoo's sender FAQ.
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.
Monitor authentication problems with Suped
Suped is our DMARC and email authentication platform. For this workflow, add the domain, review the authentication data, identify the failing source, assign the fix, and watch whether the failure rate drops.
Suped's issue detection and alerts help connect authentication failures to their sending sources. DMARC aggregate reports do not establish inbox placement, so compare Suped's authentication results with SMTP logs and recipient headers when diagnosing junk delivery.
What Suped covers 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. Authentication fixes can be checked promptly, while reputation recovery requires sustained improvement and ongoing provider-specific monitoring.
- Capture evidence: Get full headers for one junk copy and one inbox copy from the same workflow.
- Verify DNS: Confirm SPF and DKIM results, DMARC alignment and pass, and valid forward and reverse DNS using the actual sending identities.
- Separate streams: Move transactional mail away from marketing mail and risky customer traffic.
- Protect recipients: Suppress invalid-recipient bounces, investigate policy rejections separately, and rate-limit user-triggered workflows that can be abused.
- 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.
