You stop emails going to spam by identifying which system is failing, then fixing that one. There are three candidates, and they produce an identical symptom in your inbox, which is why applying fixes in the order the internet lists them so often changes nothing.
Before deliverability I practiced medicine, and the habit that carried over is refusing to treat a symptom. Mail landing in spam is a symptom. Authentication, reputation and engagement are the places the cause actually lives, and each one needs different evidence and moves on a different timeline.
What follows is the sequence, why it runs in this order, and what each step rules out.
Find the cause before applying a fix. Almost every deliverability problem traces back to one of three systems: whether mailbox providers can verify you, what your sending history has already taught them to expect, and how recipients actually treat your mail. Check them in that order, because the first takes minutes and the last takes weeks.
Those three are the first three gates of the six-gate order I run, and they resolve most cases before the later ones are needed. The sequence is not the order most guides use. I start with whatever is fastest and cheapest to rule out, then move to the slower checks only once the fast ones are eliminated. Authentication alignment is a DNS lookup. Reputation is an afternoon inside Google Postmaster Tools. Engagement and list quality need behaviour watched across multiple sends before any pattern is reliable.
Most senders run this backwards. They spend three weeks rewriting subject lines and pruning segments before ever confirming their DMARC alignment is correct, because content advice is what gets written about most, not because content is the most likely cause. I go deeper into why the order matters in the diagnostic method behind all of this.
Authentication, because it is the only cause you can confirm or eliminate in about ten minutes. Pull your SPF, DKIM and DMARC records, then check that the domain in your From address matches the domain those records are published on. A record that exists is not the same as a record that aligns.
The failure I find most is not a missing record. It is a domain where SPF and DKIM both pass, but the From address sits on a different domain from the one those records authenticate, so DMARC alignment fails quietly. Every basic checker shows green. The check that decides placement is the one that failed.
Reputation is the answer when authentication comes back clean and placement still drops. Google Postmaster Tools reports domain and IP reputation in four bands and plots your spam rate over time. A band below high, with a visible spike on the spam rate graph, means reputation is an active cause rather than background noise.
Reputation is sticky by design. It is scored on a rolling window, so one bad week suppresses placement for weeks afterwards while the average works its way back. That property is what makes it worth checking second: you cannot fix it today, so you want to know early whether it is what you are dealing with.
Damage almost always traces to one identifiable event. A send to an old or purchased list, a volume spike from a new campaign, an account sending mail nobody asked for. The mail itself can be perfectly authenticated and still get buried, because what is being scored is the sender, not the message.
Then the cause is in engagement or in infrastructure you share with other senders. Both take longer to isolate because neither shows up in a single lookup. Engagement is read from how recipients behave across several sends, and shared infrastructure means part of your reputation belongs to whoever else is sending from the same pool.
Engagement is the cause I see missed most often, because nothing looks broken. The list is simply mailed too often to people who stopped opening months ago, and the mailbox provider has quietly learned to route around them. Sustained low engagement teaches that model your recipients do not want this mail, and it does that regardless of how clean your authentication is.
Shared infrastructure is the other one, and it has no configuration fix, because nothing about your setup is wrong. I wrote up how to tell whether a pool is dragging you down in shared IP pools, when your reputation is not yours.
Three gates still sit below those. A placement test separates content from infrastructure by sending known-good mail through your own setup and seeing where it lands. Content comes after that, because it is rarely the sole cause and is the thing most often blamed first. Last is the case where nothing is wrong with your sending at all: one recipient out of many reporting spam, with everything else clean, is that person's own filter learning their habits.
An authentication fix takes effect once DNS propagates, usually inside 24 to 48 hours. A reputation problem recovers over weeks of clean sending, because reputation is a rolling score rather than a current state. An engagement problem is slowest, since it only improves after your sending pattern has produced better recipient behaviour across multiple sends.
Those three timelines are the practical argument for the order. If you guess wrong and the cause was reputation, you find out in three weeks. If you check authentication first and it was authentication, you find out before lunch.
Confirming one cause is not the same as finding all of them. Deliverability problems stack. I have seen a domain carrying a genuine authentication fault while also sitting on a contaminated shared pool, where fixing the authentication produced a small improvement that then flattened, because the second cause was still running underneath.
So when a fix produces partial recovery and then stops, that plateau is information. It usually means the first cause was real and there is a second one behind it. Going back to the top of the order and running it again on the new evidence is faster than assuming the fix underperformed.
Rarely on its own. Wording and content are a real input to filtering, but they sit on top of authentication and reputation rather than replacing them. A sender with a damaged reputation lands in spam with a carefully written subject line. Content changes are worth making once the two faster checks come back clean.
Usually yes. Migrating changes your infrastructure without touching authentication alignment, sending history or list quality, which is where most causes live. The exception is a shared IP pool whose reputation you do not control. That one is genuinely an infrastructure problem, and moving is the fix rather than an expensive way to avoid diagnosing.
Cutting volume reduces the damage while you work, but it does not resolve the cause. Sending less to the same disengaged list produces the same signals at a lower rate. Cutting volume to your least engaged segments while continuing to mail the engaged ones is a different action, and that one does change what mailbox providers see.
When the evidence that identified the cause has moved, not when a test send lands in an inbox. A single test tells you almost nothing, because one message is not a pattern. For an authentication fault, alignment now passes. For reputation, the band has climbed and held across several sends.