My mail goes to spam: how to find out what is really happening

There are three different things people call "going to spam", and they are not fixed the same way. Either you are rejected at the door, in which case there is a bounce carrying a code that says exactly why. Or you are accepted and filed in the junk folder, in which case there is no bounce and the recipient will find you if they go looking. Or you are accepted and the message never surfaces anywhere. To work out which one is yours you only need to check one thing: whether there is a bounce, and what code it carries.

The first case has become far more common. In November 2025 Google escalated from deferring non-compliant mail with temporary errors (the 421 series) to rejecting it permanently (the 550 series), and since 2025 Microsoft rejects with 550 5.7.515 any mail whose domain does not meet the required level of authentication. What was an annoyance three years ago is a hard bounce today, and that is good news: a rejection arrives with the diagnosis written on it.

Step 1: check whether there is a bounce

Before you touch anything, find the bounce. If you send from Gmail or Outlook it arrives as an automatic reply from "mailer-daemon" or "postmaster" to the same account you sent from, with the code inside, almost always at the end of the English text. If you send through a campaign tool it sits in that tool's bounce panel, not in your inbox. And if you run your own server it is in the delivery log. A typical bounce reads like this:

550-5.7.26 Your email has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550 5.7.26 Authentication results: DKIM = did not pass, SPF [empresa.es] with ip: [203.0.113.10] = did not pass

Case A: you are rejected (there is a bounce and there is a code)

The first digit of the code tells you whether the rejection is temporary or final. The 4xx series is a deferral: the server is asking you to try again later and your own server will retry on its own. The 5xx series is permanent: resending without changing anything only damages your reputation further. This table resolves almost every bounce from the three big providers:

Case B: you are accepted and land in the junk folder

There is no bounce and no code here, which is why this is the case people waste the most time diagnosing. It helps to know something almost nobody explains: the spam rate Google publishes measures, quite literally, the percentage of your messages that recipients mark as spam by hand in Gmail. Manual marking only. Automatic filtering does not appear in that number at all. It is perfectly possible to have a spam rate of 0.05 per cent and be landing in almost everyone's junk folder.

And there are two very different families of filter making the decision. Gmail, Outlook and Yahoo classify with models trained on aggregate behaviour: who marks spam, who replies, who deletes without reading. Banned-word lists are essentially a myth there, and the proof is an absence: Google's official sender guidelines contain no word list whatsoever, only rules about format and honesty. But a good share of your Spanish B2B recipients sit behind the other kind of filter: a SpamAssassin bundled with cPanel or Plesk, or a corporate Rspamd, where content rules carry published numeric scores that add up.

Which leads to the only honest way of putting it: you do not optimise for words, you optimise for structure, because the right structure passes both kinds of filter. Always send multipart with a plain-text part. Keep the HTML under 100 KB (Google does not publish the figure, but it clips long messages, and the clipping takes the footer and the unsubscribe link with it). Never send an email that is a single image. Do not hide text with CSS. And do not use public link shorteners: the link domain is evaluated separately and may be listed on the Spamhaus DBL, so your message inherits somebody else's problem.

Case C: the silent disappearance

The server accepted the message, there was no bounce, and the recipient cannot find it in the inbox or the junk folder. It is the least frequent case and the most baffling. The usual causes are these:

• A corporate anti-spam gateway has quarantined it and only the administrator can see it, not the user. This is standard in medium and large companies.
• The recipient has an inbox rule that archives or deletes, often created years ago and long forgotten.
• The mailbox is a catch-all that accepts any address and discards whatever it does not recognise. On Spanish corporate domains running Microsoft 365 this is very common.
• There is a forwarder in the path that broke the signature, and the final destination discarded the message. This is precisely the problem ARC solves, and it is the intermediary who implements it, not you.
• Greylisting: the destination returned a temporary 4xx, your tool gave the message up for lost and never retried.

The way out of the doubt is to ask the recipient to search the whole account by sender, not just the inbox, and in parallel to look at the delivery errors panel in Google Postmaster Tools, which Google defines as the percentage of authenticated messages rejected or temporarily failed. That panel moves before the spam rate does, and it is the early warning of a block.

The decision tree, in four questions

1. Is there a bounce?Yes, with a 5xx code: case A, permanent rejection. Yes, with a 4xx: case A as well, but temporary, and it is nearly always sending rate or half-finished authentication. No bounce at all: go to question 2.
2. Does it happen with every destination or just one?If it fails at Gmail and at Outlook and at the client's own mail server, the problem is yours and it is configuration. If it fails at a single provider, read that provider's documentation: Microsoft and Google neither require the same things nor reject in the same way.
3. Does it affect all your mail or only campaigns?If normal replies arrive and only bulk sends vanish, it is not domain authentication: it is reputation, content or list quality. If not even a hand-written email gets through, it is authentication, and that gets fixed first.
4. Since when?If it started abruptly on a particular day, find out what changed that day: a new tool added to the SPF record, a change of mail provider, a DKIM key rotated halfway. The number one cause of "it suddenly stopped arriving" is an SPF record that went past ten lookups when one more service was added.

The faults that explain most cases

What is almost never the cause

It is not the word "offer" in the subject line. It is not the emoji (although it is worth removing from the display name, because Google asks for that in writing). It is not that it went out on a Tuesday. What Google publishes is not a dictionary of forbidden words, it is a set of formatting requirements:

In order of real impact, what actually decides the outcome is this: broken or misaligned authentication, a complaint rate above 0.30 per cent, the domain behind your links, dirty HTML, attachments on a first contact, and hidden text. Everything else is noise, and chasing it is the most common way to lose three weeks without moving a thing.

What to do now, in order

1. Find a recent bounce and keep the code. If there is no bounce, you already know it is not a delivery problem.
2. Check the public records for your domain: exactly one SPF record, staying under ten lookups, DKIM signing with your domain, and a DMARC record that exists.
3. Open one of your own emails as received in Gmail, look at the Authentication-Results header and check whether dmarc says pass or fail. That is where alignment shows up, and alignment is what no cheap tool looks at.
4. Register the domain and every sending subdomain in Google Postmaster Tools. It is free and it is the one source with no opinion of its own.
5. Only then touch the content, and touch it structurally: multipart with plain text, no shorteners, no attachments, links on your own domain.

If step 2 has left you with more questions than answers, the guide to SPF, DKIM and DMARC explains the three records and, above all, alignment: the reason all three can show green in any checker and DMARC can still fail on one hundred per cent of your mail.