Why your emails go to spam: the causes we actually see

Almost every "my email goes to spam" question has the same handful of answers. They are not evenly distributed, either: the first four causes below account for the overwhelming majority of messages that get filtered, and the exotic explanations people reach for first — a word in the subject line, an image that is too large — are far down the list.

Here they are in the order you should check them.

1. The message is not authenticated

Receivers decide whether to trust a message before they read a word of it. Three records do that work:

• SPF says which servers are allowed to send as your domain.
• DKIM is a cryptographic signature on the message itself.
• DMARC tells receivers what to do when the first two fail, and asks them to report back.

If SPF and DKIM both fail, and DMARC says p=reject, your mail is not going to spam — it is being refused outright. If there is no DMARC record at all, a receiver falls back to its own judgement, and unauthenticated mail from a domain it has never heard of is exactly the profile of a phishing attempt.

The most common version of this is subtler than "no SPF record". It is mail sent through a new service — a CRM, a helpdesk, an invoicing tool — that was never added to SPF and never had a DKIM key published. Your everyday mail passes. The one system your customers actually hear from does not.

Check it in seconds with the DNS checker, then confirm it end to end by sending a real message to a test address.

2. The sending IP has a reputation problem

Your message inherits the reputation of the IP it left from. On shared infrastructure that reputation is partly other people's work. Two things go wrong here:

• The IP is on a blocklist. Some blocklists matter a great deal (Spamhaus ZEN is consulted by a large share of receiving servers); others are consulted by almost nobody. Knowing which list you are on is most of knowing whether to care.
• The IP has no history. A brand-new IP sending a thousand messages on day one looks exactly like a compromised host, because that is what compromised hosts do. Warm up gradually.

Our report checks 35 public DNSBLs, names each one with its return code, and — when you are listed — links you to that list's removal form with your IP already filled in.

3. Reverse DNS and HELO do not line up

This is the cause people are most surprised by, because it has nothing to do with the message.

When your server connects, it announces a hostname (HELO/EHLO) and it has an IP address. A receiver checks whether that IP has a PTR record, whether that PTR resolves back to the same IP (forward-confirmed reverse DNS), and whether the name it announced is a real host rather than localhost or a generic ISP string like static-93-184-216-34.example-isp.net.

Get this wrong and some receivers refuse the connection outright, before spam filtering is even involved. It is one of the cheapest things on this list to fix and one of the most commonly left broken on self-hosted mail.

4. The content pattern reads as bulk

Content filtering is real, but it is much less mysterious than folklore suggests. The things that reliably hurt:

• No plain-text alternative. An HTML-only message is a small, consistent signal — legitimate senders almost always send both parts.
• A wall of images with almost no text. Filters cannot read an image. A message that is one big JPEG is a message with nothing to judge but its shape, and that shape is the one spammers use to evade text analysis.
• Broken or mismatched links. A link whose visible text says one domain and whose href points at another is the single most phishing-like thing you can put in an email.
• A domain in the links with no reputation. Link-shorteners and freshly registered tracking domains both attract suspicion.

What is largely folklore: individual "spam words". Writing "free" once in a sentence does not filter your mail. A message that scores badly on a dozen SpamAssassin rules at once will, and our report shows you exactly which rules fired and what each one cost.

5. Missing headers that mark a message as machine-generated

Several headers are near-universal on legitimate mail and frequently absent on mail sent by an application that assembled its own SMTP payload:

• Message-ID — every real mail client sets one. Its absence is a strong bulk signal.
• Date — same story, and a badly-formatted or wildly wrong one is worse than none.
• List-Unsubscribe — for anything resembling bulk mail this is now effectively mandatory at the large mailbox providers, and it must be a working one-click unsubscribe.

6. Engagement, which no single message can show you

Mailbox providers weigh how recipients treat your mail: opens, replies, deletions without reading, and above all "mark as spam" clicks. This is why a message that scores a perfect 10 can still land in spam for one recipient and in the inbox for another — the score describes the message, and engagement describes the relationship.

Nothing that tests a single message can measure this, ours included. Anything that claims to is guessing. What you can do is keep the list clean, make unsubscribing trivially easy, and stop mailing addresses that have ignored you for a year.

The order to work in

1. Publish and fix SPF, DKIM and DMARC. Check them without sending anything.
2. Check your sending IP against the blocklists that matter, and fix the cause before requesting delisting.
3. Fix reverse DNS and your HELO name.
4. Send a real message to a test address and read the itemised report — content, headers and SpamAssassin rules in one place.
5. Only then start tuning subject lines.

The first four are facts you can verify today. The fifth is where most people start, which is why so many people are still stuck.