PRACTICAL OUTREACH
Email Deliverability Incident Runbook
A deliverability problem rarely arrives with a complete explanation. A campaign may show fewer replies, more deferrals, rising bounces or a sudden change in inbox placement, while the sending platform still reports that messages were accepted.
An incident runbook gives your team a controlled way to investigate. It helps you separate a mailbox, domain, content, recipient or provider problem before changing several variables at once.
Start by defining the incident
Do not begin by rewriting the email or rotating every sending domain. First record what changed, when the symptoms began and which recipients are affected.
Capture the following information for the affected campaign:
- Sending domain, mailbox, provider and sending tool.
- Approximate start time, campaign identifier and recent configuration changes.
- Recipient domains affected, such as Gmail, Outlook or a specific business domain.
- Delivery status, SMTP response codes, bounce categories and deferral rates.
- Whether replies, positive responses and unsubscribe requests are still being processed.
Compare the affected traffic with a known-good period or a separate sending identity. A problem limited to one domain points toward domain configuration or reputation. A problem across several domains using the same provider may indicate a shared platform, content or campaign issue.
Check the message and authentication path
Next, inspect an actual message from the affected stream. Do not rely only on a sending platform's green status indicator. Obtain the full headers from a delivered test message and review the receiving server's authentication results.
Check whether SPF, DKIM and DMARC are passing and whether the visible From domain is aligned with the authenticated domain. Google states that bulk senders to personal Gmail accounts must authenticate with SPF, DKIM and DMARC, and that direct messages must meet DMARC alignment requirements. Its sender guidance also recommends valid forward and reverse DNS records and TLS.
Review the DNS records for the exact domain used by the message, not just the organisation's main website domain. Common investigation errors include:
- Checking SPF for the corporate domain when the campaign uses a separate sending domain.
- Testing a DKIM selector that is not used by the current provider.
- Adding a second SPF record instead of consolidating authorised senders.
- Assuming that an SPF pass automatically means DMARC alignment passes.
- Changing DNS without recording the previous value or allowing time for propagation.
If forwarding or an intermediary service is involved, authentication can become harder to interpret. ARC is designed to carry authentication assessments through participating intermediaries, but it does not establish that a message is trustworthy or safe. Treat ARC as evidence to interpret alongside the original authentication results, not as a deliverability guarantee.
Separate provider symptoms from sender symptoms
A temporary SMTP deferral is not the same as a permanent rejection. Record the full response code and text before deciding what to do. Repeated 4xx responses may indicate rate limiting, recipient-server pressure or a reputation concern. A 5xx response generally requires a configuration, policy, recipient or message decision rather than repeated retries.
Look for patterns by recipient provider. If Gmail is affected but Microsoft-hosted recipients are not, review Gmail-specific authentication, spam-rate and reputation data. If several providers show the same increase in bounces, investigate the list, mailbox health, DNS or sending application first.
For Gmail traffic, Postmaster Tools can provide information about authentication, domain or IP reputation, spam rates and delivery problems. Google also provides a compliance dashboard for checking sender requirements. These tools are useful signals, but they do not replace message-level testing or a review of SMTP logs.
Do not treat open-rate changes as proof of a delivery failure. Open tracking can be incomplete or distorted by privacy features, proxy scanning and changes in tracking configuration. Prioritise hard evidence such as accepted, deferred, rejected, bounced and complained messages.
Contain the problem without creating another one
Once you have enough evidence to identify a likely failure area, contain it conservatively. Pause the affected campaign if complaints, invalid-recipient bounces or repeated provider rejections are increasing. Avoid moving the same audience immediately to a fresh domain, because that can spread the same targeting or content problem to another identity.
A practical containment plan may include:
- Pause new outreach to the affected recipient segment.
- Continue processing replies, opt-outs and complaints from messages already sent.
- Remove confirmed invalid addresses and suppress people who have requested no further contact.
- Preserve logs, headers, DNS records and provider notifications.
- Send a small controlled test only after the suspected issue has been corrected.
If the issue is authentication, correct the relevant DNS or signing configuration before resuming. If it is a list-quality or complaint problem, fix the audience and suppression process. If it is a provider response or rate limit, follow the provider's documented guidance and reduce unnecessary retries.
Quick checklist for the next review
- Have you written down the first known time and scope of the incident?
- Did you compare recipient providers instead of treating all failures as one problem?
- Did you inspect full headers from a real delivered message?
- Do SPF, DKIM and DMARC pass for the actual sending domain?
- Is the From domain aligned with SPF or DKIM where required?
- Did you record complete SMTP response codes and text?
- Are bounces, complaints and unsubscribes being suppressed correctly?
- Did you pause risky traffic without abandoning reply handling?
- Is there a named owner for the investigation and the restart decision?
Common mistakes include changing copy before checking authentication, rotating domains before identifying the cause, retrying permanent failures, and relying on one dashboard as if it represented every recipient provider.
A repeatable runbook is especially useful when several people, tools or client accounts share responsibility for sending. If your team needs help monitoring domains, reviewing authentication, handling provider signals and coordinating safe campaign changes, a managed cold email service can provide operational support without treating one metric as the whole diagnosis. For a broader pre-launch review, compare the steps with the cold email setup checklist.