Why your transactional emails land in spam — and how to fix it

You spent weeks on your onboarding flow. A new user signs up, triggers the welcome email, and it lands in Gmail’s spam folder. They never confirm their email. They churn before they start.

This is not bad luck. It’s a fixable infrastructure problem.

The short answer

Gmail, Outlook, and Apple Mail use a three-part authentication system — SPF, DKIM, and DMARC — to decide whether an email is legitimate. If your setup is incomplete or broken, their filters treat your messages as suspicious, even when you’re not a spammer.

How they work together:

  • SPF (Sender Policy Framework) — checks if the server sending the email is authorized to send for your domain
  • DKIM (DomainKeys Identified Mail) — checks if the email has a valid cryptographic signature proving it hasn’t been tampered with
  • DMARC (Domain-based Message Authentication, Reporting & Conformance) — tells receivers what to do if SPF or DKIM fail (ignore, quarantine, or reject)

Most early-stage SaaS products have this partially configured. “Partially” is enough to cause spam placement.

What’s actually happening

When you send through Postmark, Resend, Amazon SES, or any other transactional provider, that provider’s servers send email on behalf of your domain. Receiving mail servers check:

  1. Is this sender authorized to send for your domain? (SPF check)
  2. Is there a valid cryptographic signature on this message? (DKIM check)
  3. What should we do if those checks fail? (DMARC policy)

If your provider is not listed in your SPF record, or if DKIM isn’t configured, check 1 or 2 fails. If DMARC is absent or set to p=none, the receiving server has no clear instruction, and its own spam filter makes the call — often unfavorably.

How to find the actual problem

The fastest diagnostic is to send a test email and check the raw headers. In Gmail, open the message → three dots → “Show original.” Look for the Authentication-Results header:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com ...
  spf=pass (google.com: domain of you@yourdomain.com designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

If any line says fail or neutral, that’s your issue. Common patterns:

  • spf=neutral — your provider’s IP is not listed in your SPF record
  • dkim=fail — DKIM isn’t set up in your provider, or the DNS record has a typo
  • dmarc=fail — SPF and DKIM don’t align with the From header domain

The fix

Prerequisites: You need access to your DNS provider panel (Cloudflare, AWS Route 53, Namecheap, etc.) and your transactional email service dashboard.

For SPF: Log in to your DNS provider and check the TXT record at your root domain. It should include your transactional email provider. Example for Postmark:

v=spf1 include:spf.mtasv.net ~all

For Resend, Amazon SES, or others, check their documentation for the exact include: value. If you use multiple providers, they all go on one line.

For DKIM: Every transactional provider has a DKIM setup section in their dashboard. You generate a key there, publish a DNS TXT record at a subdomain like pm._domainkey.yourdomain.com, and verify it. This is the step most founders skip.

Validation tools:

  • Gmail Delivery Console — Check headers as described above
  • dig TXT yourdomain.com — Verify your SPF record is published
  • dig TXT selector._domainkey.yourdomain.com — Verify your DKIM key is published
  • Send a test email to Gmail and check Authentication-Results header directly

For DMARC: Add this TXT record at _dmarc.yourdomain.com to start monitoring:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Don’t set p=reject until you’ve confirmed that all your legitimate senders pass. Moving too fast breaks real email.

Why “it worked before” isn’t reassuring

Spam folder placement is not binary. It’s a score. You might have been borderline before, and a recent change (new provider, new IP, new sending volume) pushed you over the threshold. Or you got lucky — until you didn’t.

Email authentication doesn’t fix all deliverability problems, but it removes the most obvious reason for a filter to distrust you. Once SPF, DKIM, and DMARC are correct, you’re competing on content quality and sender reputation, not on whether your infrastructure looks suspicious.

Monitoring after the fix

Authentication configuration breaks silently. A developer adds a new email provider, forgets to add it to SPF, and suddenly 30% of your emails fail — with no error, no bounce, no notification. The email just disappears into spam.

DMARC aggregate reports (the rua address) give you a daily stream of what’s actually happening with your domain across every major inbox provider. DMARC Guardian reads those reports and alerts you when something breaks, so you find out before your users do.

Start your free trial — no credit card, 90 days, unlimited domains.