Hard Bounce vs Soft Bounce — Reading the AcelleMail Bounce Log

The DSN (Delivery Status Notification) standard is RFC 3463 + 5248. Three-part code:

X.Y.Z
│  │  │
│  │  └── Detail (subject status — e.g. 1 = mailbox doesn't exist)
│  └───── Subject (status class — e.g. 7 = security issue)
└───────── Major (5 = permanent, 4 = transient, 2 = success)

Common subject codes (Y position):

Detail codes (Z position) get specific. Examples:

• 5.1.1 = "Bad destination mailbox" (most common hard)
• 5.7.1 = "Delivery not authorized" (auth issue)
• 5.7.7 = "Message integrity failure" (DKIM check failed)

Most receivers also include human-readable text after the code. Read both — the code categorizes, the text specifies.

Per-domain bounce mining via SQL (replace bounce_logs with your DB_TABLES_PREFIX):

SELECT
  SUBSTRING_INDEX(SUBSTRING_INDEX(email, '@', -1), '.', -2) AS recipient_domain,
  SUM(CASE WHEN bounce_type = 'hard' THEN 1 ELSE 0 END) AS hard_total,
  SUM(CASE WHEN bounce_type = 'soft' THEN 1 ELSE 0 END) AS soft_total,
  COUNT(DISTINCT dsn_code) AS distinct_codes,
  GROUP_CONCAT(DISTINCT LEFT(reason, 60) ORDER BY created_at DESC) AS sample_reasons
FROM bounce_logs
WHERE created_at >= NOW() - INTERVAL 7 DAY
GROUP BY recipient_domain
HAVING hard_total + soft_total > 50
ORDER BY hard_total DESC
LIMIT 20;

Reveals: which receivers are giving you trouble + what they're saying. Often surfaces patterns like "all yahoo.com bouncing 4.7.0" → greylisting from Yahoo → patience required.

Auto-reactivation pattern for soft → hard conversions that resolved:

# Daily cron: identify subscribers in `bounced` state that received successful
# sends from OTHER systems (e.g. via CRM bridge) — auto-reactivate.

# Pseudo-code; adapt to your tooling
for subscriber in subscribers.bounced:
  if recent_crm_activity(subscriber, days=30) and reason_was_soft_to_hard(subscriber):
    flip status to subscribed
    send_low_volume_test_campaign(subscriber)
    monitor first 2 sends

Recovers ~5-10% of bounced subscribers who're still valid but had a temporary issue (server outage, account lock that resolved).

Hard-to-soft retry policy via per-server config:

Some operators want more retries before flipping soft to hard. In the sending-server admin config, the Retry policy field accepts:

• default — 3 retries (1h, 6h, 24h) then flip to hard
• aggressive — 5 retries (1h, 6h, 24h, 72h, 168h)
• conservative — 2 retries (1h, 24h)

For B2B receivers (Proofpoint, Mimecast) that greylist heavily, aggressive retains more addresses.

Bounce-to-list-update pipeline — feed hard bounces back to your CRM-of-record to mark the contact as undeliverable:

# Wire AcelleMail's `subscriber.bounced` webhook to your CRM
# (configurable in admin → API & Webhooks)

# Webhook fires on each bounce flip with:
{
  "event": "subscriber.bounced",
  "subscriber_email": "...",
  "list_uid": "...",
  "dsn_code": "5.1.1",
  "bounce_type": "hard",
  "reason": "..."
}

# CRM updates: contact.email_status = bounced
# Sales team sees the warning before next email outreach

End result: bounces don't just live in AcelleMail — they propagate to wherever the contact also exists.