Why transactional emails end up in spam.

1. Why transactional is different from marketing

Transactional email - password resets, order confirmations, receipts, account verifications - gets treated as "obviously safe" by most engineering teams. It's the email no one thinks about until a customer says "I never got the password reset link."

Here's the bad news: transactional email actually has stricter deliverability requirements than marketing email, because spam filters know that legitimate transactional senders care about every single message. A marketing campaign with 80% inbox placement is acceptable. A password reset email with 80% inbox placement means 20% of your users can't log in.

The good news: transactional email is also easier to fix than marketing email, because you control the entire sending infrastructure. No marketing team negotiating subject lines, no list-cleaning debates. Just code and DNS.

2. SPF alignment - the silent killer

Most transactional email passes SPF in the technical sense - but fails SPF alignment, which is what DMARC actually checks.

Here's the trap: SPF authenticates the Return-Path domain (also called envelope-from), not the visible From address. When you send through SendGrid:

SPF passes (because em1234.sendgrid.net is authorized to send for itself). But DMARC requires the SPF-authenticated domain to match the From domain. sendgrid.net ≠ yourdomain.com, so DMARC alignment fails. If your DMARC policy is p=quarantine or p=reject, your password reset goes to spam.

Fix: set up custom Return-Path domain. In SendGrid this is "Domain Authentication" - they generate CNAME records pointing em.yourdomain.com to their infrastructure. Once configured, Return-Path becomes [email protected], which aligns with yourdomain.com via the "relaxed alignment" rule.

3. DKIM signing the right domain

Same alignment principle for DKIM. Default ESP configuration signs with their domain (d=sendgrid.net). DMARC requires the DKIM-signing domain to match (or align with) the From domain.

Every major transactional ESP supports custom DKIM signing - it's a standard feature. The setup is two CNAME records pointing your selectors at their signing infrastructure. After setup, your DKIM signature reads d=yourdomain.com, which aligns properly.

4. From-address consistency

Stop using [email protected] for transactional email. Three reasons:

1. Inbox providers downgrade no-reply addresses. Gmail and Outlook both pattern-match for noreply, no-reply, donotreply in the From local-part and apply a small but measurable spam-score increase. The pattern correlates with low-trust senders historically.
2. Replies bounce, signaling broken sender. When a recipient hits reply on a noreply@ address, their server tries to deliver and fails. That bounce is logged by their provider and counted against your reputation.
3. Customer service signal. Treating customer-facing email as one-way ("don't reply, we don't read it") is a brand-damaging pattern that inbox providers explicitly downgrade.

Use a real address: [email protected], [email protected], [email protected]. Configure it to forward to your support inbox or auto-respond with helpful guidance.

5. Shared IP reputation traps

If you send via SendGrid, Mailgun, or AWS SES on a shared IP pool, your deliverability is partially controlled by other customers on the same IPs. When they send to dirty lists or generate spam complaints, the IP's reputation drops - and so does yours.

This shows up as inconsistent deliverability that you can't explain. Same code, same templates, same recipients - but Tuesday's batch goes to inbox and Thursday's goes to spam. The variable is the IP, not your sending.

Mitigation strategies:

• Postmark aggressively curates their shared IPs and kicks bad senders. Slightly more expensive but consistent. Good default for transactional.
• AWS SES has improved over the years, but still has noisy neighbors. Use only with custom warming and dedicated IPs above 50K/month.
• SendGrid Pro tier has cleaner shared pools than free tier. Worth the upgrade if you're seeing inconsistency.

6. IP warming for higher-volume senders

If you're moving to a dedicated IP (or your provider auto-assigns one), you must warm it slowly. New IPs have zero reputation; sending high volume immediately triggers spam filters.

Standard warming schedule:

Skip steps and you'll see spam-folder rates spike. Reputable providers handle warming automatically if you use their warming service - worth using.

7. Content traps specific to transactional

Marketing email content advice mostly applies. Two transactional-specific traps to know:

Subject lines that pattern-match phishing

Bad: "Reset your password immediately", "Urgent: confirm your account", "Security alert". These match phishing patterns spam filters watch for. Better: "Your password reset link", "Welcome to Acme - confirm your email", "Your order #1234 is on its way".

Image-only emails

Some teams build transactional emails as a single image (the receipt, the confirmation page) wrapped in HTML. Spam filters specifically flag image-only messages because it's a classic spam-evasion technique. Always include a meaningful HTML body alongside any images.

8. Monitoring transactional deliverability

You can't fix what you don't measure. For transactional email specifically:

1. DMARC reports - set up rua=mailto:[email protected] and review weekly. Aggregate reports show what % of your transactional mail is passing authentication.
2. Per-template engagement metrics - track open rate by transaction type. Password reset opens at 12% means 88% are going to spam (these should open at 60%+).
3. Synthetic monitoring - set up automated test sends to seed inboxes at Gmail, Outlook, Yahoo. Run hourly. Alert when placement drops.
4. Customer support signal - track tickets like "I didn't get the email." Spike in these is the loudest deliverability alarm.

9. Frequently asked questions