Deliverability triage: the incident runbook

When mail starts landing in spam, the instinct is to rewrite subject lines. Resist it. Deliverability incidents get solved by working evidence in order, and content sits last on that list because it is the least often guilty and the easiest to obsess over. This is the runbook I actually use. Define the symptom precisely, cross it with a timeline of what changed, then check the technical layers in evidence order. Most incidents fall over at the first or second step.

Step zero: define the symptom

"Emails are going to spam" is not a symptom, it is a mood. Before touching anything, pin down four facts.

Which audience? The whole list, one segment, or one important recipient? A single corporate recipient foldering you is their filter's opinion, and you solve it with their IT department, not with your DNS.

Which mailbox providers? Split your engagement data by recipient domain. A collapse at gmail.com addresses while outlook.com holds steady is a Gmail-reputation fact and rules out half the suspect list immediately. A collapse everywhere at once points at authentication or records, because the providers do not share filter verdicts, but they all read the same DNS.

Since when? Get an actual date, not "recently". Campaign statistics give you one.

Sudden or gradual? Sudden means an event: something changed on a day, and your job is to find that day's change. Gradual means erosion: list aging, engagement decline, reputation sliding. The two have almost non-overlapping cause lists, which is why this one answer does so much work.

Build the timeline

Now cross the start date against everything that changed around it. Website or DNS work, a new tool connected, an ESP migration, a big list import, a re-engagement blast to old addresses, a volume spike, a template overhaul, a DMARC policy tightened. Ask the people who would know; the person who edited DNS during a site migration never suspects they touched email.

In the triage conversations I have had, this crossing solves the case before any diagnostic tool gets opened, more often than you would believe. The six causes that account for nearly every sudden case, ordered by how often they turn out guilty, are a lesson-sized topic of their own.

Then work the layers, most measurable first

The ordering principle: records are binary, blocklists are lookups, reputation is graded, content is interpretation. Start where the answers are facts.

First, the records, from outside. Read your domain's SPF, DKIM and DMARC state as receivers see it, from public DNS. One SPF record or two? Does it parse, and is it inside the 10-lookup limit? Are the DKIM keys still published at the selectors your tools use? Is DMARC present, and did anyone tighten p= recently while a legitimate tool was still failing alignment? The free health check runs this whole layer in about a minute. In the domains we monitor, this layer is guilty far more often than its glamour suggests: the second SPF record pasted in by a new tool's setup wizard is practically a genre.

Second, the blocklists. Check the domain against the domain lists and your sending IPs against the IP lists. The health check queries combined IP and domain blocklist zones as part of its pass, which answers "listed or not" quickly; for the diagnosis you want the operator's own lookup, Spamhaus's above all, because it names the exact list you are on. That name matters: SBL means observed spam behavior, XBL means a compromised machine is involved somewhere, PBL just means the IP is in a range that should not be sending mail directly, DBL means the domain itself has the reputation problem.

Third, the reputation signals. Open Google Postmaster Tools and look at the trend, not the current value: when did domain reputation dip, and did the spam-rate chart cross 0.1% or the 0.3% ceiling around then? If you run your own IPs, pull SNDS. Check your DMARC aggregate reports for an authentication failure ramp starting near the incident date.

Fourth, and only now, content and campaign specifics. The screening question: did one campaign folder while its neighbors delivered, or is everything foldering? If everything, the cause is upstream and you already checked the right layers. If one campaign, look at what made it unusual. The two easy tells are the all-image message and the link-shortener carpet.

Delisting, escalation, and their honest odds

If you found a blocklist listing, fix the cause first, then request delisting. Spamhaus removals are free and self-service through their lookup pages; anyone charging you money to get delisted from a major list is selling paperwork you could file yourself. File before fixing the cause and you will be relisted within days, with a worse look.

Mailbox providers have escalation paths too, and this is where I owe you honesty. Google operates a sender contact form for bulk senders with Gmail delivery problems, reachable through the Postmaster Tools help pages. Microsoft runs a sender-support process for Outlook.com delivery issues and grants what it calls mitigations, which are usually conditional and temporary. Both are worth filing when a real technical problem has been found and fixed and a lingering block remains. Neither is a lever. The responses tend to arrive form-shaped, and no provider will overrule its own reputation system because you asked nicely. My experience: escalation helps at the margins after the actual fix, and does approximately nothing before it.

When the answer is to stop sending

Some incidents have no technical fix, because the cause is the audience. A gradual slide with rising complaint rates and sinking engagement means the filters have learned that your recipients do not want the mail, and no DNS record un-teaches that. The repair is behavioral. Stop mailing the disengaged segment. Shrink to the people who provably read you (given how Apple inflates opens, weight clicks and recent activity), hold volume steady at that reduced level, and let the metrics recover before expanding again. Then write the cut down as a standing sunset policy, a rule that retires any address after a defined stretch without engagement, so next time it happens on schedule instead of after the damage.

This takes weeks, not days, and nobody wants to hear it, which is why it gets prescribed last and needed often. Reputation heals at the speed filters re-learn, and you cannot rush a filter. The list hygiene lesson covers how to make the cut without losing revenue you actually had, as opposed to revenue the list size only implied.

One closing observation from the monitoring side: the incidents that reach triage were almost never sudden at the root. A record broke, or a list soured, weeks before anyone noticed the symptom. The timeline step exists because the change and the alarm are rarely the same day, and the whole argument for continuous monitoring is collapsing that gap to hours.

Keep the glossary, the course's reference shelf, a click away for any term this runbook leans on. Next comes the repair itself, in an order that won't backfire: repairing a decayed setup.

Terms from this lesson

• triage - working an incident by checking causes in order of measurability and likelihood instead of guessing at the most visible one.
• delisting request - asking a blocklist operator to remove your IP or domain after the cause is fixed. Removals from the major lists are free.
• mitigation - a mailbox provider manually easing a block or filtering decision for a sender, usually temporary and conditional on behavior.
• sunset policy - a standing rule that stops mail to addresses after a defined period without engagement, before they damage reputation.

Check yourself

1. The founder says "our emails are going to spam." What is the first professional move?

Rewrite the subject lines and resendRequest delisting from every major blocklistPin down which audience, which providers, since exactly when, and whether it was sudden or gradualSwitch to a new ESP

2. Why do records and blocklists come before content in the evidence order?

Content never affects placementThey are binary, checkable facts, and they are guilty far more oftenProviders publish records but hide content rules

3. A service offers to remove you from Spamhaus for a fee. What should you know?

Spamhaus delisting is free and self-service once the cause is fixedPaid removal is faster and worth it during an incidentOnly ESPs can request delisting

4. Placement at Gmail has declined for months, complaints are creeping up, and the records all check out. What is the fix?

File Google's sender contact form and waitTighten DMARC to p=rejectStop mailing the disengaged segment, hold reduced volume, and let reputation recover over weeks