Bộ quy tắc bulk-sender tháng 2/2024 của Gmail và Yahoo đã thay đổi điều gì

Vào ngày 1 tháng 2 năm 2024, Google và Yahoo đồng loạt thực thi các yêu cầu mới cho mọi sender vượt quá 5.000 message mỗi ngày tới tệp người dùng của họ. Hai thông báo đó vẫn là tham chiếu chuẩn mực — "Email sender guidelines" của Google và "Sender best practices" của Yahoo — và về bản chất chúng gần như giống hệt nhau. Ba yêu cầu:

1. Xác thực (Authentication). SPF và DKIM là bắt buộc; DMARC tối thiểu ở mức p=none là bắt buộc. Mail không align sẽ vào spam hoặc bị từ chối.
2. One-click unsubscribe. Header List-Unsubscribe (RFC 2369, 1998) vốn đã có từ lâu; điều mà năm 2024 bổ sung là yêu cầu one-click — URL unsubscribe phải chấp nhận một POST request duy nhất và xử lý nó mà không cần bước xác nhận (RFC 8058, 2017). Người dùng click một lần trong mail client là được unsubscribe.
3. Trần complaint-rate. Bulk sender phải giữ tỷ lệ spam-complaint dưới 0,3% mọi lúc. Tỷ lệ cao kéo dài sẽ kích hoạt việc tự động đẩy xuống spam folder.

Trước 2024, đa số người tự host chỉ chạy SPF + DKIM và bỏ qua DMARC. Lập luận: DMARC chỉ là một chính sách chồng lên hai thứ kia, và việc nhận report ngược về vận hành phiền hà. Lập luận đó giờ không còn dùng được nữa.

Cụ thể, quy tắc 2024 yêu cầu DMARC phải tồn tại — dù chỉ ở p=none — và phải align. "Align" trong DMARC nghĩa là hoặc From-domain của SPF, hoặc domain ký DKIM, khớp với header From: hiển thị, ở chế độ strict hoặc relaxed alignment. Một thất bại phổ biến: sender dùng marketing@yourcompany.com làm From hiển thị nhưng route qua một CRM bên thứ ba ký DKIM bằng domain của CRM — alignment fail, DMARC fail, và Gmail / Yahoo âm thầm route message vào spam.

Cách khắc phục là quy trình triển khai DMARC tiêu chuẩn: publish p=none kèm RUA reporting, theo dõi aggregate hằng ngày trong hai đến bốn tuần, xác định và sửa các luồng không align, leo qua p=quarantine, chốt ở p=reject. Không có đường tắt.

Mức kỹ thuật là hai header, cả hai theo RFC 8058:

Mail client (Gmail, Yahoo, Apple Mail) render hai header này thành một link "Unsubscribe" một-cú-click ở phần header của message. Khi user click, client POST List-Unsubscribe=One-Click tới URL. Server của bạn xử lý unsubscribe và trả 200 OK. Không trang xác nhận, không captcha, không đăng nhập.

AcelleMail emit cả hai header này theo mặc định cho mọi campaign list đã bật xử lý unsubscribe. Chỗ vận hành viên hay vấp là các tích hợp tuỳ biến — luồng transactional bypass campaign engine, SMTP relay bên thứ ba strip mất header, hoặc URL unsubscribe redirect qua một trang xác nhận của CMS. Mỗi trường hợp đó đều là một cú trừ điểm về deliverability.

Cách kiểm tra đơn giản nhất: gửi cho chính mình một test, click "Show original" trong Gmail, tìm List-Unsubscribe-Post. Nếu header thiếu hoặc không nói One-Click, bạn không tuân thủ. Sửa trước khi volume vượt 5.000/ngày tới một trong hai provider.

Complaint rate là tỷ lệ phần trăm người nhận đánh dấu message của bạn là spam, tính theo ngày trên một cửa sổ trượt. Thông báo của Google yêu cầu "dưới 0,3%" duy trì, kèm "chúng tôi muốn thấy tỷ lệ của bạn ổn định dưới 0,1%" như mức biên vận hành.

Hai ghi chú khi triển khai:

1. Tính per-domain, không phải per-account. Nếu bạn tách marketing sang subdomain (ví dụ news.yourcompany.com) thì complaint rate được tính riêng cho subdomain đó. Một subdomain vượt 0,3% không tự động đẩy traffic transactional trên apex domain xuống spam, đó là một lý do tại sao thông lệ chuẩn là cô lập marketing trên subdomain. (Xem /glossary/email-deliverability.)
2. Gmail và Yahoo đo khác nhau. Gmail dùng tỷ lệ click nút spam trong nhóm người nhận đã mở mail. Yahoo dùng một metric tương tự trên giao diện của họ. Cả hai con số nên bám sát nhau trong khoảng ~0,05%; chênh lệch lớn thường là do skew của audience chứ không phải vấn đề của sender.

Để có khả năng quan sát, đăng ký Google Postmaster Tools (miễn phí, cần verify DNS domain của bạn) và Complaint Feedback Loop của Yahoo. Cả hai đều bộc lộ số complaint-rate theo ngày. AcelleMail tiêu thụ feed complaint cấp SES qua SNS webhook (app/SendingServers/Webhooks/ComplaintReceived.php), đây là nguồn sự thật ở cấp sending-server. Số liệu của Gmail / Yahoo là post-delivery; số liệu SES là at-acceptance.

Nói chặt chẽ, quy tắc 2024 chỉ áp với bulk sender — >5.000/ngày tới Gmail hoặc Yahoo. Dưới ngưỡng đó, các yêu cầu là "best practice" chứ không bị thực thi.

Trên thực tế, điều này vô nghĩa. Sender dưới 5.000 vẫn bị quẳng vào spam vì thiếu DMARC, thiếu one-click unsubscribe, hoặc complaint rate cao. Heuristic mà provider chạy phần lớn vẫn vậy; khác biệt là trên 5.000 thì provider sẽ publish bạn vào một queue "bulk sender" với automation chặt hơn, còn dưới ngưỡng bạn rơi vào một track manual-review / dựa-trên-engagement. Dù sao, bỏ qua quy tắc dưới 5.000 cũng tạo ra tổn thất deliverability đo được.

Cách đóng khung đúng: quy tắc 2024 chính thức hoá những gì vốn đã là mức ngầm định ở các provider lớn. Họ không phát minh ra yêu cầu mới; họ làm cho yêu cầu hiện hữu trở nên tường minh và được thực thi. Vận hành viên tự host dưới 5.000/ngày nên coi quy tắc này như mức làm việc bất kể ngưỡng.

Ba mô hình đã đổ vỡ ở quy mô lớn trong tháng 2-3/2024 và vẫn đang gây tổn thất deliverability đo được đến hôm nay:

1. Forwarder-DMARC-fail. Vận hành viên có mailing list forward mail tới địa chỉ cá nhân của subscriber (mô hình "list service" cổ điển) thấy mail forward của họ bị từ chối hàng loạt. Cách khắc phục là rewrite header From trên mail đã forward (cách tiếp cận ARC) hoặc chuyển list sang gửi trực tiếp từ list-domain. Cả Mailman 3 và module list của Postal đều hỗ trợ điều này.
2. Sender CRM bên thứ ba. Gửi qua một SMTP relay gắn với CRM ký bằng domain của CRM phá vỡ DMARC alignment trừ khi CRM cũng publish DKIM riêng dưới subdomain của bạn. SES, Mailgun, SparkPost, và SendGrid đều hỗ trợ; các relay cũ hơn hoặc ít phổ biến có thể không.
3. Luồng transactional không xác thực. "Chúng tôi gửi password reset qua Postfix trên cùng box chạy app, không DKIM" đã ngừng hoạt động ở bất kỳ volume có ý nghĩa nào. Cách khắc phục là publish DKIM key cho apex domain và cấu hình OpenDKIM trên bản cài Postfix — một lần làm bù lại cho toàn bộ traffic transactional.

Quy tắc 2024 hoá ra có ý nghĩa hơn nhiều so với vẻ ngoài ban đầu. Nó không chỉ nâng mức — nó làm cho mức đó cụ thể và kiểm tra được. Sender Score, Talos, GlockApps, Postmark, và các vendor giám sát deliverability đều đưa ba trụ cột này vào kiểm tra của họ chỉ trong vài tháng. Tới giữa 2025, toàn bộ hệ sinh thái công cụ deliverability thương mại đã coi DMARC + one-click unsubscribe + complaint-rate là điều kiện tiên quyết; các dịch vụ "chúng tôi sẽ giúp bạn debug SPF" kiểu cũ hoặc nâng cấp hoặc lặng lẽ đóng cửa.

Riêng với người tự host, quy tắc 2024 đẩy nhanh một sự dịch chuyển vốn đã đang diễn ra: rời xa "gửi gì cũng được, từ đâu cũng được" (chuẩn mực tự host những năm 2010) tiến tới "chỉ gửi mail đã xác thực, đã align, dễ unsubscribe, từ một domain mà bạn chủ động quản lý reputation". Đó là mức vận hành cao hơn nhưng trạng thái ổn định thì rủi ro thấp hơn. Bộ công cụ của AcelleMail cho trạng thái ổn định — WarmupStrategy, BounceHandler, suppression list, các adapter verification NeverBounce / ZeroBounce — đã có sẵn trong codebase từ trước 2024; điều thay đổi là chúng đã trở thành thiết yếu thay vì tuỳ chọn.

Nếu bạn chưa thực hiện audit tuân thủ quy tắc 2024 trên domain gửi trong sáu tháng qua, hôm nay là một ngày tốt để bắt đầu. Phiên bản năm phút: gửi cho chính mình một test, "Show original" trong Gmail, xác minh ba verdict pass cộng thêm header List-Unsubscribe-Post: List-Unsubscribe=One-Click. Nếu mọi thứ ok, bạn đã ổn. Nếu chưa, đường để đến đó đã có người đi trước.