Why your transactional emails go to spam, and how to debug it
Updated
When a password reset lands in spam, the user does not blame spam filters. They blame your product. Debugging it is a process of elimination, in this order.
Step 1: read the evidence
Get a real message that landed in spam, then open its full headers (Gmail: "Show original"). Find the line that begins Authentication-Results. It usually reads something like:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=mail.yourdomain.com;
dkim=pass header.d=yourdomain.com;
dmarc=pass header.from=yourdomain.com
Everything after this depends on what it says.
| Result | Meaning | Go to |
|---|---|---|
| spf=fail or softfail | Sending server not authorised | Step 2 |
| dkim=none or fail | No valid signature | Step 2 |
| dmarc=fail | Neither SPF nor DKIM aligned with the From domain | Step 2 |
| All three pass | Authentication is fine | Step 3 |
Step 2: fix authentication
Check each record with the free SPF checker, DKIM checker and DMARC checker.
Common findings:
- Two SPF records. A domain may publish one. Merge them.
- More than ten DNS lookups in SPF. Remove includes you no longer use.
- DKIM published on the wrong host, for example with the domain appended twice by the DNS panel.
- Alignment failure. SPF passed for a different domain than the visible From. Use a verified sending domain with its own DKIM so the signing domain matches your From address.
The explainer on SPF, DKIM and DMARC covers alignment in more depth.
Step 3: look at the identity
If authentication passes, the filter is judging your reputation and the message itself.
- New domain or subdomain. It has no history. Start with low volume, send only wanted mail, and let reputation build.
- Inconsistent From. Many different From names and addresses look like abuse. Keep one per purpose.
- Mixed streams. If newsletters and OTPs share a sending identity, newsletter complaints hurt the codes. Use separate subdomains.
Step 4: look at the content
Transactional mail is usually short, so the culprits are few:
- Promotional language or large images in an account email
- Link shorteners and tracking redirects on a domain you do not own
- A missing plain-text part
- Subject lines in all capitals or with excessive punctuation
- A tiny message that is only a link
Send the same email with the content stripped to a sentence and a link to your own domain. If that lands in the inbox, add content back until it breaks.
Step 5: look at the list
- Hard bounces being retried damage reputation. Make sure bounced addresses are suppressed.
- Sending to unconfirmed addresses. Verify addresses with a link before you send anything else.
- Complaints. If users mark your mail as spam, stop and find out which email they are reacting to.
Step 6: test across providers
Send the same message to Gmail, Outlook and Yahoo test mailboxes and compare. If only one provider junks it, that provider has a reputation or policy issue with you. If all three do, the cause is in your authentication or content.
What does not help
- Adding words such as "not spam"
- Sending the same email repeatedly to "train" the filter
- Buying a list
- Switching providers before you have read the headers
Where Inboxili fits
Verify your domain in the Deliverability Center to get the SPF, DKIM and DMARC records to publish, watch the domain health score, and keep bounces and complaints low with automatic suppression. That removes the controllable causes. It cannot promise placement, and no sender can.
Frequently asked questions
- Can anyone guarantee inbox placement?
- No. Mailbox providers decide using signals only they see. You can remove every cause you control: authentication, content, list quality and sending pattern.
- Why do emails reach Gmail but not Outlook?
- Each provider weighs signals differently and keeps its own reputation data for your domain and IP. Test several providers and compare the headers.
Set up a verified domain
Create a workspace, verify a domain, and make your first API call.