Why email goes to spam, and how to fix each cause

Mail goes to spam for one of six reasons, and they are checked roughly in this order: the sending IP is on a blocklist, the IP has no matching reverse DNS, SPF, DKIM or DMARC fails or does not align, the IP or domain has a poor or empty reputation, recipients have complained or ignored previous mail, or the content looks like spam. Content is last on that list and is the first thing people change, which is why so much deliverability advice does nothing. The useful approach is diagnostic: read the headers of a message that landed in spam, check the first five causes in order, and fix the one that is actually failing.

This post goes through each cause, how to tell whether it is yours, and what fixing it involves - with the caveat that the largest receivers do not publish their filters, so where the post describes their behaviour, it is the behaviour they document or that is widely observed.

Start with the headers#

Before changing anything, get a message that landed in spam and read its headers. In Gmail, open the message, choose Show original, and the top of the page summarises SPF, DKIM and DMARC. In Outlook on the web, View message details. In Thunderbird, View, then Message Source. Look for:

Authentication-Results: mx.google.com;       dkim=pass header.i=@example.com header.s=s2026a;       spf=pass (google.com: domain of anna@example.com designates       203.0.113.25 as permitted sender) smtp.mailfrom=anna@example.com;       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.comReceived: from mail.example.com (mail.example.com. [203.0.113.25])

Three passes and header.from matching your domain means authentication is not the problem, and the Received: line shows your HELO name and the reverse DNS of your IP side by side. If anything there is wrong, fix that first. Nothing else matters while authentication fails.

On your own Stalwart server, incoming mail carries X-Spam-Status and X-Spam-Result headers listing every rule that fired with its score. Other servers do the same with their own headers. When a message from you lands in spam at a recipient who runs a filter like that, ask them for the headers - they tell you exactly why.

It also pays to keep a few test mailboxes of your own: a personal Gmail, an Outlook.com address, and one at a smaller provider. Send to all three after any change to DNS, keys or relays, and check where each message landed. Three data points are not statistics, but they catch a broken record within minutes rather than after a week of customer complaints.

The sending IP: blocklists and reverse DNS#

The first two checks are about the address your mail comes from, before a single byte of the message is read.

Blocklists

A DNS blocklist (DNSBL) is a list of IP addresses (or domains) known to send spam, queryable over DNS. Receivers check the connecting IP against several during the SMTP conversation. A listing on a major list usually means outright rejection with a 5xx error naming the list, not just the spam folder.

The lists that matter most:

Check your IP by reversing its octets and querying the list:

# Is 203.0.113.25 on Spamhaus ZEN (SBL + XBL + PBL)?$ dig +short 25.113.0.203.zen.spamhaus.org# No answer: not listed. 127.0.0.x: listed (the last octet says which list)

Spamhaus does not answer queries that come through large public resolvers such as 8.8.8.8 - it returns a special error code instead - so run the check from a server using its own resolver, or use the lookup page on the list's website, which is also where delisting happens.

Getting delisted: find out why you were listed (the list's page says), fix the cause - usually a compromised account or a form being abused - and then request removal. Listings for a fixed problem are generally removed quickly; repeat listings take longer each time.

Reverse DNS and the HELO name

Large receivers expect the sending IP to have a PTR record, the PTR name to resolve back to the same IP, and the server to introduce itself with a sensible host name. Gmail requires this for everyone sending to it. A missing PTR, or a generic one like 203-0-113-25.dynamic.provider.example, makes the IP look like an infected home machine.

The fix is set by whoever owns the IP, not in your zone. Reverse DNS and PTR for mail servers goes through it. If you cannot get a PTR set, sending through a relay solves it, because the relay's IPs have one.

Authentication and alignment#

SPF, DKIM and DMARC are the entry ticket. Since 2024, Gmail and Yahoo require SPF or DKIM for all senders, and both plus DMARC for anyone sending more than about 5,000 messages a day; Microsoft announced similar rules for Outlook.com in 2025. Mail that fails is spam-foldered or rejected.

The common failure is not a missing record but alignment: SPF passes for a provider's bounce domain and DKIM is signed by the provider's own domain, so neither matches the From: address. DMARC reports and policy rollout shows how to find and fix those senders, and DKIM keys and rotation covers the signing side.

Other authentication slips that send mail to spam:

• Two SPF records at the same name - a permanent error, which fails SPF for everything.
• An SPF record with more than ten DNS lookups - the same permanent error.
• A DKIM key published with a typo or truncated - dkim=fail or permerror.
• A From: address on a domain you do not control, such as a web form sending "from" the visitor's own address. Use your domain in From: and put the visitor in Reply-To:.

Reputation and warm-up#

Reputation is the receiver's memory of you, attached to your IP and, increasingly, to your domain. It is built from how recipients react to your mail: opened, replied to, moved out of spam, added to contacts - or deleted unread, reported as spam, sent to addresses that do not exist.

A new IP or a new domain has no reputation, and no reputation is treated cautiously. That is why a perfectly configured new server still sees some mail land in spam for the first weeks. The fix is time and a gentle start:

1. Start with mail people expect and reply to. Person-to-person conversation is the best possible reputation builder.
2. Ramp volume gradually. If you will send a newsletter to 10,000 people, do not send it all on day one from a new IP. Start with a few hundred of your most engaged recipients and grow over two to four weeks.
3. Keep the pattern steady. Sudden spikes from a quiet sender look like a compromised account.
4. Separate streams. Put marketing on its own subdomain or its own service, so a bad campaign does not drag down invoices and password resets.

You can watch reputation at the two largest receivers. Google Postmaster Tools shows domain reputation, spam rate and authentication results for mail to Gmail, once you verify your domain and send enough volume. Microsoft SNDS shows data for your IP addresses at Outlook.com. Both are free.

List hygiene and engagement#

Every bounce, complaint and ignored message counts against you.

• Remove hard bounces immediately. An address that returned 550 user unknown once will not come back. Sending to it repeatedly is a strong spam signal, and old addresses are sometimes turned into spam traps.
• Never buy or scrape lists. They contain spam traps - addresses that never signed up for anything, operated by blocklists and receivers to catch exactly this.
• Make unsubscribing easy. For bulk mail, Gmail and Yahoo require one-click unsubscribe, implemented with the List-Unsubscribe and List-Unsubscribe-Post headers (RFC 8058), honoured within two days. A recipient who cannot unsubscribe presses "Report spam" instead.
• Prune the unengaged. People who have not opened anything in a year are dragging down your engagement figures. Re-confirm or remove them.

None of this applies much to a team's day-to-day mail, which is why ordinary business mail from a well-configured server rarely has problems. It applies heavily to anything sent in bulk.

Content#

Content matters, but less than people think, and usually as a tiebreaker for mail that is borderline on everything above.

What actually counts against you:

• Links to domains with bad reputations, including URL shorteners that spammers also use. Link to your own domain.
• A mismatch between link text and target, such as text showing one URL while the link goes elsewhere.
• One large image with little or no text. Spam filters cannot read images, so they treat image-only mail with suspicion.
• No plain-text part in HTML mail, or broken HTML from a template pasted out of a word processor.
• Attachments of risky types - executables, macro-enabled documents, password-protected archives. Many receivers block them outright.
• A `From:` display name that does not match the address, or an address like noreply@ on mail you want people to engage with.

What does not matter much any more: individual "spammy words". Modern filters are statistical and look at the whole message and its sender, not a list of banned phrases.

Content testing services that score a sample message are useful for catching the mechanical problems - a broken DKIM signature, a link domain on a blocklist, a missing plain-text part. They cannot tell you how Gmail feels about your domain, because that depends on history they do not see. Treat a perfect score as "nothing obviously broken", not as a promise of the inbox.

One more content trap is specific to self-hosted servers: forwarding. If your server forwards a user's mail to an outside mailbox, it forwards the spam too, and the outside provider holds your server responsible for it. Forwarded spam is a quiet way to damage your own reputation. Prefer having users collect mail from your server over IMAP rather than forwarding it all elsewhere.

A diagnostic order#

When mail goes to spam, work through this list in order and stop at the first failure:

1. Rejected with a `5xx` mentioning a list? Blocklist. Check, fix the cause, delist.
2. `Received:` header shows no reverse DNS or a generic one? PTR. Get it set, or use a relay.
3. SPF, DKIM or DMARC not `pass`, or `header.from` not your domain in the passing result? Authentication or alignment.
4. New IP or domain, or a recent volume spike? Reputation. Slow down, send to engaged recipients, wait.
5. Bulk mail with high bounces or complaints? List hygiene.
6. Only some messages affected, all else clean? Content - look at links, images and attachments in those messages.

Also check where in the receiving system the mail went. Gmail's Promotions tab is not spam; it is where Gmail puts commercial mail, and no setting on your side reliably moves you out of it.

Spam and a RE:NODE Mail Server#

On a Mail Server plan you run Stalwart, so causes 3 to 6 are in your hands: the web admin generates DKIM keys per domain, you publish MX, SPF, DKIM and DMARC, and the volume and content are yours. Causes 1 and 2 depend on the address you send from. Whether a PTR can be set for your server's address is something to ask support rather than assume; and if a network refuses outbound port 25 or your address is not suited to sending directly, a relay set in the web admin sends your mail from IPs with established reverse DNS and reputation while Stalwart still signs it with your keys. For incoming mail, Stalwart's own spam filter does the judging - mail server spam filtering covers tuning it. The overall picture is in the self-hosted mail server guide.

FAQ#

Why does my mail go to spam at Gmail but not Outlook?

Each receiver has its own filters and its own memory of you. Gmail weighs domain reputation and engagement heavily; Outlook leans more on IP reputation. Check Google Postmaster Tools and Microsoft SNDS separately, and compare the authentication results in headers from both.

I passed SPF, DKIM and DMARC. Why is it still spam?

Authentication proves who you are, not that recipients want your mail. Look at reputation next: a new domain or IP, a recent spike in volume, or complaints. Then check content, especially link domains.

Does adding an unsubscribe link help personal email?

No, and it can look odd. One-click unsubscribe is required for bulk and marketing mail. Person-to-person mail does not need it.

How long does it take to fix a bad reputation?

Weeks of consistently clean, wanted mail at low volume. Blocklist delisting can be quick once the cause is fixed, but reputation at the large receivers recovers gradually.

Will moving to a new IP fix it?

Only if the problem was the IP alone, and a new IP starts with no reputation, which has its own cost. If the cause was your list, content or a compromised account, the new IP inherits the problem within days.