Email deliverability is whether the systems receiving your mail decide to put it in front of the person you sent it to. It is not whether the message was accepted. A message can be accepted by Gmail, logged as delivered by your sending platform, and filed straight into spam, and every number on your dashboard will still look healthy.
That gap is where most of the confusion lives. Your platform reports delivery, which means a receiving server took the message off your hands. Placement is a second decision made after that, by a filter reading your sending identity, your recent sending history, how these particular recipients have treated your mail before, and what is inside the message. You get no dashboard for that decision. You infer it from signals.
This guide is the whole method I use to infer it. Six checks, run in a fixed order, stopping at the first one that fires. The order is deliberate and it is not a checklist worked through top to bottom for completeness. It is an order of elimination, sequenced by how fast each cause can be ruled out rather than by how likely it is to be the answer.
I came to this from medicine, where a symptom is not a diagnosis and you do not treat before you know what you are treating. Mail landing in spam is a symptom. Six different causes produce it, they look identical from the outside, and the fix for one does nothing for the others. Most of the wasted months I see come from people treating whichever cause they read about most recently.
Four inputs and one wildcard. The receiving system checks whether you are who you claim to be, what your sending domain and IP have done recently, how these recipients have engaged with you before, and what the message contains. The wildcard is the recipient's own filter, trained on their personal habits.
The first input is identity. SPF authenticates the envelope sender, the address a receiving server sees in the SMTP conversation rather than the one displayed in the mail client. DKIM signs the message with a key published in your DNS, and its authenticated identifier is the signing domain. DMARC ties both back to the address your recipient actually sees and tells receivers what to do when neither lines up. These are the records the receiving filter reads before it reads anything else about you.
The second is reputation, tracked separately for your sending domain and for the IP the mail left from. This is a rolling judgment built from complaint rates, spam-trap hits, blocklist appearances and volume patterns. It moves slowly in both directions, which is why it rewards patience and punishes panic.
The third is engagement, and it is the input most senders underweight. Filters watch whether your recipients open, reply, move you out of spam, or ignore you. Engagement is measured per recipient domain, so your standing at Gmail is a different number from your standing at Outlook, built from a different history.
The fourth is content: the message body, the links in it, the reputation of the domains those links point at, whether a plaintext part exists, whether the subject line matches what is inside. It matters least of the four and is the one people rewrite first.
The wildcard is the recipient. One person's filter learns their habits, and a message that is perfectly healthy across a thousand mailboxes can be filed as spam in one of them for reasons that have nothing to do with you.
You rule causes out in a fixed order and stop at the first one that fires. Six gates, in this sequence: technical front-load, domain and IP reputation, list quality and engagement, a control test, content, and the non-problem. Each gate carries a signal that either implicates it or clears it and sends you to the next.
The whole point of stopping at the first gate that fires is that a fired gate explains the symptom. Continuing past it produces a list of things that are imperfect, which is not the same as a diagnosis and is how a sender ends up with four simultaneous changes and no idea which one mattered.
Authentication and infrastructure together, checked up front because they are the cheapest thing in the method to rule out. The failures I actually find here are structural rather than subtle: two DMARC records where there should be one, two SPF records where a domain may only have one valid record, a missing include after an ESP migration, no DNS at all on a sending subdomain, or a missing tracking subdomain. DKIM is the one that most often fails quietly, particularly on Google Workspace and Microsoft 365, where the record exists but was never activated.
Infrastructure sits in the same gate. Whether you are on a shared pool or a dedicated IP, and how well that IP is managed, belongs here rather than in the reputation gate, because it is a fact about your setup that you can establish in minutes. Blocklists belong here too, with the caveat that only some of them matter. Spamhaus and Barracuda are worth acting on. Most of the rest are worth knowing about and nothing more, which is the argument I make in detail about what a UCEPROTECT listing actually means for your mail.
This is where most real cases resolve. The signals are a Google Postmaster reputation reading of bad or low, a user-reported spam rate above Google's published line, a listing on a blocklist that receivers actually consult, or a shared pool being degraded by other tenants sending badly from the same addresses. When any of those is true, it is almost always sufficient to explain the symptom on its own.
Reputation problems have a shape worth recognising. They usually start on a date, and something changed around that date: a list import, a volume jump, a new campaign type, a platform migration. When a sender tells me placement fell off a cliff, the useful question is what happened that week, not what is wrong with the emails.
The thresholds I work to for normal subscriber mail are a bounce rate above 1% being a problem unless it is a one-off, an unsubscribe rate above 1% being the same, and a spam complaint rate above 0.3% being actively harmful. An open rate in the 25 to 30% range is an acceptable signal, though it is niche-dependent enough that I treat the trend as more informative than the number.
The discriminator that matters here is what opens are doing relative to reputation. Opens declining together with reputation points at the audience. Reputation falling while opens hold up points somewhere else, and pruning the list in that second case removes the engaged recipients who were holding your standing up. That distinction decides whether a list gets cut or left alone, and getting it backwards is expensive.
Spam complaints have a mechanic that misleads people. Complaints can drag reputation down and suppress placement while your engaged core keeps receiving normally, because those mailboxes have already learned to accept you. New and marginal recipients get filtered first. So a falling open rate with a still-active core is a complaint signature rather than a dying list.
A placement test separates content from infrastructure by sending known-good mail through your own setup and seeing where it lands. It runs fourth because it costs real time to set up and read, and because the three gates above it resolve most cases before it is needed. When the first three come back clean and mail is still being filtered, this is the gate that tells me which half of the problem to look at.
Content is checked late because it is rarely the sole cause, and because most published advice about it is folklore. I only state what is traceable to a provider's own documentation. Gmail, Yahoo and Microsoft publish no image-to-text ratio threshold, so any ratio quoted as a rule is somebody's heuristic rather than a line a filter enforces. An image-heavy message is a rendering and engagement signal, and it can hurt you through that route, but not because a receiver is counting pixels against words.
What does gate delivery is the published bulk-sender requirement set. For senders above 5,000 messages a day to personal Gmail accounts, Google requires SPF and DKIM both passing with alignment, a DMARC record published at a minimum of p=none, one-click unsubscribe implemented as the List-Unsubscribe-Post mechanism defined in RFC 8058 alongside a visible unsubscribe link, valid forward and reverse DNS on the sending IP, and TLS on transmission. Those are requirements rather than suggestions.
Below that line, the content signals I act on are traceable failures rather than word lists: broken or mismatched links, a link shortener or click-tracking domain whose own reputation is poor, a missing plaintext part, and a subject line that misrepresents the message. A linked domain sitting on a blocklist damages you through the link, which is the mechanism behind a Spamhaus DBL listing on a domain you merely link to.
Before declaring a fault when nothing above has fired, I check whether there is a fault at all. If one inbox out of many shows spam and everything else is clean, that is the recipient's personal filter rather than your sending. A sports newsletter landing in spam for someone whose mailbox is otherwise all business mail is that filter working correctly. Prescribing a fix for it wastes a month and changes nothing.
The order is a cost order rather than a likelihood order. Authentication resolves in minutes, reputation takes an afternoon of reading, and engagement history takes days to reconstruct. Checking the cheapest thing first costs almost nothing when it comes back clean, and saves the entire investigation when it does not.
The data on my own monitored senders makes the distinction concrete. Across 56 domains I monitor, 51 pass SPF, DKIM and DMARC on 100% of measured mail on a median day, and 2 fall below 95% on any of the three. Authentication is almost never the thing that is broken. It is checked first because it is the fastest to rule out, not because it is the most likely cause.
That number is worth sitting with, because it contradicts how most deliverability content is organised. The overwhelming majority of published guidance leads with SPF, DKIM and DMARC, and a reader following it spends their first week on the layer least likely to be their problem. Those records still get checked first in my order. The reason is that ruling them out takes ten minutes and removes an entire category of doubt from everything that follows, not that they are where the fault usually sits.
The same logic runs the other direction at the bottom of the order. Content sits fifth because confirming or clearing it is slow and ambiguous, and because a content change made while reputation is bad produces no readable result. If you rewrite your emails during a reputation problem and placement improves three weeks later, you will credit the rewrite. The rewrite did nothing. Time did.
Google Postmaster Tools, read over weeks rather than days. It reports domain reputation and IP reputation separately, each in four bands: bad, low, medium and high. One reading tells you almost nothing. Two weeks of readings tells you where you actually sit and which direction you are moving.
The reason a single reading is close to useless is that the band is a slow-moving state rather than a daily score. Across 50 domains I monitor in Google Postmaster Tools, the reported reputation band changed 13 times in 703 consecutive readings over a seven-week window in 2026. A band is a slow-moving state. One day's reading tells you very little, and two weeks of them tell you almost everything.
The distribution across those readings gives you a sense of what normal looks like. Across 753 domain-days of Postmaster readings on the domains I monitor, 66.5% sat at high reputation, 14.9% at medium, 10.2% at low and 8.4% at bad. That describes the shape of the data rather than the share of senders, because a domain that reports on many days weighs more heavily than one that reports once.
There is a trap in the spam rate reading that catches experienced people. A spam rate that drops to zero after a spike is not automatically good news. Too little inbox-delivered volume to register a rate produces the same reading as no complaints, so a zero after a spike gets verified against send volume before anyone calls it a recovery. Google's spam rate is measured against messages delivered to the inbox rather than everything sent, and a consequence follows arithmetically: as more mail is filtered to spam the denominator shrinks, so the reported rate can rise while the absolute number of complaints falls.
If your dashboard is empty, that is usually a volume fact rather than a setup fault. Postmaster only populates data for domains above a minimum daily volume to Gmail, and Google does not publish the number. Of 160 domains connected to Postmaster in my monitoring account, 104 produce no reporting data at all. Only 56 send enough mail to Gmail for Google to report anything.
Google publishes one line and nobody publishes the other. The user-reported spam rate has to stay below 0.3%, measured against mail delivered to the inbox. No mailbox provider publishes a comparable bounce threshold, so a bounce rate gets read against your own history and grouped before it is read at all.
On the complaint side, Google states 0.3% as a hard violation line and recommends staying below 0.1%. Treating 0.3% as a target rather than a ceiling is a common and costly reading. The senders who come to me are frequently on the wrong side of it: of the domains that come to me for monitoring, 16 of the 19 for which Gmail reports a user-reported spam rate at all sit at or above Google's 0.3% line on a typical reporting day, and the median of those domains' own medians is 0.8%. That is not what a healthy sender looks like. It is what most senders look like by the time they call me.
Bounces need more care than a headline percentage. A bounce rate is not comparable across sending platforms, because each one applies its own classification and its own soft-to-hard promotion threshold to the same SMTP codes. The same failing address can be counted differently by two ESPs. Where a platform exposes the raw codes, I compare those instead, and the real difference between a soft and a hard bounce is a platform decision layered on top of a protocol fact.
The protocol fact underneath is simple. A 4yz reply is a transient negative completion and a 5yz reply is a permanent negative completion. Enhanced status codes take the form class.subject.detail, so 5.1.1 is a bad destination mailbox address and 4.2.2 is a full mailbox. Those distinctions survive across every platform, which is exactly why I read them rather than the dashboard's category.
Rarely on its own, which is why I check it last. Content is usually the amplifier of a reputation problem rather than its source. The exception is the published requirement set that gates delivery outright, and those requirements are documented by the providers rather than inferred from folklore about trigger words and exclamation marks.
The practical version of this is that content changes are readable only when reputation is stable. If your domain reputation is low, the filter is reading your sending history before it reads your words, and no rewrite gets ahead of that. Warmup already includes content warmup with link interaction, so content reputation tends to lift alongside the domain rather than needing separate work.
Genuinely spammy content still struggles regardless. Content matters. It is the last thing in this order to change and the first thing most senders change. When a sender tells me they have rewritten their emails three times with no improvement, that is usually diagnostic information about the reputation gate rather than about their copy. I wrote out how the Gmail spam filter actually weighs these inputs for anyone who wants the receiving side of this in more depth.
Four, and none of them produces a score. Postmaster Tools for reputation and complaints, a DNS and authentication checker for the record layer, raw message headers for what the receiving server actually decided, and a placement test when I need to separate content from infrastructure.
I distrust deliverability scores as a category. A score compresses six independent causes into one number, and the number moves for reasons you cannot attribute. Every tool in the list above answers a specific question instead, which is what makes the answer actionable.
| Tool | The question it answers | What it cannot tell you |
|---|---|---|
| Google Postmaster Tools | What Gmail thinks of your domain and IP, and your complaint rate | Anything about Outlook, Yahoo or Microsoft 365 recipients |
| DNS and authentication checker | Whether your records exist, resolve and align | Whether mail using them reaches the inbox |
| Raw message headers | What the receiving server decided and why, per message | Anything about mail you did not receive a copy of |
| Placement test | Whether the problem follows your content or your infrastructure | Which specific recipients were affected |
Headers deserve more attention than they get. The Authentication-Results header records what the receiving server concluded about SPF, DKIM and DMARC for that specific message, which is a stronger statement than a checker's view of your DNS. A record can be published correctly and still fail on a given message because of how the sending platform assembled it.
The fix follows the gate that fired, and only that gate. A record error is a DNS edit. A reputation problem is warmup and time, with no message change that shortcuts it. A list problem is a segmentation and acquisition question. Applying the wrong remedy to the right diagnosis changes nothing.
For the technical gate, the work is small and the verification matters more than the edit. After a record change I confirm the record resolves publicly, then confirm a real message signed under it passes at the receiver, because those are two different claims. An SPF record can be present, syntactically valid and still actively harmful, which is the case where a checker showing green is misleading rather than reassuring.
For the reputation gate, the remedy is a managed ramp rather than a schedule. My warmup process runs on a contact network spanning MS365, Google Workspace, Gmail, Outlook and Yahoo, and the ramp is gated on engagement holding at each volume step rather than on days elapsed. That distinction is the whole argument in what most warmup guides get wrong about fixed schedules, and the same logic applied to IPs sets what should actually govern an IP ramp.
For the list gate, the sequence is to stop the bleeding before rebuilding. That means suppressing the segments producing complaints, mailing the engaged core at normal volume so positive signal keeps flowing, and reintroducing the rest only once reputation has recovered enough to survive them. Cutting the whole list at once removes the complaints and the positive engagement in the same stroke, which is why reputation often fails to recover after an aggressive prune.
Weeks rather than days, and the range depends on how far reputation fell. From medium or low I aim at roughly three to six weeks. From a sustained low I plan on at least two months. High reputation with mail landing in Promotions sits at the shorter end. These are aims rather than commitments.
Every one of those ranges runs faster or slower on a given sender, and the Promotions case sometimes needs light content adjustment alongside the ramp. I give them as ranges because a date would be a promise about a receiver's judgment rather than about my work.
The reason nobody can compress this is the same reason the band moves slowly in the first place. Reputation is a rolling assessment built from your recent sending, so changing it requires accumulating a new history at a volume the receiver will notice. There is no request you can file and no setting you can change that substitutes for that accumulation.
What does change the timeline is whether the underlying cause was actually fixed before the ramp started. A ramp run on top of an unfixed list problem re-creates the complaint pattern that caused the original fall, and the sender spends two months arriving back where they began. That is the most common reason a recovery stalls, and it traces back to skipping the diagnosis rather than to the warmup itself.
Here is the piece of the reputation gate that does the most work and appears in almost no published guidance. Which provider your mail lands in spam at is not a snapshot question. It is a history question, and reading it as a snapshot produces the wrong diagnosis with total confidence.
Consider two senders with identical symptoms. Both report that mail reaches the inbox at Outlook and goes to spam at Gmail. The obvious reading is that Gmail is harsher, and the obvious action is to work on Gmail. That reading is right for one of them and wrong for the other, and what separates them is whether the list ever had a chance to interact at each provider.
If a provider never accepted your early campaigns, your recipients there never got to engage with you, so there is no positive history and the mail stays filtered indefinitely. Placement at that provider tells you about your first contact with it, not about your current reputation. A provider that accepted your early campaigns and let recipients engage is the one whose current placement carries real information.
So when mail reaches the inbox at a provider where your list has no history, and goes to spam at a provider where it does, the spam placement is pointing at domain reputation or content rather than at that provider being unfair. Reverse the histories and the same symptom means something different. I source this from old campaign metrics, Postmaster, a placement test, and the last thirty to ninety campaign results, and it is often the read that turns a stalled six-month problem into a two-week one.
This is also why I ask about the first campaigns a domain ever sent, which sounds like an odd question when someone is describing a problem that started last month. The early history sets the ceiling on what the current numbers can mean.
No. Delivery rate is the share of messages a receiving server accepted, and your sending platform reports it. Deliverability is where the message went after acceptance, which no platform reports because the decision happens inside the receiving system. A domain can show a delivery rate that looks perfect while most of its mail sits in spam.
Rarely. Content is the fifth of the six things I check, and it is usually the amplifier of a reputation problem rather than its source. If your domain reputation has fallen, rewriting subject lines changes almost nothing, because the filter is reading your sending history before it reads your words.
Almost always volume rather than a setup fault. Google only populates Postmaster data for domains above a minimum daily volume to Gmail, and it does not publish the number. Of 160 domains connected to Postmaster in my monitoring account, 104 produce no reporting data at all. An empty dashboard usually means you are below the reporting floor.
Only above a volume where you can keep it warm. A dedicated IP with inconsistent, low or erratic sending behind it is worse than a well-run shared pool, because a shared pool borrows the reputation of everyone in it and a quiet dedicated IP has no reputation to lend you. Volume and consistency decide this, as I set out in what a shared pool actually does to your reputation.
Each gate in this order has its own page. The symptom-first version of this method, written for someone who has just discovered their mail is being filtered, is the six checks I run when emails are going to spam. The remedial version, for someone who already knows the cause and wants the sequence of fixes, is how to stop emails going to spam. For the authentication layer specifically, start with what DMARC is and what DKIM is, then read the causes of Gmail spam placement in the order they actually occur.
If you want the order run against your own domain rather than read about, the diagnostic is the same six gates applied to your records, your reputation and your sending history, with the gate that fires named at the end of it.