Why your emails go to spam

How filtering decisions are made

A mailbox provider decides where a message goes using signals of three kinds. The first is identity: can the message be tied to the domain it claims to come from. The second is reputation: how have recipients reacted to earlier mail from this domain and this sending address. The third is the message itself: its content, links and structure.

They are weighed in roughly that order. A message that fails authentication may be filtered whatever it says. A message from a domain with a poor reputation is filtered even when it is perfectly authenticated. Content matters most at the margin, for senders the provider has little history with. This is why rewriting the subject line rarely fixes a spam-folder problem.

Start with one real message

The fastest diagnosis comes from a message that actually went to spam. Open it in the receiving mailbox, view the original or the full headers, and find the Authentication-Results header added by the receiving server. It records the outcome of SPF, DKIM and DMARC for that exact message.

Three passes with your own domain shown beside each means identity is not the problem. Anything else tells you where to look first.

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Authentication-Results: mx.example.net;
  spf=softfail smtp.mailfrom=example.com;
  dkim=pass header.d=mailer-service.example;
  dmarc=fail header.from=example.com

Authentication problems and their fixes

Each result in that header corresponds to a specific cause.

1. spf=fail or softfail: the sending server is not in your SPF record. Add the service, or check which domain it uses as the return path.
2. spf=permerror: the record is invalid. The usual reasons are two SPF records or more than ten DNS lookups.
3. spf=none: no SPF record exists for the return-path domain.
4. dkim=none: the message was not signed. Signing has not been turned on at the sending service.
5. dkim=fail: the signature did not verify. The DNS key is wrong or truncated, or the message was altered in transit.
6. dkim=pass with another company's domain: signed, but not by you. Enable the service's custom domain signing.
7. dmarc=fail: neither SPF nor DKIM passed with alignment to the From domain.

Alignment is the usual culprit

The second example above is the most common pattern for mail sent through a third-party platform. DKIM passes, but the signature belongs to the platform. SPF is evaluated against a return path that is either the platform's or not authorised. Nothing in the message is tied to the visible From domain, so DMARC fails.

The fix is at the platform, in a section usually called domain authentication or sender authentication. It asks you to publish a few DNS records so that the platform can sign with your domain. After that, the header should show your domain next to dkim=pass.

Check the DNS records behind it

Once you know which check failed, read the public records. They should each return exactly one answer.

dig example.com TXT +short | grep spf1
dig _dmarc.example.com TXT +short
dig s1._domainkey.example.com TXT +short
dig example.com MX +short

Reputation

If authentication is clean and mail still goes to spam, the cause is almost always reputation. Mailbox providers keep a running assessment of each sending domain and each sending IP address, built from how recipients treat the mail: whether they open it, delete it unread, move it to spam or move it out of spam.

Reputation attaches to several things at once. A new domain has none, and providers are cautious with it. A shared IP address at an email service carries the reputation of every customer using it. A domain that was used carelessly in the past keeps that history for a long time. Reputation is specific to each provider, so mail can reach the inbox at one and go to spam at another.

The large providers offer free dashboards where a verified domain owner can see reputation and complaint data. They are the only source for these numbers. No external tool can measure them.

Complaints and list quality

The single strongest negative signal is a recipient pressing the spam button. Providers ask bulk senders to keep the complaint rate below 0.1 percent, and sustained rates around 0.3 percent lead to filtering and rejection. A rate that looks tiny is already a problem.

Complaints follow from who is on the list and how they got there.

1. Send only to people who asked for the mail. Bought, scraped and borrowed lists are the fastest route to the spam folder.
2. Confirm new addresses with a confirmation message, so that typos and addresses entered by someone else never join the list.
3. Remove addresses that hard-bounce immediately.
4. Stop mailing addresses that have not opened or clicked in many months.
5. Make unsubscribing a single click, and honour it at once. People who cannot find the unsubscribe link use the spam button instead.
6. Beware of very old lists. Abandoned addresses are sometimes converted by providers into spam traps.

Volume and consistency

Sudden changes in sending behaviour look like a compromised account or a spam run. A domain that normally sends two hundred messages a day and suddenly sends fifty thousand will be throttled or filtered, however good the content.

A new domain or a new dedicated IP address has to be warmed up: begin with small volumes to the most engaged recipients and increase over several weeks. Keep the sending pattern steady afterwards. If you must send a large one-off campaign, split it over several days.

Content and structure

Content is the last thing to examine, and a few points do matter. They are less about particular words than about whether the message looks like what it claims to be.

1. Links that go somewhere other than where the visible text says, and public link shorteners, which are heavily abused.
2. Link and image domains with a poor reputation of their own. Use your own domain for tracking links where the platform allows it.
3. A message that is one large image with little or no text.
4. No plain-text version alongside the HTML.
5. Broken or bloated HTML pasted from a word processor.
6. Attachments of types often used for malware.
7. A From name or address that changes from one send to the next.
8. A missing physical address or unsubscribe link in marketing mail, which is also a legal requirement in many countries.

Infrastructure checks for your own mail server

If you send through a mailbox provider or an email service, they handle the server side. If you run your own mail server, a few basics are required before reputation even comes into play: a reverse DNS record for the sending address that matches a forward record, a HELO name that is a real host name, TLS for outgoing connections, and an address that is not on the major blocklists. Addresses in residential and dynamic ranges are blocked by most receivers outright.

dig -x 203.0.113.10 +short      ; mail.example.com.
dig mail.example.com A +short    ; 203.0.113.10

The order to work through it

Working in this order avoids spending time on the wrong layer.

1. Read the Authentication-Results header of a message that went to spam.
2. Fix any SPF, DKIM or DMARC failure, and any alignment failure, before anything else.
3. Check the public DNS records for duplicates and errors.
4. Look at the providers' own dashboards for reputation and complaint rate.
5. Review how addresses join the list and when they are removed.
6. Look at recent changes in volume, sending system or From address.
7. Only then review links, images and structure in the message.
8. Send again to a small, engaged group and watch the result before returning to full volume.

What recovery looks like

Authentication fixes take effect as soon as DNS updates. Reputation does not. Once a provider has learned to distrust a sender, it takes weeks of consistent, wanted mail to change that. During recovery, send less, to the people most likely to open it, and let positive signals accumulate. Asking a few recipients to move a message out of spam and reply to it helps at the margin; it does not replace fixing the cause.

There is no setting, record or phrase that guarantees inbox placement. Providers decide per recipient, and a message one person wants is one another person reports.

What a DNS check can and cannot tell you

A check of public records answers the first question on this list and only that one. It shows whether SPF, DKIM and DMARC records exist, whether they are valid, and whether a record has changed. It cannot see reputation, complaint rates, engagement or the content of your mail, and it cannot predict where a message will land. The CloudSpex Email Security Check reads the records a receiver would look up and reports what it measured; monitoring them matters because authentication that worked last month is the thing most likely to have broken quietly since.