Deliverability Incident Runbook — From Alert to Recovery in AcelleMail

The 5-minute triage flow#

When something looks broken — a campaign stuck on Sending, a bounce-rate spike, a customer complaint — work this exact flow in the dashboard first, top to bottom. Most incidents resolve before you reach the last step. Each check tells you where the problem is so you don't guess.

Open the affected campaign. On a regular campaign the report tabs sit under the Sending logs dropdown: Delivery log, Bounce log, Feedback log, Open log, Click log, Unsubscribe log. (On an A/B-test campaign the same dropdown is labelled Logs, and the per-message tabs live under it the same way.) The first three are your triage tools.

Step 1 — Read the Delivery log#

Open the campaign → Sending logs → Delivery log:

This is the per-message record of what AcelleMail handed to your sending server. Each row shows the recipient and a Status badge — Sent (green) when the message was accepted, or Error (red) when the send failed (hover the badge for the error text). Read the pattern:

• Recent rows, all marked Sent — AcelleMail delivered the messages to the SMTP server fine. The problem is recipient-side or reputation-side, not in your queue. Go to the Bounce log.
• Recent rows marked Error — sends are failing at the server. Go straight to the Bounce log to see why.
• No new rows in the last 30 minutes while the campaign still shows Sending — nothing is draining the queue. Either the campaign is paused, or the background worker that sends mail has stopped. See Why is my campaign stuck in Sending status.

Step 2 — Read the Bounce log#

Open the campaign → Sending logs → Bounce log. Every bounce is listed with the recipient, a Bounce type badge, and the raw Reason the receiving server sent back (click a reason to see the full text):

Pattern-match what dominates the list:

The verbatim reason text in each row is the receiving server's own response. For the full code reference, see Decoding bounce messages.

Step 3 — Read the Feedback log (complaints)#

Same campaign → Sending logs → Feedback log. Each row shows the recipient, a complaint Type badge, and the raw reason:

Complaint volume tells you whether this is a content/list problem or a pure deliverability problem:

• Spike concentrated on one segment — that segment's consent was shaky, or the content missed. Pause sending to it and audit before resuming.
• Spread evenly across the whole list — content or subject-line mismatch. Audit the campaign before the next send.
• Zero complaints despite a bounce spike — this is a deliverability issue (auth or IP), not a content or list issue. That narrows your next steps a lot.

Step 4 — Check your sending-domain authentication#

If the Bounce log is full of 5.7.x "not authorized" lines, your domain authentication is the prime suspect. Open Sending → Sending domains in the left sidebar. Each domain shows a Verified / Unverified status, with SPF, DKIM, and DMARC record chips:

Click into the domain to see every DNS record and its individual check state:

If any record shows Unverified, click Verify DNS records to re-check them all at once. AcelleMail tells you which records are still pending — DNS changes can take up to 48 hours to propagate worldwide, so a freshly edited record may need time before it turns green.

Step 5 — Run a live test send#

To confirm whether the problem is reputation or something else, send yourself a real message. Open Sending → Sending servers, click into your active server, and use Send test email in the toolbar:

Send one to your own Gmail address, one to Outlook, one to Yahoo, then open each one:

• All land in the inbox — your reputation is fine. The original issue is content-side or list-side, not your sending setup.
• Some land in spam — an ISP-specific reputation hit (often just Gmail or just Outlook). Check that provider's postmaster tooling.
• None arrive at all — your IP is likely blocklisted. Look it up on a public blocklist checker and follow that list's delisting process.

Triage decision tree#

Once the five checks above point you at a cause, this maps the cause to the next action:

Recovery checklist#

After you've identified the root cause, work in this order:

1. Pause active sending if there's customer-visible impact (queue not draining, complaints climbing).
2. Fix the source — the DNS record, the list, or the content.
3. Send a small test to your most-engaged 5% to validate the fix — never the full list.
4. Monitor for 24 hours — are bounce and complaint rates back to baseline?
5. Resume normal sending once everything is green.
6. Write the post-mortem within 48 hours (template below).

When the problem is below the dashboard#

If you've worked every step above and the Delivery log shows no new rows while the campaign sits on Sending, the issue is the background process that actually sends mail — the queue worker — not anything you can fix from a campaign screen. That's a separate, infrastructure-level fix (restarting the worker, checking the queue) and it's covered end to end in Setting Up Queue Workers and Cron Jobs. Hand that one to whoever administers your install.

Reputation recovery cycle#

If Step 5 confirms a reputation hit (messages going to spam or not arriving), don't blast the full list to "push through" it — that makes it worse. Ramp back in instead, sending only to your most-engaged subscribers first so receiving servers see strong engagement again:

• Day 0 — Pause all bulk sending. Re-verify your domain at Sending → Sending domains and confirm SPF, DKIM, and DMARC are all green. Begin sending only to subscribers who opened in the last 7 days (your highest-engagement group).
• Day 7 — If those sends stayed clean, widen to the last-30-day openers.
• Day 14 — Widen to the last-90-day openers. Keep checking Google Postmaster Tools and Microsoft SNDS daily.
• Day 30 — Resume to your full audience once reputation is back to baseline.

A mild dip recovers in one to two weeks. A severe hit (sustained complaint rate above 1%) can take four to six weeks, or a fresh IP and a full warmup — see IP warmup schedule for new sending servers.

Post-mortem template#

Capture every incident in a shared doc so the team learns from it. Fill in:

INCIDENT: [Date] — [Short description]
DETECTED VIA: [Customer complaint / routine check / alert]
DETECTED AT: [Timestamp]
SEVERITY: [Stalled campaigns / damaged reputation / complaint spike]

ROOT CAUSE: [One sentence — what actually broke]

TIMELINE:
  T+0:   [What happened]
  T+5m:  [What we did]
  T+30m: [What we did]
  T+...: [Resolution]

CONTRIBUTING FACTORS: [What made detection or response slow / impact wider]

PREVENTION: [What we change so it doesn't recur — action items with owners + dates]

LEARNINGS: [Even with no action — what we now know that we didn't before]

Related articles#

• Sender reputation monitoring
• Decoding bounce messages
• Why is my campaign stuck in Sending status
• Email delivery issues — UI diagnostic checklist