Your incident is over when somebody in the channel says it is over, unless you wrote down what “over” means. Otherwise the next sale repeats the same send, to the same cold slice, on the same domain, and the Slack thread starts from zero.
The first 24 hours is the response. This page is the document you write after that, while the logs still exist.
Last verified: 26 September 2026. The template does not add recovery-time claims. Providers still do not publish one.
Copy this deliverability postmortem structure
Title. One sentence: what stopped, for whom, on which date. “Gmail spam rate crossed 0.30% on the Saturday sale, 12 September 2026” is a title. “Email issues” is not.
Timeline. Hour the first signal moved. Hour someone noticed. Hour the send was stopped. Hour the change shipped. Hour you retested. Pull times from Postmaster, Sender Hub, the bounce log, or seed results. The incident agent keeps an audit history of signals and remediation if it was on. That history is an input. It is not the postmortem.
Scope. Which From domain, which IP or ESP, which stream (campaign, flow, receipt), which providers. A Gmail-only event is not an Outlook event. Use the provider split so the scope line names a provider.
Impact. Orders or tickets you can count. If you estimate revenue, use your own inputs the way deliverability ROI describes. Do not convert a bounce rate into lost revenue. Do not cite a sitewide spam percentage as your incident.
Cause. The mechanism you can point at: a list import, a broken DKIM selector, a volume step, a complaint spike on a win-back, a 5xx policy. Quote the SMTP text or the provider chart. One cause.
Ruled out. Authentication passed or failed, and you looked. A domain scan of SPF, DKIM, DMARC, and blocklists gives you one dated snapshot to paste here. No new list, or there was a new list. Content was or was not the only thing that changed. This section is how the next person skips the myth you already killed. Content versus reputation is the background, not a required paragraph.
Change. What you stopped, suppressed, or fixed in DNS. Link the runbook you actually followed.
Verification. The signal that has to hold before volume comes back. “Gmail spam rate under 0.10%” is a verification line; “wait 30 days” is not. Keep the caveat in the document: 0.10% is Google’s guideline, not a requirement, and meeting it says your complaints are down, not that placement has returned. Other examples that are real: Yahoo complaint rate under 0.30%, no new 5.7.515, seed placement at Gmail and Yahoo back to the pre-incident pattern. Recovery time explains why “wait 30 days” is not a verification.
Monitor. Who looks at which tool on the next three sends. Monitoring across providers is the assignment list.
What does not belong
A blame paragraph. A new sending domain created during the incident and described as the fix, unless you planned that cutover and authenticated it. A promise that placement is “back to 100%.” Seed tests are a sample at Gmail, Yahoo, AOL, and Outlook. They are not the whole list.
InboxEagle
Fill in the ruled-out section with evidence
Scan your domain for SPF, DKIM, DMARC, and blocklist status, and paste the dated result into the postmortem. Then the next person knows authentication was checked, not assumed.
Sources
- Email sender guidelines FAQ, Google. The 0.30% mitigation window, which is a verification condition, not a narrative.
- Sender best practices, Yahoo. The complaint-rate line to name if Yahoo was in scope.
- Fix NDR 550 5.7.515, Microsoft. The rejection to quote if Outlook was in scope.