Why your emails go to spam (and how to fix it)

Most emails go to spam for one of three reasons: the domain fails authentication checks (SPF/DKIM/DMARC), the sending IP or domain has a poor reputation, or the message content trips spam filters. Mailbox providers like Gmail and Outlook.com score every message against all three before deciding where it lands, and a failure in any one of them is often enough to route mail straight to the junk folder.

This guide walks through each cause and the concrete fix, in the order mailbox providers actually check them.

Authentication: the most common cause

If your domain doesn't publish SPF, DKIM and DMARC — or publishes them incorrectly — you're starting every send with a strike against you. This is the single biggest fixable cause of spam placement.

SPF (Sender Policy Framework), defined in RFC 7208, is a DNS TXT record listing which servers are allowed to send mail for your domain. The receiving server checks the envelope-from address against it. A typical record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Two gotchas trip people up constantly: SPF allows a maximum of 10 DNS lookups (each include, a, mx, ptr, exists mechanism counts), and exceeding that causes a permanent error that fails the check entirely. And a single TXT string is capped at 255 characters per RFC 1035, so long SPF records need to be split into multiple quoted strings within the same record. Validate yours with our free SPF generator, or read the full walkthrough on how to create a secure SPF record.

DKIM (DomainKeys Identified Mail), RFC 6376, adds a cryptographic signature to outgoing mail that's verified against a public key published at selector._domainkey.yourdomain.com. Unlike SPF, DKIM survives simple forwarding because the signature travels with the message headers, not the envelope.

DMARC (Domain-based Message Authentication, Reporting & Conformance), RFC 7489, ties the two together. It requires that the domain in the visible From: header aligns with either the SPF or DKIM domain, and it lets you publish a policy telling receivers what to do with mail that fails:

v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; pct=100

TipStart DMARC at p=none to collect aggregate reports without affecting delivery, then move to quarantine or reject once you've confirmed all legitimate senders pass. Build the record correctly with our DMARC generator.

As of February 2024, Google and Yahoo require valid SPF and DKIM for every sender, and DMARC (at minimum p=none) with From-header alignment for anyone sending 5,000+ messages a day to their users. Below that threshold it's not strictly enforced — but domains without any DMARC record are increasingly treated as suspicious by default.

Sender reputation: what happens after authentication passes

Passing SPF, DKIM and DMARC gets you in the door. What happens next depends on reputation — a score mailbox providers build up per sending IP and per domain based on real recipient behaviour.

Key reputation signals include:

• Spam complaint rate. Gmail's Postmaster Tools flags anything above roughly 0.1% as a concern and treats 0.3%+ as a hard problem for bulk senders.
• Engagement. Opens, clicks, replies and — negatively — deletions without reading or manual "mark as spam" actions all feed the score.
• Forward and reverse DNS. Sending IPs need a valid PTR (reverse DNS) record that resolves back to a hostname matching the sending domain. Missing or mismatched PTR records are an instant red flag for Gmail's bulk sender rules.
• Blacklist status. Being listed on a major DNS blackhole list (DNSBL) after a compromised server or leaked credentials tanks deliverability until you're delisted.
• Consistent sending patterns. A domain that suddenly jumps from 50 emails a day to 50,000 looks like a compromised account or a spam campaign, even if the content is legitimate.

If you manage your own mail server or a new sending domain, warm it up gradually and monitor Gmail Postmaster Tools and Microsoft SNDS rather than guessing. Reverse DNS and PTR records live in the same DNS zone as everything else — check yours with our DNS lookup tool or review your full zone with DNS management.

Content and formatting: the filter's last check

Even a perfectly authenticated, well-reputed domain can get flagged if the message itself looks like spam. Filters look at:

Signal	What triggers it
Subject line	ALL CAPS, excessive punctuation, "free", "guaranteed", "act now"
Link ratio	A message that's mostly links with little text
Image-to-text ratio	Image-only emails with no readable text (common phishing pattern)
Unsubscribe mechanism	Missing or broken unsubscribe link
HTML quality	Malformed HTML, mismatched display text vs. link URL
Encoding	Non-standard character sets, hidden text, invisible tracking pixels overused

For bulk and marketing mail, Gmail and Yahoo now require a one-click unsubscribe header (RFC 8058) that must be honoured within two days. Sending marketing mail without it — even from a perfectly authenticated domain — increases the chance of being routed to spam or blocked outright.

WarningFixing authentication after a domain has already accumulated spam complaints doesn't reset reputation immediately. Expect a gradual recovery over days to weeks, not an instant fix.

A practical checklist

1. Confirm SPF, DKIM and DMARC all exist and pass — check with DNS lookup or MX lookup for mail-specific records.
2. Make sure your DMARC policy has an aligned domain and a reporting address so you can see failures.
3. Set up reverse DNS (PTR) for every sending IP.
4. Watch spam complaint rate in Gmail Postmaster Tools or Microsoft SNDS; keep it under 0.1%.
5. Add one-click unsubscribe to any bulk or marketing send.
6. Avoid sudden volume spikes from a cold domain or IP.

Most deliverability problems trace back to one missing or misconfigured DNS record. If you're managing SPF, DKIM, DMARC and MX across several domains and registrars, centralising DNS in one dashboard makes it far easier to catch a broken record before it costs you inbox placement — see how with InfraNest DNS management.