Hard bounce

A hard bounce is a permanent email delivery failure. The receiving mail server has returned a rejection that the sender should treat as final — the address is not deliverable now, and retrying will not change that. Common hard-bounce causes: the mailbox does not exist (5.1.1), the domain has no MX record, the receiving server has explicitly blocked the sender, or the message violates a content policy that will not resolve on retry. The opposite is a soft bounce — a temporary failure (mailbox full, server down) that may succeed if retried later.

AcelleMail collapses the many vendor-specific bounce shapes onto a small semantic enum. The file app/SendingServers/Webhooks/BounceType.php defines exactly two cases that drive the blacklist decision:

enum BounceType: string
{
    case HARD = 'hard';
    case SOFT = 'soft';
}

The raw vendor string (Amazon SNS sends Permanent / Transient / Undetermined; Mailgun, SparkPost, SendGrid each have their own taxonomy) is preserved separately as BounceReceived::$bounceTypeRaw for audit. The model BounceLog then mirrors this with three constants — HARD, SOFT, UNKNOWN — keyed off the legacy column.

Mailbox providers score sender reputation in part on bounce rate. Sending to a known-undeliverable address a second time is the strongest possible signal that the sender is not maintaining their list — and that signal will demote the sender's reputation across all recipients, not just the bad one. AcelleMail's BounceHandler + RecordBounce listener converts a HARD webhook event into a row in BounceLog and flips the subscriber's status to blacklisted; the address is then excluded from every future campaign on that account. Soft bounces do not auto-blacklist; they accumulate, and only after a configurable streak does the address graduate to blacklist.

Industry baseline: keep hard-bounce rate below 2% per campaign. Sustained higher rates trigger reputation downgrades at Gmail / Outlook. The fastest way to drive bounce rate down is double opt-in plus periodic list cleansing — see double opt-in and deliverability §8 for the operational playbook.