Why Your Emails Go to Spam, and What Actually Helps

The pattern is nearly always the same. A form confirmation never reaches the customer, half the newsletter recipients find it in the promotions or spam folder, and the first search for a fix produces a list of words to avoid in the subject line. So the exclamation mark goes, "free" gets rewritten, and nothing changes.

That happens because the advice targets the smallest lever available. A receiving mail server first asks who is writing, and only then asks what the message says. The first question is answered by three DNS records and by what your domain has been sending over the past few weeks. Neither of those lives in the subject line.

This article ranks the levers by how much they actually move. By the end you will know which record to touch next.

Work through the levers in this order

Most deliverability checklists throw twenty items into one pile and weight none of them. Ranked by effect, the picture gets a lot simpler:

1. Authentication. SPF, DKIM and DMARC are in place and alignment holds.
2. Sending path. Your mail leaves a server that your own DNS records permit to send for the domain.
3. List quality. Every address on the list gave documented consent, and bounces get removed.
4. Sender reputation. Volume and frequency match what this domain has sent so far.
5. Content. Subject, copy, image-to-text ratio, number and destination of links.

Item five gets the most coverage online. It only starts to matter once the four above it are settled. Reverse the order and you are polishing wording on a message the receiving server cannot attribute to anyone in the first place.

What SPF, DKIM and DMARC actually check

The three get named in one breath constantly and confused just as constantly. They answer three different questions.

SPF says which servers are allowed to send

SPF is defined in RFC 7208. It is a TXT record on your domain listing the servers allowed to hand over mail in that domain's name. The receiving server compares the IP address of the delivering server against that list and gets an answer to one question: is this route permitted.

The second most common failure in practice sits right here. Evaluating an SPF record is allowed to trigger at most ten DNS lookups, and every service you include costs at least one. Add your mailbox provider, a newsletter service, an invoicing tool and a helpdesk one after another and you will cross the limit. The result is a permerror, and an SPF record that produces a permerror is worthless. It still looks perfectly ordinary in your DNS panel.

DKIM proves nothing was altered in transit

DKIM is specified in RFC 6376. A cryptographic signature is added to the message header on the way out, and the matching public key sits in your domain's DNS. The recipient checks two things with it at once: the message really originates from that domain, and the signed portion arrived unchanged.

DMARC ties the two together with an instruction

DMARC is described in RFC 7489. It is the record that turns two check results into a decision. You state what a receiver should do when the check fails. There are three values: none means take no action, quarantine means put it in the spam folder, reject means refuse it. DMARC also sets up the reporting channel that tells you who is sending under your name.

By far the most common mistake in the field: the record sits at p=none and stays there forever. As a starting point that is correct, because the first thing you want is visibility into what goes out in your name. As a permanent state it is a line in your DNS with no effect. A record that means business ends up looking like this:

_dmarc.yourcompany.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com"

Alignment is where most setups fail

Here is the part almost every guide skips. DMARC does not only check whether SPF or DKIM passed. It additionally requires the visible sender domain to match the domain that was checked. That requirement is called alignment.

In practice it plays out like this. You send your newsletter through an email service provider. Your own address appears in the From field. Technically, though, the provider hands the message over, and the provider has a clean SPF record for its own domain. So SPF passes. The signature is applied with the provider's domain too. From DMARC's point of view a foreign domain was verified while yours is the one on display. Alignment fails, DMARC fails with it, and every checking tool still shows a green SPF result.

Every serious provider offers the same remedy: add your own domain inside your account with them, then publish the DKIM key they issue for it in your DNS. After that the signature is issued for your domain, alignment holds and DMARC passes.

What Gmail, Yahoo and Outlook.com require from bulk senders

Since February 2024 Google and Yahoo have applied requirements to bulk senders, meaning roughly anyone sending more than about 5,000 messages a day to Gmail accounts. Those requirements are SPF, DKIM and DMARC, a working one-click unsubscribe in the mail header per RFC 8058, and a spam complaint rate below 0.3 percent. Microsoft announced and implemented comparable requirements for Outlook.com in 2025.

If you are well below that volume you do not formally count as a bulk sender. That changes nothing about the setup, though. The three records cost you an hour once, one-click unsubscribe is something your sending tool handles, and the complaint rate follows from the state of your list at any volume. The only difference below the threshold is that nobody is measuring you against it.

Find your case in this table

Why the first big send almost always gets throttled

Receiving systems keep a kind of history for every sending domain. A domain that sent nothing for years and then hands over 2,000 messages on a Tuesday morning looks like a compromised account. It gets throttled, and how tidy your DNS records are makes no difference to that.

The way out is warming up, and it is unglamorous. Start small and raise the volume over several weeks. Begin with the recipients who most recently opened, clicked or bought, because their response is what builds the reputation. The contacts you have not heard from in a long time come later.

If the newest contact on your list is three years old, warming up on its own will not carry you. In that case the list needs work before the sending does.

A clean list beats any amount of copy tuning

Purchased lists, addresses that have aged for years and bounces nobody acted on will cost you more deliverability than every trigger word you ever avoided. The reason is straightforward: each message to a dead address and each complaint is a signal that counts directly against your reputation.

The rules are short. Hard bounces, meaning addresses that are permanently undeliverable, come off the list immediately. Soft bounces can be retried a few times and then removed. A complaint means an unsubscribe on the spot, with no confirmation step. Addresses that have opened nothing in years are a liability for everyone else on the list.

All of that starts with consent. What a proper double opt-in looks like, what has to be logged and why it helps you technically as well is covered in the article on double opt-in and the GDPR. This is a practical explanation and not legal advice; for a binding assessment of your own situation you need a qualified lawyer.

WordPress sends the wrong way by default

This deserves its own section, because in small projects it is the single most frequent cause. WordPress sends through wp_mail, and with no further configuration that ends up calling the PHP function mail(), which hands the message straight to the web server. That web server is usually in no SPF record of yours and signs nothing. So the message goes out and fails both checks at the same time.

The usual fix is to route sending through SMTP or through your sending provider's API, using your own verified domain. This applies to everything your site sends automatically: form confirmations, password reset messages, order confirmations and invoices. Those messages matter more to the customer than any newsletter, and they are the ones that disappear most quietly.

Where you are wasting your time

That leaves the question of what survives from the usual advice. Trigger words in the subject line are the classic, and today they are largely folklore. Filters weigh sender behaviour far more heavily than individual words. The word "free" in a subject line is no problem while the sender has a good reputation, and it rescues nothing while the sender has none.

None of which makes subject line work pointless. It simply pays into open rates and not into delivery. Keeping those two jobs apart saves you a lot of fruitless rewriting.

What the free tier covers and where Pro starts is listed on the pricing page. One honest caveat: branching automation sequences in Kurato are still being built.

Frequently asked questions