Soft bounce

Soft bounce là lỗi giao email tạm thời. Máy chủ thư nhận từ chối message tạm thời, nhưng nguyên nhân là điều có thể tự giải quyết — mailbox người nhận vượt quota, máy chủ nhận đang tạm xuống hoặc rate-limit, message bị greylist ở lần thử đầu, hoặc có hiccup TLS handshake. Sender được kỳ vọng sẽ retry. So với hard bounce — từ chối vĩnh viễn không nên retry.

Cùng enum BounceType dẫn dắt xử lý hard-bounce có case thứ hai:

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

Webhook event SOFT từ vendor (SES, Mailgun, SparkPost, …) được ghi vào BounceLog giống hệt hard bounce, nhưng listener RecordBounce không tự blacklist subscriber sau một lần duy nhất. Địa chỉ vẫn active và vẫn nằm trong campaign tiếp theo. Nếu soft bounce tiếp tục tích lũy qua một streak có thể cấu hình, operator có thể đẩy địa chỉ lên blacklist qua bounce-handler policy — nhưng một soft bounce đơn lẻ được coi là noise.

Gộp soft và hard bounce là sai lầm xử lý bounce phổ biến nhất trên các nền tảng nhỏ. Tự blacklist khi soft bounce sẽ co list lại mỗi khi server của người nhận gặp hiccup — một sự cố Gmail có thể "rụng" hàng nghìn subscriber hợp lệ. Xử lý hard bounce như soft (cứ retry) đốt uy tín người gửi. AcelleMail thực thi sự tách biệt này ngay ở lớp data model (BounceType::HARD vs BounceType::SOFT) nên listener không thể vô tình lẫn lộn.

• SMTP response 4xx — toàn bộ class 4xx nghĩa là "lỗi tạm thời, hãy retry."
• Mailbox đầy — người nhận chạm cap dung lượng; thường thông sau vài ngày.
• Greylisting — kỹ thuật chống spam delay sender lạ ở lần đầu; retry hợp lệ thành công trong vài phút.
• Rate limiting — receiver đang giới hạn traffic từ IP/domain này; back off và retry.
• Sự cố TLS / kết nối — vấn đề mạng hoặc certificate tạm thời ở phía nhận.

Playbook vận hành đầy đủ — khi nào soft bounce nên escalate lên blacklist, streak length hợp lý là bao nhiêu, và cách đọc raw reason từ vendor — nằm trong deliverability §8.