Deliverability incident response: contain, diagnose and restart deliberately

Define the decision

A sudden failure can affect authentication, transport, recipient handling or message construction. The first goal is to stop avoidable repeated contact while retaining enough evidence to distinguish these layers.

Work through the procedure

1. Pause the affected stream and record the incident start time.
2. Capture representative errors, received messages and recent configuration changes.
3. Assign an owner to the suspected layer and test one hypothesis at a time.
4. Define correction, rollback and restart gates before resuming.
5. Review whether other campaigns share the same cause.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Incident: new DKIM selector activated before DNS publication
Containment: pause affected sending service
Correction: publish and verify the required key
Restart gate: fresh messages pass using the new selector
Follow-up: change checklist updated to publish before activation

Read the result

The incident record should explain what failed and why the next attempt is expected to differ. A successful unrelated mailbox test cannot close a domain-wide signing incident.

Check before moving on

1. Keep uncertain attempts out of blind retries.
2. Verify suppression and reply handling before restart.

Limits and next action

Close the incident only after the affected path is retested. Longer-term reputation effects may remain uncertain and should be monitored without promising a recovery date.

Source: Zintara deliverability operations context