Why mail goes to spam when „nothing was changed”

“We didn’t change anything” is usually true — and that is exactly what makes it misleading. Spam filters do not judge a message once and for all. They judge it afresh every time, based on what they know about the sender today. So everything around you may have changed while your configuration stayed untouched.

Below are the causes in order of frequency. Work through them in order rather than starting with the one that sounds most interesting.

1. No sender authentication

The most common cause and the only one that can be solved permanently.

If the domain has no properly configured SPF, DKIM and DMARC, large mail providers treat it as suspect by default. Since 2024 Google and Yahoo have required authentication from all senders — what used to be a recommendation is now a condition of delivery.

To check:

dig TXT yourcompany.com +short          # should contain v=spf1
dig TXT _dmarc.yourcompany.com +short   # should contain v=DMARC1

No answer to the second command is the most common starting state. The fix is described separately — several weeks of work, but done once.

2. Somebody is impersonating the domain

If someone has spent the last few weeks sending spam with an address in your domain, the domain’s reputation drops — and your genuine messages go down with it.

The characteristic symptom: bounce messages about undelivered mail to people nobody wrote to. That is not a server fault; it is the echo of somebody else’s sending while impersonating you.

Without DMARC there is no way to detect this early or to stop it. That is the second reason why point one comes first.

3. The server’s IP address is on a blocklist

Mostly affects companies with their own mail server or on shared hosting.

On shared hosting it is enough for a neighbour on the same IP address to start sending spam. Your configuration is impeccable and the mail still lands in spam, because the filter judges the address, not the company.

To check: put the server’s IP address into any blocklist lookup tool. If it is listed, the delisting procedure is described by whoever runs that particular list — usually you remove the cause and submit a request.

A conclusion for the future: for company mail, shared hosting is a false economy.

4. The PTR record does not match the server name

The reverse check: the filter asks what name belongs to the address the mail came from, and expects it to be the mail server’s name. A missing reverse record, or a default name from the operator (host-89-64-x-x.dynamic...), is a warning sign.

dig -x IP_ADDRESS +short

The PTR record is set by whoever hosts the server — you cannot add it in your own DNS. On cloud services it is set in the control panel.

5. A sudden rise in message volume

The company bought a quoting tool and on day one sent three thousand messages from an address that had been sending thirty a day.

Filters treat a step change in volume as a classic sign of a compromised account. The remedy is warm-up: raising volume gradually over two to three weeks. Serious sending tools have this built in; you only have to use it rather than switch it off.

6. Content, but less often than people think

The content itself matters less than reputation, though not nothing. What genuinely hurts:

• a message that is one large image with no text,
• links passed through URL shorteners,
• an attachment with an executable extension, or a password-protected archive,
• a link domain different from the sender domain and with poor reputation of its own.

Classic advice about avoiding CAPITALS and the word “free” comes from an era when filters really did work that way. Today it is marginal.

7. The recipient has a rule of their own

Before you start looking at your side, rule out the simplest thing: does this affect all recipients or one. If messages disappear only at one customer, the cause is almost certainly on their side — a rule in the mailbox, a filter on their server, or somebody at their company having marked your address as spam earlier.

The order to check in

1. One recipient or everyone? Splits the problem into two entirely different ones and takes a minute.
2. SPF, DKIM, DMARC — two dig commands.
3. The IP address on blocklists.
4. The PTR record.
5. Whether anything changed in sending volume.
6. Content, last of all.

What not to do

Do not change everything at once. This is the most common mistake: in one day the company adds SPF, changes the sending server and rewrites the message template. If it helps, nobody knows what helped; if it hurts, even less so.

Do not ask recipients to add you to their contacts as the solution. That works for one person and fixes nothing for everyone else. The sender’s reputation is on your side and that is where it has to be repaired.