Password resets going to spam? You're sending them from the same IP and domain as marketing campaigns. The four operational fixes that actually work.
The Pattern That Causes This Problem
A typical SaaS company sets up email like this:
- One sending domain:
noreply@yourbrand.com - One ESP account: most often a marketing-focused ESP because that is what the marketing team chose
- One IP pool: shared, because the volume does not justify dedicated
- All streams routed through this setup: password resets, receipts, account notifications, marketing campaigns, product announcements, transactional alerts
For a while, this works. The mail delivers, recipients get their password resets, marketing campaigns reach the inbox.
Then a marketing campaign underperforms. The targeting was off, the content was weak, or the segment was tired. Complaint rate on that campaign hits 0.4%. Some recipients click spam. The sender's reputation drops.
The next morning, a customer cannot log in. The password reset they requested is in their spam folder. They contact support. Support investigates. Engineering checks the logs the email was sent successfully. Marketing checks their numbers the campaign performed below expectations but "nothing terrible happened." Nobody connects the two events.
Over weeks, the pattern repeats. Marketing campaigns occasionally drag reputation down. Transactional emails occasionally land in spam. The relationship is not obvious because the timing is offset and the events are tracked by different teams.
This is the most common deliverability problem I encounter in B2C and SaaS sender audits. The fix is structural, not tactical.
Why the Mixing Is the Cause
Mailbox providers do not differentiate between transactional and marketing mail at the reputation level. From Gmail's perspective, all mail from yourbrand.com is yourbrand.com mail. The complaint rate is calculated against total volume, and the reputation score applies to the next message regardless of its purpose.
When the marketing stream produces complaints:
- The domain reputation drops.
- The IP reputation drops (because the IP carried the marketing volume).
- The next transactional message sent from that domain and IP inherits the lower reputation.
- Inbox placement degrades for all mail, including the password reset.
The asymmetry is what makes this particularly damaging. Marketing campaigns produce most of the volume and most of the complaints. Transactional mail produces almost no complaints (recipients almost never mark "this is spam" on a password reset they actually wanted). But the transactional stream gets blamed in placement decisions because it shares reputation infrastructure with the marketing stream.
The result: the stream that should have the best reputation in your account—because it has the highest engagement, the lowest complaint rate, and the most explicit recipient consent gets dragged down by the stream that has the worst reputation profile.
Stream separation reverses this. When transactional has its own reputation infrastructure, the high engagement signals (every password reset is opened within minutes) build reputation faster than marketing can damage it. When the streams are commingled, the marketing damage outweighs the transactional benefit.
The Four Operational Fixes
These are the changes that resolve transactional-into-spam problems, in order of impact.
Fix 1: Separate Subdomains
The single highest-impact change. Send transactional from a subdomain dedicated to transactional mail.
Common patterns:
- Marketing:
news.yourbrand.comormail.yourbrand.com - Transactional:
tx.yourbrand.comoraccount.yourbrand.com - Notifications:
notify.yourbrand.com(if applicable)
The mechanics: each subdomain has its own SPF, DKIM, and DMARC. Each builds its own domain reputation independently. A complaint against news.yourbrand.com damages that subdomain's reputation; the transactional subdomain remains unaffected.
This is the architectural foundation. For the full guide on subdomain implementation.
Fix 2: Different IPs (or at Least Different Pools)
Domain reputation isolates one signal. IP reputation isolates another. For senders with enough volume to justify dedicated IPs, transactional should run on its own IP separate from marketing.
For senders below the dedicated-IP threshold (see The Hidden Cost of Shared IP Pools), the practical alternative is using ESPs with separate IP pools for transactional and marketing. Most major ESPs categorize their pools internally; a transactional API send through Postmark or Sendgrid's transactional pool goes through different IPs than marketing campaigns through the same provider's marketing pool.
Verify this with your ESP. The labels on the dashboards do not always reflect the underlying pool segmentation. Ask explicitly: "Are transactional sends through your API on different IPs than marketing campaigns through your UI?"
Fix 3: Transactional-Optimized Provider
Marketing-focused ESPs (Mailchimp, Mailjet, Campaign Monitor, Klaviyo) are built around campaign workflow segmentation UIs, A/B testing, reporting dashboards. They send transactional through APIs but transactional is not the focus.
Transactional-focused providers (Postmark, Mailgun, AWS SES, SendGrid Transactional) are built around individual-message delivery. Better latency, better error handling, better deliverability defaults for system-generated mail.
For senders running both streams at meaningful volume, using two providers is operationally clean:
- Marketing provider: for campaigns, segmented sends, A/B tests
- Transactional provider: for system mail, password resets, receipts, notifications
The cost of running two providers is real (two API integrations, two billing relationships) but small relative to the deliverability difference. For high-volume senders, the cost is rounding error. For smaller senders, a single ESP with separated IP pools is the cost-effective compromise.
Fix 4: Treat Transactional as the Priority Stream
This is the operational mindset change that supports the architectural changes.
Most companies treat transactional mail as a commodity it goes out, it works, nobody thinks about it. Marketing mail gets the attention because marketing teams have campaigns to optimize and metrics to report.
The mindset that produces clean deliverability inverts this. Transactional is the high-stakes stream because:
- Failures have direct user impact (cannot log in, missed receipt, security alert not received)
- Engagement signals are uniformly positive and high-value
- Complaint rate is essentially zero, so the reputation feedback loop is healthy
- Recovery from transactional reputation damage is much harder than from marketing damage
Operational implications:
- Transactional infrastructure gets first priority during deliverability incidents
- Transactional changes go through the same review process as production code changes
- Transactional reputation is monitored with tighter thresholds than marketing
- The team responsible for transactional includes engineering, not just marketing ops
Companies that treat transactional as the priority stream do not have transactional-into-spam problems for very long. The operational discipline catches issues early.
What Counts as Transactional vs. Marketing
The line is fuzzier than it seems, and the fuzziness causes problems.
Clearly transactional:
- Password reset
- Account verification email
- Two-factor authentication codes
- Order confirmation, shipping notification
- Receipt for a payment
- Direct support ticket replies
Clearly marketing:
- Promotional newsletter
- Product announcement
- Discount campaign
- Drip sequences for nurture
- "We miss you" re-engagement
The gray zone:
- "Your weekly digest" (looks marketing, recipient explicitly subscribed)
- Product update emails ("here's what shipped this month")
- Onboarding sequences after signup
- Transactional emails with marketing content embedded ("here's your receipt, and check out these other products")
- Notification emails ("someone commented on your post")
The gray zone is where stream separation gets compromised. A team decides to "save infrastructure cost" by routing the weekly digest through transactional infrastructure. The digest accumulates complaints (because all bulk content does, eventually). The transactional reputation gets damaged. The password resets start landing in spam.
The discipline: anything that is bulk, scheduled, or promotional belongs on the marketing infrastructure. Anything that is system-generated, individual, and triggered by user action belongs on transactional. The gray zone goes to marketing infrastructure it is safer to over-classify as marketing than to under-classify and contaminate transactional.
How to Diagnose Whether Your Setup Has This Problem
Three signals that mixing is causing your transactional-into-spam issues:
1. Transactional inbox placement varies with marketing campaign timing. If your password reset deliverability degrades within 24 hours of major marketing sends, the streams are commingled. Compare bounce rates, support tickets about missing emails, and Postmaster Tools data against your campaign calendar.
2. Domain reputation in Postmaster Tools drops during marketing-heavy weeks. If reputation declines correlate with high marketing volume rather than with high overall volume, the marketing stream is the cause and the transactional stream is collateral damage.
3. Support tickets cluster around password reset failures. A spike in "I can't log in, the email never arrived" tickets often correlates with a recent marketing campaign that performed below expectations. The connection is rarely obvious to the team handling the tickets, but the pattern is consistent.
If two or three of these signals are present, your infrastructure is mixing streams in a way that is damaging transactional deliverability. The fixes above are the resolution path.
A Concrete Migration: From Mixed to Separated
A SaaS company sending 200,000 marketing emails per month and 500,000 transactional emails per month, all from mail@yourbrand.com through one ESP. Customer complaints about missed password resets are escalating.
Week 1: Diagnosis
- Confirm the pattern via support ticket analysis and Postmaster Tools correlation
- Identify the streams and current sending paths
Week 2: DNS and infrastructure preparation
- Add subdomains:
tx.yourbrand.comfor transactional,mail.yourbrand.comfor marketing - Configure SPF, DKIM, and DMARC for each subdomain
- Verify authentication with test sends
Week 3-4: Transactional cutover
- Configure the existing ESP (or migrate to a transactional-optimized provider) to send from
tx.yourbrand.com - Update application code to use the new sending domain for password resets, receipts, etc.
- Warm the new subdomain via the IP warming process (transactional warms fast: 7-10 days)
Week 5-6: Marketing cutover
- Configure marketing campaigns to send from
mail.yourbrand.com - Warm the marketing subdomain (longer: 21-30 days)
- Decommission the old shared sending from
mail@yourbrand.com
Week 7+: Monitoring
- Daily Postmaster Tools review for both subdomains
- Watch for reputation establishment on the new subdomains
- Confirm transactional inbox placement no longer correlates with marketing campaign timing
By the end of week 8, the streams are fully separated, transactional reputation is established independently, and password reset deliverability is no longer affected by marketing campaign performance.
This is the migration path I have walked dozens of customers through. It works consistently. The hardest step is not technical it is getting organizational alignment that the streams need to be treated as different products.
Frequently Asked Questions
Can I just use a different "From" address while keeping the same domain?
Do I need to use a different ESP for transactional, or just different subdomains?
What about API-only providers like AWS SES or Mailgun?
Do I need to warm the transactional subdomain?
What if I'm a small sender and cannot justify multiple ESPs?
Does this matter for B2B senders with low transactional volume?
How does this interact with Yahoo and Gmail's bulk sender requirements?
Key Takeaways
- The most common cause of transactional emails landing in spam is mixing them with marketing on the same domain and IP. Mailbox providers do not differentiate between streams; reputation applies to all mail from the same source.
- Marketing campaigns produce most of the volume and most of the complaints. Transactional mail produces almost no complaints. When commingled, marketing damage drags transactional reputation down.
- The four operational fixes: separate subdomains, separate IPs (or at least separate pools), transactional-optimized provider, and treating transactional as the priority stream.
- The gray-zone messages (digests, notifications, transactional with marketing content) belong on marketing infrastructure. Over-classify as marketing rather than under-classify and contaminate transactional.
- Diagnose the problem through correlation: does transactional placement degrade after marketing sends? Does support ticket volume cluster around campaign timing?
- Migration from mixed to separated takes 6-8 weeks for a typical SaaS company. The infrastructure work is straightforward; the organizational alignment is the harder part.
If you are working through email infrastructure improvements in order, the prerequisites in this series are Sending from Subdomains for the architectural foundation, The Hidden Cost of Shared IP Pools for the IP separation question, and SPF Records Demystified for per-subdomain authentication.
Most SaaS companies discover this problem when a CEO cannot log in to their own product because the password reset is in spam. By that point, the deliverability incident is also a credibility incident. Fix the infrastructure before the incident, not after.
Related articles
Deliverability Incident Response: A Playbook for the First 4 Hours
When email reputation collapses, the first 4 hours determine the recovery timeline. Triage, containment, communication the operational playbook teams actually need.
List Hygiene Beyond Bounces: Engagement-Based Suppression Strategies
Bounce-based list cleaning is decades behind modern deliverability. The 90/180/365-day engagement model, sunset policies, and re-engagement that actually works.
Blocklist Remediation Playbook: Spamhaus, SORBS, and UCEPROTECT
How to remove your IP or domain from Spamhaus, SORBS, UCEPROTECT, and other blocklists. Which lists matter, which to ignore, and the delisting process for each.