Why do my emails go to spam?

Emails end up in spam folders for a surprisingly narrow set of reasons, and almost all of them are fixable within 24 to 72 hours once you know what to look for. In 2026 the landscape changed again: Google, Yahoo and Microsoft now enforce the bulk-sender rules introduced in February 2024, and the threshold of "bulk" has effectively dropped to any domain sending more than a few hundred messages per day to their users. If your legitimate mail is being filtered, the cause is almost always one of the following eight categories, and they are worth working through in order.

The eight real causes of spam folder placement

1. Missing or broken email authentication. SPF, DKIM and DMARC are no longer optional. A domain without a published DMARC record is now actively penalised by Gmail and Yahoo. A domain with DMARC set to p=none but no aligned DKIM signature is also penalised, because receivers interpret "none" as "the owner has not finished configuring authentication". Run a quick authentication scan on IntoDNS.ai to confirm all three records exist, are syntactically correct and align with the visible From header.

2. SPF that silently exceeds the 10-lookup limit. RFC 7208 caps SPF at 10 DNS lookups during evaluation. Large include: chains (Microsoft 365, Google Workspace, Mailchimp, HubSpot stacked together) routinely push domains past 10, and when that happens every message returns a permerror which most receivers treat as an authentication failure. The fix is SPF flattening or, preferably, removing unused senders.

3. DKIM key too short or signature broken. 1024-bit DKIM keys are now treated as weak. Rotate to 2048-bit. Also verify the signature actually validates — a common failure is a mail gateway that rewrites the message body after signing, which invalidates the signature on every outgoing message.

4. IP or domain on a blocklist. Spamhaus ZEN, SURBL, URIBL and Barracuda are the four that matter in 2026. Shared hosting IPs get listed for other tenants' behaviour all the time. Delisting is free and usually takes less than an hour once the underlying cause is resolved.

5. Poor sender reputation at the receiver. Gmail Postmaster Tools, Microsoft SNDS and Yahoo Sender Hub all publish per-domain and per-IP reputation scores. A single spike in spam complaints above 0.3% can move a domain from "High" to "Low" reputation within days. Once reputation drops, even perfectly authenticated mail lands in spam.

6. Reverse DNS mismatch. The sending IP must have a PTR record, and that PTR record should forward-confirm to the same IP. Missing or generic PTRs (think host-1-2-3-4.isp.net) are a strong spam signal for Microsoft in particular.

7. Content patterns. Receivers still weigh content, though less than five years ago. The patterns that hurt in 2026 are: mismatched link display text vs href, URL shorteners, tracking pixels from known bulk-mail ESPs on transactional mail, single-image emails with no text, and unbalanced text-to-link ratios.

8. Engagement signals. Gmail especially measures whether recipients open, reply, star or move your mail out of spam. Sending to cold or stale lists tanks engagement metrics fast. List hygiene — removing hard bounces immediately, honouring unsubscribes within 24 hours, and pruning non-openers after 180 days — is the single highest-leverage deliverability task most senders skip.

A diagnostic playbook that actually works

Step one is always authentication. Use IntoDNS.ai to get a pass/fail on SPF, DKIM alignment, DMARC policy, MTA-STS and BIMI in one scan. If any of these fail you stop and fix them before doing anything else, because fixing content or reputation on top of broken auth is wasted effort.

Step two is blocklist status. Check the sending IP and the envelope-from domain against Spamhaus, SURBL and Barracuda. If listed, follow each provider's delist flow — Spamhaus is usually automatic within an hour once the cause (open relay, compromised account, snowshoe pattern) is resolved.

Step three is reputation. Register the sending domain in Google Postmaster Tools and Microsoft SNDS. Watch spam rate, domain reputation and IP reputation for seven days. If spam rate is above 0.1% investigate which campaign or segment is driving it.

Step four is content. Send a test from your production system to a fresh, never-used Gmail and Outlook address. Look at the full message source. Check the Authentication-Results header for dkim=pass, spf=pass and dmarc=pass. Look at the X-Spam-Status (many receivers add one) for the actual score and which rules fired.

Common fixes, ranked by impact

1. Publish DMARC at p=none with rua reporting            ~35% of cases
2. Flatten SPF under 10 lookups                          ~20%
3. Rotate DKIM to 2048-bit and verify signature validity ~15%
4. Request blocklist delisting                           ~10%
5. Fix PTR / reverse DNS                                 ~8%
6. Clean list (remove bounces, inactives)                ~7%
7. Rewrite content (remove URL shorteners, balance HTML) ~5%

Percentages are approximate, based on patterns observed across thousands of scans.

Troubleshooting when the basics all pass

If SPF, DKIM and DMARC all pass, the IP is clean, and the domain still lands in spam, look at three less obvious causes.

First, check for SPF/DKIM alignment issues. DMARC requires that either the SPF Return-Path domain or the DKIM d= tag matches the organisational domain in the From header. Many ESPs sign with their own domain by default, which authenticates but does not align — DMARC will fail even though SPF and DKIM technically pass.

Second, check MTA-STS and TLS-RPT. In 2026 Gmail downgrades mail from domains that do not publish a valid MTA-STS policy. Publishing one is a thirty-minute job: a TXT record at _mta-sts, a policy file at https://mta-sts.yourdomain/.well-known/mta-sts.txt, and a TLS-RPT record.

Third, check BIMI. BIMI is not an anti-spam mechanism but publishing a valid BIMI record (with a VMC or CMC) signals to Gmail, Yahoo and Apple Mail that you care about your brand, and these providers quietly boost reputation for domains that publish one.

When to use IntoDNS.ai

IntoDNS.ai was built specifically for this diagnostic flow. A single scan of your domain returns the state of SPF (with lookup count), DKIM across common selectors, DMARC with policy and alignment check, MTA-STS, TLS-RPT, BIMI, DNSSEC, blocklist status on the top four RBLs, and plain-English explanations of every failure with the exact record you need to publish. It is free for public scans and does not require an account. If you are chasing a spam-folder issue, running an IntoDNS.ai scan first saves an hour of manual checks across five different tools.

A worked example

Consider a consultancy running a Microsoft 365 tenant that also uses HubSpot for marketing, Zendesk for support, and a self-hosted application for invoice delivery. Their mail started landing in Gmail spam in March 2026. A scan returned:

• SPF: 12 DNS lookups (permerror). HubSpot plus Microsoft 365 plus Zendesk plus the self-hosted MX's chain was over limit.
• DKIM: only Microsoft 365's selector1 was signing. HubSpot was sending unsigned on a subdomain.
• DMARC: p=none with no rua= configured, so no aggregate reports in three years.
• MTA-STS: missing.
• Gmail Postmaster reputation: Medium, spam rate 0.4%.

The fix, in order, took less than a working day. First, flatten SPF by dropping unused legacy include: entries and moving HubSpot to a marketing.example.com subdomain with its own short SPF. Second, enable DKIM signing at HubSpot with d=example.com to align with the visible From header. Third, publish DMARC at p=none with [email protected] to start collecting reports. Fourth, publish MTA-STS in testing mode. After two weeks of clean reports, DMARC moved to p=quarantine; pct=25, then incrementally to p=reject. Gmail spam rate dropped from 0.4% to 0.05% within 30 days, and domain reputation moved to High.

The lesson: almost every spam-folder investigation follows this same pattern. Fix authentication first, then reputation rebuilds on its own over 2-4 weeks. Chasing content or list hygiene before auth is fixed is lost time.