Why Are My Emails Going to Spam? (And How to Fix It)

There are two kinds of email deliverability problems. The first is content-related: spam filters flagging your copy, your subject line, your sending behavior. The second is infrastructure-related: authentication failures that tell receiving servers your email might not be legitimate. Most deliverability guides focus on content. Most deliverability problems are infrastructure. If you want the full sweep, the email deliverability checklist covers both sides in order.

If your emails are landing in spam, start here.

Category 1: Authentication failures (most common cause for developers)

These are the problems that DMARC, SPF, and DKIM exist to solve. Authentication answers a single question for the receiving server: did this message really come from the domain it claims to come from? If the answer is no, or even "can't tell," the message is treated as suspicious before a spam filter ever looks at your subject line. Fix authentication first, because nothing else you do matters if Gmail can't confirm you are who you say you are.

SPF missing or broken

Your SPF record (governed by RFC 7208) tells receiving servers which IPs are allowed to send email as your domain. It's a single DNS TXT record that starts with v=spf1 and ends with a policy qualifier, usually -all (hard fail) or ~all (soft fail). If it's missing, misconfigured, or doesn't include your ESP, every email you send fails SPF validation. Spam filters treat SPF failure as a strong negative signal.

There's a catch that bites growing senders specifically: SPF has a hard limit of 10 DNS lookups per evaluation. Every include:, a, mx, ptr, and exists mechanism in your record counts, and includes can nest (your ESP's include can pull in two or three more). Cross the limit and your record returns permerror, which most receivers treat as an outright SPF failure, not a soft one. Add a few vendors (an ESP, a CRM, a support tool, a marketing platform) and you blow the budget without realizing it.

Check: SPF checker. Look for: does your record exist, does it include your ESP's sending IPs, and is it under the 10-lookup limit? If you're over, don't keep adding includes. Flatten the record (replace includes with the resolved IP ranges) or consolidate vendors. The SPF flattening guide walks through it, and the SPF flattener tool does the resolution for you.

DKIM not configured

DKIM (RFC 6376) cryptographically signs your outgoing email. Your ESP holds a private key and signs each message; you publish the matching public key in DNS at a named selector (something like selector1._domainkey.yourdomain.com). The receiving server fetches that public key and verifies the signature. A missing or broken DKIM signature means receiving servers can't verify the email came from an authorized source.

DKIM matters more than SPF for one structural reason: it survives forwarding. SPF checks the envelope sender against the connecting IP, so the moment a message is forwarded through a mailing list or a .forward rule, the IP changes and SPF breaks. The DKIM signature travels with the message body and headers, so it still validates. That's why DKIM alignment is usually the load-bearing half of DMARC.

Check: most ESPs show DKIM status in their dashboard. You can also use the email authentication checker or read the what is DKIM primer.

Frequent cause: you set up DKIM once and it was fine, then your ESP rotated their signing key without telling you. Your DNS record is now pointing at an expired selector. This is exactly the kind of silent change that only shows up in production, or in your aggregate reports.

DMARC alignment failing

DMARC ties SPF and DKIM together and checks whether either is aligned with the from: domain on your email. Alignment is the part people miss. It's not enough for SPF or DKIM to pass on their own; the domain they passed for has to match (or be a parent of) the visible From domain.

Alignment comes in two modes. Relaxed alignment (the default) accepts any subdomain of your organizational domain: a DKIM signature for mail.yourdomain.com aligns with a From of yourdomain.com. Strict alignment requires an exact match. If you set strict alignment and your ESP signs with a subdomain, DMARC fails even though DKIM passed. This is one of the most common self-inflicted failures.

This is the silent one. Your email might be passing SPF and DKIM individually but still failing DMARC because of a subdomain mismatch or alignment settings you didn't intend. A message that fails DMARC under a p=quarantine or p=reject policy goes straight to spam, or is rejected entirely.

Check: DMARC record checker to see your DMARC record. Use the DMARC analyzer to see what your aggregate reports show about real mail in flight, which sending sources are aligning and which aren't.

Category 2: Domain and IP reputation

Authentication proves who sent the message. Reputation decides whether that sender is trusted. Two domains can both pass DMARC and land in different folders purely because one has a track record and the other doesn't. Reputation lives at two levels, the sending IP and the sending domain, and receivers score both.

Sending IP on a blocklist

If you're on a shared IP pool with your ESP, someone else's spam can get your IP blocklisted. Receiving servers check the sending IP against major blocklists (Spamhaus, Barracuda, SpamCop, SORBS, and others) on every inbound message. A listing on a widely-consulted blocklist like the Spamhaus SBL or XBL can send your mail to spam across many providers at once.

Check: email blacklist checker. Check your domain and, if your ESP tells you your sending IP, check that too. Some blocklists are domain-based (URIBLs that flag the domains inside your message body, like your links), so a clean IP doesn't always mean a clean reputation.

Fix: if you're on a shared IP, request a dedicated IP from your ESP (usually available at a paid tier) so your reputation is yours alone. If your own IP is listed, follow the blocklist's documented removal process, and investigate why it was listed before you request delisting, or you'll just get relisted.

Sending domain has no reputation history

New domains are treated as suspicious by default. If you launched last month and started sending immediately, you're building reputation from zero. Spam filters are conservative with unknown senders, and a brand-new domain that suddenly sends thousands of messages looks exactly like a throwaway domain a spammer would burn.

Worse, domain age interacts with content: a new domain with image-heavy marketing mail to a cold list is the textbook spam profile. The same content from an established domain often delivers fine.

Fix: warm up the domain. Start with low volume to highly engaged recipients, people who open and reply, and build over weeks, not days. Send consistently rather than in bursts. If you can, send your earliest mail to your own team and engaged early users so the first engagement signals are strongly positive.

Shared-IP neighbors

On a shared pool, your deliverability is partly a function of who you're sending alongside. Reputable ESPs police their pools aggressively and segment senders by behavior, but on cheaper or less-curated infrastructure a few bad neighbors can drag the whole IP's reputation down. If your authentication is clean and your content is fine but mail still lands in spam inconsistently, a noisy shared IP is a prime suspect, and the fix is the same as above: move to a dedicated IP, or move to a provider with a better-managed pool.

Category 3: Content and formatting triggers

These matter less than authentication and reputation, but they compound other problems. A content issue rarely sinks a well-authenticated message from a trusted domain on its own, but stack it on a young domain or a borderline IP and it tips you into the spam folder.

Images-only or heavy HTML with no text

Spam filters look at the text-to-HTML ratio and the text-to-image ratio. Emails that are mostly one big image with little real text, or dense marketing HTML with megabytes of inline styling, score worse than plain-text or light, well-structured HTML. The classic spammer trick was to hide all their text inside an image to dodge content filters, so filters learned to distrust image-only mail. Always include a meaningful plain-text part alongside your HTML, and make sure your message reads sensibly even with images disabled.

Spammy phrasing and subject lines

"Free," "limited time," "act now," "100% guaranteed," "click here," excessive exclamation points, and ALL CAPS subject lines are all patterns filters have been trained on for decades. They rarely flag a message by themselves anymore, but they add up. More importantly, modern filters weigh engagement far more heavily than keyword lists: if recipients consistently ignore, delete-without-opening, or never reply to similar emails, the filter learns the mail is unwanted regardless of the words you choose.

Link shorteners and link reputation

bit.ly, t.co, and other URL shorteners are heavily abused by spammers because they hide the real destination, so filters treat shortened links with suspicion. Link to your own domain instead. And remember that the reputation of the domains you link to is part of your content score. Linking to a flagged or blocklisted domain can pull your message down even if your own domain is spotless.

Mismatched From, Reply-To, and headers

A From address on one domain with a Reply-To pointing somewhere unrelated is a phishing pattern, and filters notice. So is a missing or generic From display name, a From domain that doesn't match the authenticated domain, or a missing List-Unsubscribe header on bulk mail. None of these is a guaranteed spam verdict on its own, but each is a small negative weight that compounds with everything else. Keep your From, Reply-To, and authenticated domain consistent, and set a real, recognizable From name.

Category 4: List hygiene and engagement

For anything beyond one-to-one mail, who you send to and how they respond is now the dominant deliverability signal at the major mailbox providers. Gmail and Yahoo lean heavily on engagement: mail that gets opened, read, and replied to builds reputation; mail that gets ignored or marked as spam destroys it. You can have flawless authentication and still land in spam if your list is full of people who don't want your mail.

Sending to unengaged or scraped addresses

Mailing people who never open your messages trains the filter that your mail is low-value, and that verdict spreads to your engaged recipients too. Purchased or scraped lists are the worst version of this: they're full of stale addresses, role accounts (info@, sales@), and spam traps, addresses that exist only to catch senders who didn't get consent. Hitting a spam trap is a fast track to a blocklist. Never buy lists. Periodically suppress recipients who haven't engaged in months, and re-confirm or drop them rather than sending forever into the void.

High complaint rate

When a recipient clicks "report spam," that's a complaint, and complaints are the single most damaging engagement signal you can generate. Gmail's published guidance is to keep your spam complaint rate below 0.1% and to never exceed 0.3%, and crossing 0.3% can get your mail throttled or sent to spam wholesale. (More on the thresholds in the next section.) Complaints usually come from mail recipients didn't expect or can't easily escape, so the fixes are: set clear expectations at signup, only send what people opted into, and make unsubscribing trivial.

Missing one-click unsubscribe

A buried, multi-step, or broken unsubscribe link pushes frustrated recipients to hit "report spam" instead, which is far worse for you than a clean unsubscribe. Make unsubscribe obvious and one-click. For bulk senders this isn't just good practice; it's now a hard requirement (next section). Honor unsubscribes fast: Gmail requires them to be processed within two days, and continuing to mail someone who opted out is a reliable way to manufacture complaints.

Category 5: The Gmail and Yahoo 2024 bulk-sender requirements

In February 2024, Gmail and Yahoo jointly rolled out enforced requirements for bulk senders, defined as anyone sending more than 5,000 messages per day to their users. These aren't suggestions; mail that doesn't comply gets rejected or filtered. If your sending volume is anywhere near that threshold, this is the category to verify first after authentication. The full walkthrough is in the Gmail and Yahoo sender requirements post; here's what they require:

1. Full authentication. SPF and DKIM must be set up, and you must publish a DMARC record (a policy of p=none is enough to satisfy the rule, though enforcement is better for protection). Your message's From domain must align with either the SPF or DKIM domain. This is Category 1 above, which is why authentication is non-negotiable, not optional.

2. One-click unsubscribe (RFC 8058). Marketing and promotional mail must include a List-Unsubscribe header and a List-Unsubscribe-Post: List-Unsubscribe=One-Click header, so the recipient's mail client can unsubscribe them in a single action without a round trip to your site. The visible unsubscribe link in the body still matters, but the header-based one-click flow is what's mandated. You must also honor these requests within two days. (Transactional mail such as receipts, password resets, and action-triggered alerts is treated differently and doesn't require the one-click unsubscribe.)

3. Spam complaint rate under 0.3%. Keep your complaint rate (as measured in Gmail Postmaster Tools) below 0.3%, and ideally under 0.1%. Spike above 0.3% and Gmail will start filtering or rejecting your mail. This is where list hygiene from Category 4 turns from best-practice into a pass/fail gate.

Check: the Gmail & Yahoo compliance checker verifies the authentication and unsubscribe-header pieces. The complaint-rate piece you monitor in Gmail Postmaster Tools, which reports complaint rate and domain reputation for volume senders.

How to diagnose your case systematically

Don't guess. Work top-down, starting with authentication because it's the most common cause and everything else assumes it's solved, and stop at the first thing that's broken.

1. Reproduce it. Send a test message to a Gmail account, a Yahoo account, and an Outlook account. Note exactly where each lands. A free tool like a seed-inbox/placement test or simply mailing your own accounts tells you whether the problem is universal or provider-specific.

2. Check authentication. Run the email authentication checker, then the SPF checker (exists? includes your ESP? under 10 lookups?) and the DMARC record checker. Confirm not just that SPF and DKIM pass, but that one of them aligns with your From domain. This single step resolves most deliverability problems.

3. Read the View Original / headers. In Gmail, open the message and choose "Show original." It prints SPF: PASS/FAIL, DKIM: PASS/FAIL, and DMARC: PASS/FAIL for that exact message. This is ground truth for one delivery and will immediately confirm or rule out authentication.

4. Check reputation. Run the blacklist checker on your domain and sending IP. Open Gmail Postmaster Tools and look at domain reputation and complaint rate. A young domain with no history is its own finding.

5. Check compliance if you send volume. If you're near 5,000/day to Gmail, run the Gmail & Yahoo compliance checker and verify your one-click unsubscribe headers and complaint rate.

6. Only then look at content and list. If authentication, reputation, and compliance are all clean and mail still lands in spam, examine content (text-to-image ratio, link shorteners, From/Reply-To consistency) and list quality (engagement, complaint rate, stale addresses).

Match your symptom to the likely category:

• Emails going to spam for everyone: start with authentication (SPF, DKIM, DMARC).
• Emails going to spam only on Gmail/Yahoo: check compliance and blocklist status.
• Emails going to spam for some recipients but not others: reputation or sending IP.
• Marketing emails specifically: complaint rate, engagement, and content.
• Transactional emails specifically: almost certainly authentication or a blocklist.

The monitoring gap

Most of these problems are invisible until you hit them in production or go looking for them. A header check tells you about one message you sent to one inbox. It can't tell you that your CRM started sending unaligned mail last Tuesday, or that one of your five sending sources quietly stopped signing with DKIM.

DMARC aggregate reports are the best source of ground truth for authentication failures. They show you, for every sending source, what's passing and what's failing across all receiving mail servers, the full picture a single header check can't give you.

The problem: they're gzipped XML, sent daily by dozens of mailbox providers. The practical solution is a tool that processes them automatically and alerts you when something changes.

If authentication is the problem, DMARC aggregate reports will tell you exactly which sources are failing and where. DMARCdrift processes them into something readable. Free for one domain.

Get started free →