Deliverability Incident Runbook — From Alert to Recovery in AcelleMail

The 5-minute triage flow#

When something looks broken (campaign stuck / bounce rate spike / customer complaint), don't jump to SSH. Walk this exact flow in the AcelleMail dashboard first. Most incidents resolve here.

Step 1: Read the tracking log#

Campaign → Tracking log tab:

What the rows tell you:

• All recent timestamps + "Sent" status — AcelleMail handed messages to the SMTP successfully. Issue is recipient-side.
• Recent timestamps + "Failed" + retry counter — receiving servers rejecting. Open bounce log next.
• No new rows in last 30 min — queue worker is dead OR campaign is paused. Check campaign state + worker (see Advanced).

Step 2: Read the bounce log#

Where the bounce signals live#

Open the campaign → Bounce log tab. Every failed delivery is row-listed with the recipient, bounce type (Hard/Soft chip), and the raw reason from the receiving server:

For machine-codes (5.x.x / 4.x.x DSN classifications) the per-row reason text is the receiving server's verbatim response. See Decoding bounce messages for the full code reference.

Pattern-match the bounces:

Step 3: Check the feedback log (complaints)#

Same campaign → Feedback log tab:

Complaint volume tells you:

• Spike + concentrated on one segment — that segment's consent was unclear or content was off-target. Pause sending to it; audit.
• Spread across the list — content / subject mismatch. Audit the campaign before next send.
• Zero complaints despite bounce spike — pure deliverability issue (auth/IP), not content/list.

Step 4: Check sending server health#

Open Settings → Sending servers → click your active server:

Verify all three: SPF green, DKIM green, DMARC green. Any red = receiving servers immediately throttling. Click Verify domain to walk through DNS records.

Step 5: Run the live diagnostic#

Same sending server → toolbar Send test email:

Send to your own personal Gmail, Outlook, Yahoo. Open each:

• All Inbox → reputation is OK; original issue is content-side or list-side
• Some spam folder → ISP-specific reputation hit (Gmail or Outlook only). Check that ISP's postmaster tool.
• None arrive → IP blocklisted. Use mxtoolbox.com to identify which blocklist; follow delisting process.

Triage decision tree#

Recovery checklist#

After identifying root cause:

1. Pause active sending if customer-visible impact (campaign log not draining, complaints spike)
2. Fix the source — DNS record, list cleanup, content edit
3. Send a small re-engagement to your most-engaged 5% to validate (NOT full list)
4. Monitor for 24h — bounce + complaint rates back to baseline?
5. Resume normal sending if all green
6. Post-mortem within 48h (template below)

Post-mortem template#

For each incident, capture in a shared doc:

INCIDENT: [Date] — [Short description]
DETECTED VIA: [Customer complaint / auto-alert / routine check]
DETECTED AT: [Timestamp]
SEVERITY: [Customer-facing impact: 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 slow / response slow / impact wider]

PREVENTION: [What we change to make this not happen again — explicit action items with owners + dates]

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

ssh acelle@acellemail.com "
  ps aux | grep -E 'queue:work' | grep -v grep | wc -l
  # Expect 1+ per --queue= pool defined in supervisor config

  php artisan queue:size
  # Should drop toward zero; if growing, workers are stuck

  php artisan queue:failed | wc -l
  # If >0, jobs gave up; investigate:
  php artisan queue:failed
"

ssh acelle@acellemail.com "sudo supervisorctl restart all"

ssh acelle@acellemail.com "nc -zv email-smtp.us-east-1.amazonaws.com 587"
# Expected: succeeded. Failure = firewall outbound block.

ssh acelle@acellemail.com "
  openssl s_client -connect smtp.sendgrid.net:587 -starttls smtp -crlf < /dev/null 2>/dev/null \
    | grep -E '(subject|issuer|verify)'
"

ssh acelle@acellemail.com "
  dig TXT yourdomain.com +short | grep -i spf
  dig TXT default._domainkey.yourdomain.com +short
  dig TXT _dmarc.yourdomain.com +short
"

Day 0:  PAUSE all bulk sending. Re-verify domain. Confirm SPF/DKIM/DMARC green.
        Begin sending ONLY to engaged-last-7d segment (highest open rate).
Day 7:  If engagement-segment sends stayed clean, expand to engaged-last-30d.
Day 14: Expand to engaged-last-90d. Daily check of SNDS / Gmail Postmaster.
Day 30: Resume to full segment if reputation back to baseline.

Related articles#

• Sender reputation monitoring
• Decoding bounce messages
• Why is my campaign stuck in Sending status
• Email delivery issues — UI diagnostic checklist
• Setting up queue workers and cron jobs