Key takeaways
- Accepted by the receiving server is not the same as inbox placement. Your API
200can still mean spam folder. - Fix authentication and alignment before rewriting subject lines — unauthenticated or misaligned mail fails modern gates.
- Complaint rate and unknown/invalid recipients poison reputation faster than “spammy words” ever did.
- Shared IP and shared-domain neighbours can put your transactional mail in spam even when your content is clean.
- Recovery is slow: reduce volume, fix root causes, then ramp. There is no appeal form that undoes a week of bad signals.
When a password reset or receipt goes to spam, users blame your product. Internally, teams often blame subject lines, “spam words,” or a flaky ESP. Those can matter at the margin. They are rarely the primary cause in 2026.
Mailbox providers decide placement with layered signals: whether you are allowed to send as the domain you claim, how similar senders have behaved on related IPs and domains, how recipients engage, and whether the message looks like abuse. The decision is probabilistic and mostly opaque — which is why random A/B tests on subject lines feel productive while the real problem sits in DNS or list hygiene.
This guide is for product and engineering teams sending transactional mail. Pair it with the broader email deliverability playbook and the bounces and suppression guide when you are ready to operationalize the fixes.
Spam folder is not a bounce
A bounce means the receiving server rejected or deferred the message at SMTP time. Spam placement means the message was accepted and then filed where users rarely look. Your application may record both as “delivered” if you only watch acceptance webhooks.
| Symptom | What it usually means | Where to look first |
|---|---|---|
| Hard bounce / 5xx | Address or policy permanent failure | Suppression list, SMTP codes |
| Soft bounce / 4xx | Throttle, greylist, temporary outage | Volume, IP reputation, retry logic |
| Accepted but missing | Spam folder, promotions, delayed filter | Auth, domain reputation, complaints |
| Works for some domains only | Provider-specific reputation or policy | Gmail vs Microsoft vs Yahoo separately |
Cause 1: authentication and alignment failures
Since 2024–2025, major consumer mailbox providers enforce SPF, DKIM, and DMARC expectations for bulk and many automated streams. Misconfiguration no longer just “hurts deliverability” — it can produce outright rejection or automatic junk placement.
- SPF fails when the sending IP is not authorized for the envelope domain, or the record is broken / over the lookup limit.
- DKIM fails when signatures do not verify — wrong selector, rotated key not published, or body modified in transit by a buggy relay.
- DMARC alignment fails when SPF/DKIM pass for a domain that does not align with the visible
From:domain. - Domain mismatch — marketing tool sends as
marketing.example.comwhile the product sends asexample.comwithout a coherent policy.
Fix DNS before debating copy. The SPF, DKIM, and DMARC guide walks alignment rules and common breakage. For transactional streams, prefer a dedicated sending subdomain so marketing never shares the signing identity.
Cause 2: domain and IP reputation
Reputation is the accumulated memory mailbox providers keep about your domain and the IPs you send from. New domains are unknown. Domains that suddenly spike volume look risky. Domains that generate complaints look abusive. Unknown plus noisy is the fastest path to spam.
Shared pools and noisy neighbours
On a shared IP pool, you inherit some of the behaviour of everyone else on those addresses. A free tier full of abandonable accounts is a structural risk. If your transactional mail shares fate with strangers’ blasts, spam placement can appear “for no reason” from your application’s point of view. That is a primary reason to prefer a transactional-only pool or Dedicated infrastructure.
Cold IPs and sudden volume
A brand-new dedicated IP with yesterday’s full production volume is a classic self-inflicted spam event. Warm gradually. See IP warmup. The same logic applies, more gently, to a brand-new sending domain on already-warm IPs.
Cause 3: who you send to
Sending to invalid addresses, role accounts that never engage, purchased lists, or old unengaged marketing cohorts trains filters that you are careless. For transactional mail the list should be “people who just did something in the product” — still, bugs that retry forever against hard bounces recreate marketing-list failure modes.
- Suppress hard bounces immediately at send time.
- Cap soft-bounce retries; then suppress.
- Never send marketing-style blasts from the transactional subdomain.
- Treat spam complaints as urgent — keep rates well under 0.10%.
- Do not “re-permission” cold addresses through your transactional identity.
Operational detail lives in bounces, complaints, and suppression. The short version: hygiene is deliverability.
Cause 4: content and user signals (after the basics)
Content still matters, but mostly as a secondary scorer once authentication and reputation are in range. Misleading subject lines, deceptive From names, broken HTML, malware-like URL patterns, and huge image-only bodies can push borderline mail into spam. User signals matter more: deletes without reading, junk button, and lack of opens over time.
- Match the From name and domain users expect for your product.
- Make auth and receipt subjects specific and honest — not clickbait.
- Include a plain-text part; keep HTML simple for transactional templates.
- Use links on domains you control; avoid URL shorteners in auth mail.
- For password resets, prioritize speed and clarity over branding flourishes — see authentication emails.
A diagnostic order that saves weeks
- 1
Segment by mailbox provider
Is the problem Gmail-only, Microsoft-only, or universal? Provider-specific failures point to reputation and policy; universal failures often point to auth or content.
- 2
Verify SPF, DKIM, and DMARC alignment
Use the headers from a message that landed in spam. Confirm pass/fail and alignment against the visible From domain.
- 3
Check bounce and complaint rates
Spikes correlate tightly with junk placement. Fix list bugs and suppressions before increasing volume.
- 4
Inspect shared vs dedicated identity
If you are on a mixed pool or shared marketing identity, plan isolation — subdomain + pipe separation — not another subject-line test.
- 5
Only then tune templates
Simplify HTML, clarify subjects, remove suspicious link patterns. Re-test with seeds across providers.
If you operate SuperSend TX, domain authentication in the dashboard and event webhooks give you the raw materials for steps two and three. Pool traffic stays on transactional infrastructure; Dedicated adds managed isolation when neighbour risk is unacceptable. Product overview: transactional email API.
Write down what you learn in an internal incident note: which provider, which sending subdomain, which auth results, and which rate moved. The next spam scare goes faster when the last one left a paper trail.
How to recover after a spam incident
Reputation recovers slower than it burns. Acting like nothing happened and “pushing through” usually deepens the hole.
- Pause non-essential volume on the damaged identity.
- Fix authentication, suppression, and any acquired-list behaviour immediately.
- Keep sending highly wanted transactional mail (auth, receipts) at reduced volume if the identity must stay warm.
- Watch provider-specific feedback for days, not hours, before ramping.
- If the identity is badly poisoned, move transactional mail to a clean subdomain and warm deliberately rather than waiting forever on a burned domain.
Send transactional mail on a pipe built for it
Authenticate a domain, keep marketing off your transactional identity, and send from Pool or Dedicated infrastructure designed for messages that cannot miss.
Related reading