Why a decision tree beats a checklist
Most advice about email deliverability problems arrives as a flat list of twenty things to check. The list is not wrong; it is unordered. The cause of mail hitting spam on a two-week-old domain with clean DNS is different from the cause on a five-year-old domain that just imported a purchased list, and treating both with the same checklist wastes the one resource a deliverability incident consumes fastest — sending days.
Diagnosis is sequential. The symptom narrows the field first: mail in the spam folder is a filtering decision, mail that bounces is a rejection with a stated reason, mail that simply vanishes is usually one of the two wearing a disguise. The provider narrows it further — Gmail publishes sender guidelines and enforces them mechanically, so a Gmail-specific path exists in the tree. Then authentication, because it is the layer that is either provably fine or provably broken. Only when those pass does the tree move to the murkier territory of volume spikes, domain age, and IP reputation.
The five entry symptoms
- Spam folder. The deep path: provider, then SPF → DKIM → DMARC, then volume history, domain age, and IP type. Verdicts range from a missing authentication layer to shared-pool reputation and engagement problems.
- Not delivered at all. Silent loss splits on an underrated cause: your own DMARC policy at enforcement quietly discarding your own misaligned mail. The other branch covers unauthenticated mail that large providers drop without a bounce.
- Wrong tab. Promotions is delivery, not filtering — the shortest path in the tree, and its verdict says honestly that fighting tab classification is often not worth the effort.
- Bounces. The bounce wording routes you: user-unknown points at list quality, policy wording at authentication or blocklists, deferrals at throttling and greylisting.
- Blacklisted. IP listings, domain listings, and the surprisingly common case where the claim itself needs verifying before anything else.
What the verdicts link to
Every cause carries its verification tool, because a diagnosis you cannot test is an opinion. Authentication causes link to the SPF, DKIM and DMARC checkers and their generators; reputation causes to the blacklist and reverse DNS checkers; message-level questions to the header analyzer, which reads the Authentication-Results verdicts receivers actually recorded. When several layers need checking at once, the setup score grades all of them in one pass.
The Gmail path
Gmail gets its own branch because Google is explicit in a way other providers are not: the current Google sender guidelines expect authentication from every sender and require SPF, DKIM, and DMARC from bulk senders. When your spam problem is at Gmail and any of those layers is missing, the diagnosis is short and the tree says so without hedging. We keep the references high-level on purpose — thresholds and details shift, and a wizard that hardcodes last year's numbers is worse than one that points you at the requirement and the checker.
Honest limits
A decision tree diagnoses from your answers, and answers can be wrong — "yes, SPF is configured" sometimes means "someone set it up in 2019." When a verdict hinges on an authentication answer, verify it with the linked checker rather than trusting memory. The tree also cannot see provider-internal signals: complaint rates, engagement history, the reputation your IP earned last month. For those, the verdicts point at provider postmaster tools and at steady sending behavior — the only lever that rebuilds reputation once it is lost.
Start with the symptom above, and if the wizard ends somewhere unexpected, run the full DNS audit — it checks every layer the tree asks about, in one pass, against live DNS.
Frequently asked questions
How does the troubleshooter diagnose email deliverability issues?
It walks a decision tree built from the way deliverability problems actually branch: the symptom first (spam folder, silent loss, tab placement, bounces, blacklisting), then the mailbox provider, then authentication — SPF, DKIM, DMARC — then recent volume changes, domain age, and whether you send from a dedicated or shared IP. Each path ends in a ranked list of probable causes with an explanation, a concrete action, and the tool that verifies the fix.
Where do my answers go?
Nowhere. The wizard is a static decision tree that runs entirely in your browser — no server calls, no storage, no analytics on what you answer. State lives in memory only and disappears when you restart the wizard or leave the page.
Why does it keep pointing me at SPF, DKIM, and DMARC?
Because authentication failures explain more deliverability problems than everything else combined, and they are the cheapest to rule out — each is one DNS lookup away from a definitive answer. The tree deliberately refuses to discuss reputation or content until the authentication questions pass: debugging engagement on an unauthenticated domain is polishing the wrong layer.
What does the priority on each cause mean?
High means the cause is both likely given your answers and serious enough to explain the symptom on its own — fix these first. Medium causes are plausible contributors worth checking once the high ones are ruled out. Low causes are less likely or less damaging, listed because they occasionally turn out to be the answer and cost little to verify.
Can the wizard tell me definitively why my email goes to spam?
No, and it does not pretend to. From outside a mailbox provider, nobody can see the exact filtering decision — providers keep those signals private on purpose. What a structured diagnosis can do is rank the probable causes for your specific situation and hand you the checks that confirm or eliminate each one. In practice that resolves most cases; the remainder need provider postmaster tools and patience.