Newsletter deliverability 2026 — những gì thực sự hiệu quả

Nếu bạn cài SPF từ năm 2022 và chưa đụng vào phần email authentication kể từ đó, khả năng cao là bạn đang thất thoát inbox placement ngay lúc này. Ba nhà cung cấp hộp thư lớn nhất — Gmail, Yahoo, và Outlook — đều đã áp dụng tiêu chuẩn authentication bắt buộc từ 2024–2025, và “chỉ có SPF” không đáp ứng bất kỳ cái nào trong số đó nữa.

Tóm gọn: cài SPF + DKIM + DMARC ở mức p=quarantine hoặc p=reject, cấu hình one-click unsubscribe, giữ spam complaint rate dưới 0.10%, và gửi từ platform tự động xử lý IP warming lúc cold-start. Về điểm cuối đó, Beehiiv và Resend hiện là lựa chọn tốt nhất cho người gửi indie; Kit và Mailchimp có những đánh đổi đáng nói ở phần dưới.

Bài này dành cho ai

Người vận hành newsletter độc lập, công ty developer tools đang chạy drip sequence, và SaaS founder gửi cả mail giao dịch lẫn marketing. Nếu bạn đang dùng managed sending platform và đã thấy inbox rate ổn, bài này là công cụ chẩn đoán để hiểu tại sao lại ổn (hoặc không). Nếu bạn đang bắt đầu từ đầu năm 2026, hãy đọc phần bốn đòn bẩy ở mục ba trước.

Những gì thay đổi trong 2024–2025

Email delivery thay đổi mang tính cấu trúc vào năm 2024. Không phải dần dần — các quy tắc đã điều chỉnh authentication hợp lệ suốt một thập kỷ bị thay thế bằng enforcement cứng.

1 tháng 2, 2024: Google + Yahoo đặt tiêu chuẩn tối thiểu

Email Sender Guidelines của Google bắt đầu áp dụng bắt buộc với bulk sender (5.000+ tin/ngày đến Gmail):

SPF trên envelope-from/Return-Path domain
DKIM signing trên sending domain
DMARC tối thiểu p=none trên visible From: domain
One-click unsubscribe (RFC 8058) — header List-Unsubscribe-Post: List-Unsubscribe=One-Click + xử lý trong 48 giờ (chỉ áp dụng cho promotional/marketing mail, không áp dụng cho transactional)
Aligned From header — visible From: domain phải align với DKIM hoặc SPF signing domain

Yahoo áp dụng tiêu chuẩn giống hệt vào cùng ngày cho bulk sender. Yêu cầu one-click unsubscribe áp dụng cho promotional mail; Yahoo loại trừ rõ ràng transactional trong sender FAQ.

Google bổ sung spam-rate threshold enforcement từ tháng 6/2024:

< 0.10%: mục tiêu vận hành được khuyến nghị
≥ 0.30%: bạn không còn đủ điều kiện để được Google hỗ trợ giảm thiểu vấn đề giao nhận. Guidelines của Google lưu ý rằng cải thiện spam rate cần thời gian để phản ánh tích cực lên phân loại sender.

Google Postmaster Tools hiện hiển thị hai đường ngưỡng 0.10% và 0.30% trong biểu đồ spam rate, nên không còn chỗ để mơ hồ về vị trí của bạn.

5 tháng 5, 2025: Microsoft bịt lỗ hổng cuối cùng

Trước tháng 5/2025, các thuộc tính consumer của Microsoft (outlook.com, hotmail.com, live.com) là một kẽ hở về deliverability. Sender không đáp ứng yêu cầu authentication của Gmail vẫn có thể vào inbox Outlook. Điều đó đã chấm dứt.

Bulk sender đến Microsoft properties nay cần cùng một stack: SPF + DKIM + DMARC, one-click unsubscribe header, spam complaint rate dưới 0.3%, và địa chỉ From/Reply-To nhận được reply. Lỗi enforcement là 550; 5.7.515 Access denied, sending domain does not meet the required authentication level.

Dữ liệu benchmark Q1 2025 của GlockApps (xem phần số liệu bên dưới) cho thấy inbox rate tại Microsoft properties sụt giảm 22–27 điểm phần trăm so với cùng kỳ năm trước trong giai đoạn chuẩn bị. Đó là cái giá của những sender chưa kịp thích nghi.

Những lời khuyên từ 2022 đang sai hoàn toàn

Lời khuyên phổ biến năm 2022 — “thêm SPF record là xong” — nay chủ động gây hại. Lý do:

SPF một mình không bảo vệ visible From: header. SPF (RFC 7208) xác thực envelope-from/Return-Path domain — địa chỉ gửi kỹ thuật mà mail server dùng để xử lý bounce. Nó không có thẩm quyền đối với header From: mà người nhận thực sự nhìn thấy. Một email giả mạo dùng domain của bạn trong From: header hoàn toàn qua được SPF nếu DMARC của bạn vắng mặt hoặc ở p=none.

DMARC ở p=none không tạo ra bất kỳ enforcement nào. Nó đáp ứng checkbox compliance của Google (mức tối thiểu là p=none), nhưng p=none nói với mailbox provider: “theo dõi thôi, đừng làm gì.” Mail giả mạo dùng domain của bạn vẫn được giao đến người nhận. Policy chỉ trở thành bảo vệ thực sự ở p=quarantine (mail thất bại vào spam) hoặc p=reject (mail thất bại bị từ chối ngay tại gateway).

SPF không có DKIM làm vỡ forwarding. Khi mail server của người nhận forward tin (email list, corporate forwarding rule), forward đó phá vỡ SPF alignment vì envelope-from thay đổi. DKIM signature tồn tại qua forwarding vì nó gắn vào header và body của tin, không phải envelope. Sender chỉ dựa vào SPF để đạt DMARC alignment sẽ thấy apparent failure trên forwarded message.

Baseline đúng trong 2026: SPF + DKIM + DMARC, với DMARC ở p=quarantine hoặc p=reject nếu bạn muốn bảo vệ thực sự (và đủ điều kiện BIMI — xem bên dưới).

Bốn đòn bẩy ảnh hưởng đến inbox placement

1. Authentication: SPF + DKIM + DMARC + BIMI

Stack này hiện là điều kiện tiên quyết, không phải lợi thế cạnh tranh. Mọi sender nghiêm túc đều cần có.

Một vài điểm đáng biết mà hầu hết hướng dẫn bỏ qua:

Tham số pct của DMARC. Tag pct kiểm soát phần trăm mail thất bại chịu sự điều chỉnh của policy. Mặc định là 100 (không có tag = 100). Khi triển khai dần từ p=none → p=quarantine → p=reject, đặt pct=25 là cách phổ biến để thử nghiệm mà không áp dụng toàn bộ. Quan trọng: nhà cung cấp BIMI yêu cầu pct=100 (hoặc không có tag). Enforcement một phần loại bạn khỏi điều kiện hiển thị logo BIMI.

DMARC alignment. Để DMARC pass, ít nhất một trong SPF hoặc DKIM phải đạt alignment — tức là signing domain khớp (hoặc là organizational subdomain của) visible From: domain. Không cần cả hai; một cái pass alignment là đủ để thỏa DMARC. Trong thực tế, DKIM alignment đáng tin hơn vì nó tồn tại qua forwarding.

Tag rua của DMARC. Thêm tag rua trỏ đến địa chỉ email hoặc dịch vụ báo cáo. Thiếu nó là không có thông tin gì — không có aggregate report nghĩa là không thấy được cái gì đang thất bại alignment hay bị giả mạo trên domain của bạn.

2. List hygiene

Spam complaint rate là tín hiệu trực tiếp nhất mà mailbox provider dùng để đánh giá sender reputation. Ngưỡng 0.10% / 0.30% tại Gmail là cụ thể — và Gmail, Yahoo, Microsoft đều có ngưỡng tương đương.

Trong thực tế, giữ complaint rate dưới 0.10% đòi hỏi:

Hard bounce suppression (xóa ngay địa chỉ bị bounce; đừng retry)
Engagement-based suppression (subscriber không mở trong 6–12 tháng là rủi ro)
Preference center hoạt động đúng — nếu trải nghiệm unsubscribe bị hỏng hoặc khó tìm, người nhận dùng “Mark as spam” thay thế

Nếu bạn đang import list mua hoặc scrape từ đâu đó, complaint rate sẽ vượt 0.30% trong vài ngày. Không có lý do deliverability nào để làm vậy.

3. Tín hiệu engagement

Mailbox provider đánh giá chất lượng sender dựa trên hành vi người nhận: mở, trả lời, kéo khỏi spam, và unsubscribe. Tỷ lệ unsubscribe cao không có hại — nó còn tốt hơn tỷ lệ complaint cao. Người unsubscribe đang nói với mailbox provider rằng nội dung không phù hợp với họ; người đánh dấu spam đang nói bạn là actor xấu.

Hệ quả thực tế: segment trước khi gửi đến toàn bộ list. Gửi re-engagement campaign đến subscriber không hoạt động trước main send, rồi loại người không phản hồi. Điều này giữ average engagement cao và complaint rate thấp.

4. Sending infrastructure: shared pool vs dedicated IP

Shared IP pool nghĩa là sender reputation của bạn bị ảnh hưởng bởi mọi sender khác trên cùng pool. Pool tốt (như SendGrid-backed pool của Beehiiv) phân nhóm sender theo engagement quality score. Pool kém (ESP lớn shared với vetting lỏng lẻo) nghĩa là inbox rate của bạn phụ thuộc vào ai vừa lạm dụng pool tuần trước.

Dedicated IP bắt đầu với zero reputation. Bạn phải warm nó — tăng dần send volume trong 6–8 tuần để mailbox provider xây dựng reputation baseline. Cho đến khi warm xong, dedicated IP thực ra có thể hoạt động tệ hơn một shared pool có uy tín.

Ai cần dedicated IP:

Sender trên 700K tin/ngày (ngưỡng Enterprise của Beehiiv)
Sender cần cách ly reputation nghiêm ngặt khỏi hàng xóm trên pool
High-volume transactional sender với daily volume đều đặn

Ai không cần:

Indie newsletter sender dưới 100K subscriber — warm shared pool tại ESP có uy tín vượt trội hơn cold dedicated IP

Hành vi của các platform trong thực tế

Beehiiv

Beehiiv chạy trên infrastructure Twilio SendGrid. Engagement Quality Score (EQS) của SendGrid định tuyến sender đến các shared pool riêng biệt dựa trên performance — sender tốt không dùng chung infrastructure với sender kém.

Cold-start được xử lý tự động qua Smart Warming: kích hoạt ở 100 subscriber (hoặc 200 nếu domain được cấu hình trước), chạy 6–8 tuần cho sender gửi hàng tuần trở lên (lâu hơn với monthly sender), và bao gồm domain reputation, sender identity, và IP reputation cùng lúc. Trong quá trình warm-up, một số tin đi qua domain của Beehiiv trong khi custom domain của sender xây dựng reputation. Không cần cấu hình gì từ phía người dùng.

Dedicated IP chỉ dành cho Enterprise (liên hệ Customer Success), chỉ cần khi gửi trên 700K tin/ngày cho mỗi publication.

Benchmark Q1 2025 của GlockApps xếp SendGrid infrastructure ở 35.31% inbox rate — thấp hơn mức trung bình 56.97% của Gmail. Con số đó phản ánh toàn bộ SendGrid pool; EQS segmentation của Beehiiv nghĩa là sender có engagement cao được định tuyến đến sub-pool tốt hơn. Con số 35.31% nên được đọc là sàn, không phải kết quả kỳ vọng của Beehiiv với list được duy trì tốt.

Với indie newsletter operator, Beehiiv là lựa chọn cold-start ít ma sát nhất. Warming tự động loại bỏ rủi ro vận hành lớn nhất cho người gửi mới. (Beehiiv) Xem so sánh trực tiếp giữa Resend và SendGrid — cơ sở hạ tầng mà Beehiiv sử dụng — tại Resend vs SendGrid.

Kit (ConvertKit)

Kit dùng shared pool infrastructure trên sending domain convertkit.com mặc định. Deliverability and Compliance team của Kit theo dõi pool.

Custom domain authentication — SPF, DKIM qua CNAME record, DMARC — là tùy chọn trong UI nhưng bắt buộc bởi Gmail/Yahoo ở quy mô. Setup là DNS thủ công, không có auto-configure tương đương tích hợp Entri của Mailchimp. Help center của Kit nói thẳng: “authentication via Verified Sending Domain is required by mailbox providers like Gmail and Yahoo.”

Cold-start friction có thật. Khi chuyển sang Verified Sending Domain, hãy chuẩn bị cho đợt giảm open rate 2–3 tuần khi provider đánh giá lại domain reputation. Cách tiếp cận được Kit khuyến nghị: suppress inactive contact hai tuần trước khi chuyển, rồi triển khai với engaged subscriber trước khi gửi đến toàn bộ list.

Dedicated IP là $250/tháng với minimum 150.000 tin/tuần. Dưới volume đó, shared pool là lựa chọn duy nhất.

Với sender cần cài authentication đúng ngay từ đầu, việc Kit thiếu auto-configure là rào cản mà Mailchimp đã giải quyết. Với sender đã ổn định có list sạch và không ngại làm DNS thủ công, compliance team theo dõi shared pool của Kit là đảm bảo chất lượng hợp lý. (Kit)

Mailchimp

Mailchimp có quá trình onboarding authentication mượt mà nhất trong bốn platform. Tích hợp Entri kết nối với các DNS provider lớn và cấu hình DKIM CNAME + DMARC TXT record mà không cần thao tác DNS thủ công. Với founder không chuyên kỹ thuật cần đạt compliance trước khi Google/Yahoo enforcement ảnh hưởng đến list của họ, đây là lợi thế thực sự so với đối thủ.

Điểm Mailchimp thua: benchmark inbox placement. Dữ liệu GlockApps Q1 2025 xếp Mailchimp ở 32.30% inbox rate — gần cuối trong bảng so sánh ESP, chỉ trên Mailgun (26.05%) và Brevo (24.93%), và thấp hơn nhiều so với mức trung bình 56.97% của Gmail. Đây là đặc điểm cấu trúc của shared pool lớn, không phải lỗ hổng authentication. Chất lượng pool của Mailchimp ở quy mô phản ánh sự đa dạng của sender, và sự đa dạng đó kéo deliverability xuống.

Câu chuyện onboarding authentication và câu chuyện inbox placement chỉ vào hai hướng đối lập nhau. Nếu bạn cần đạt compliance nhanh và list dưới 10K, Mailchimp là ổn. Nếu inbox placement ở quy mô lớn là ưu tiên hàng đầu, con số 32.30% là tín hiệu đáng chú ý. (Mailchimp) Xem so sánh chi tiết về giá và tính năng newsletter-native tại Mailchimp vs Beehiiv.

Resend

Resend là lựa chọn tốt nhất cho developer sender — team vừa gửi transactional email vừa gửi newsletter, hoặc developer solo muốn infrastructure họ hiểu được.

Domain verification bắt buộc trước khi gửi bất kỳ thứ gì và là một phần của onboarding flow. Dedicated IP yêu cầu tối thiểu 500 email/ngày và được quản lý hoàn toàn: Resend tự migrate traffic từ shared sang dedicated, scale IP count dựa trên volume và phản hồi của provider, và phân phối giữa shared + dedicated pool trong quá trình warm-up. “Khi bạn nhận dedicated IP từ Resend, bạn có thể bắt đầu gửi ở quy mô ngay lập tức” — không cần lịch warming thủ công.

Resend cũng tích hợp DMARC Analyzer trong dashboard để parse incoming DMARC aggregate report và hiển thị alignment failure. Với team đang chuyển từ p=none lên p=reject, đây là công cụ thực dụng để phát hiện vấn đề trước khi ảnh hưởng đến inbox rate.

Điểm cần lưu ý: dedicated IP yêu cầu Scale plan và volume đều đặn ở mức 500 email/ngày. Sender với lịch gửi không đều hoặc list hygiene kém phục vụ tốt hơn bởi managed shared pool — quá trình warm-up tự động phụ thuộc vào volume bền vững để xây dựng tín hiệu reputation tích cực. (Resend) Xem so sánh DX và deliverability giữa Resend và Postmark tại Resend vs Postmark.

Các con số benchmark

GlockApps dùng phương pháp seed list — tin test gửi đến địa chỉ đã biết trên các provider — nên các con số đại diện cho inbox placement tiềm năng, không phải đảm bảo cho list cụ thể của bất kỳ sender nào. Hãy đọc chúng như benchmark định hướng.

Q1 2025: đáy sau enforcement

Provider	Q1 2025	Q1 2024	Thay đổi
Gmail	53.70%	58.72%	−5.02 pp
Google Workspace	53.36%	63.85%	−10.49 pp
Outlook/Hotmail	26.77%	49.33%	−22.56 pp
Office 365	50.70%	77.43%	−26.73 pp
Yahoo/AOL	40.97%	43.32%	−2.35 pp

Sự sụp đổ tại Microsoft properties — −22 đến −27 điểm phần trăm so với cùng kỳ — là tiêu điểm của Q1 2025. Điều này tương ứng với các sender đã tuân thủ cho Gmail/Yahoo nhưng chưa kịp thích nghi trước deadline enforcement tháng 5/2025 của Microsoft.

Q4 2025: phục hồi

Provider	Q4 2025	Q3 2025	Thay đổi QoQ
Exchange/Office365	67.95%	60.61%	+7.34 pp
Yahoo	57.48%	50.78%	+6.70 pp
Gmail	56.97%	51.06%	+5.91 pp
Hotmail	46.79%	43.23%	+3.56 pp
Outlook	45.06%	41.84%	+3.22 pp

Sự phục hồi có thật nhưng không đồng đều. High-volume sender (trên 1M email/tháng) tăng +20.37% tại Gmail và +19.42% tại Office365 từ Q3 đến Q4 2025. Low-volume sender (1–10K email/tháng) lại giảm −15.50% tại Gmail trong cùng giai đoạn. Sender nhỏ vẫn đang gặp khó, có thể vì thiếu công cụ và nguồn lực deliverability chuyên biệt để thích nghi đầy đủ.

Inbox placement theo ESP (Q1 2025)

ESP	Inbox rate Q1 2025
Outlook (infrastructure riêng)	46.94%
Amazon SES	40.30%
Klaviyo	43.66%
SendGrid	35.31%
Mailchimp	32.30%
Mailgun	26.05%
Brevo	24.93%

Xu hướng nhất quán: các ESP shared pool lớn kém hơn sender dùng infrastructure riêng. Shared pool mang theo reputation tổng hợp của tất cả sender trên pool đó.

Thứ hầu hết sender bỏ qua: DMARC enforcement

Hầu hết sender làm theo hướng dẫn enforcement 2024 đều cài DMARC ở p=none rồi dừng lại. Đó là compliance, không phải bảo vệ.

p=none có nghĩa: “Tôi biết DMARC tồn tại. Đừng làm gì với failure.” Email giả mạo dùng domain của bạn vẫn lọt qua.

Con đường từ p=none đến p=reject trông như thế này:

Bắt đầu ở p=none với rua reporting. Theo dõi DMARC aggregate report trong 2–4 tuần. Bạn sẽ thấy tất cả nguồn gửi hợp lệ (ESP, CRM, transactional sender) và mọi thử nghiệm giả mạo.
Chuyển lên p=quarantine với pct=25. Mail thất bại vào spam với 25% người nhận. Theo dõi nguồn hợp lệ bạn có thể bỏ sót ở bước 1.
Tăng pct lên 100. Theo dõi các trường hợp bị vỡ.
Chuyển lên p=reject. Mail thất bại bị từ chối tại gateway. Đây là điểm bắt đầu đủ điều kiện BIMI, và là nơi bạn thực sự được bảo vệ khỏi giả mạo.

Lý do phổ biến nhất khiến sender ở mãi p=none: họ không biết thứ gì đang gửi email thay mặt họ. Mọi dịch vụ bên thứ ba được cấu hình với domain của bạn (CRM, support ticketing, billing tool, form provider) đều cần được DKIM-ký dưới domain của bạn hoặc được liệt kê trong SPF record. DMARC aggregate report hiển thị các nguồn này; DMARC Analyzer của Resend và các công cụ bên thứ ba như MXToolbox parse chúng thành định dạng dễ đọc.

BIMI: tín hiệu tin cậy qua logo

BIMI (Brand Indicators for Message Identification) hiển thị logo của bạn cạnh tên sender trong inbox. Gmail, Yahoo, và Outlook đều hỗ trợ. Điều kiện tiên quyết: DMARC ở p=quarantine hoặc p=reject với pct=100.

Từ ngày 24 tháng 9, 2024, Gmail bổ sung hỗ trợ Common Mark Certificates (CMC) — loại certificate không yêu cầu đăng ký nhãn hiệu. Trước đó, BIMI yêu cầu Verified Mark Certificate (VMC) khoảng $1.200–$1.500/năm cộng với đăng ký nhãn hiệu active. CMC loại bỏ yêu cầu nhãn hiệu và lần đầu tiên đưa BIMI vào tầm tay của indie newsletter operator.

CMC mang lại gì: hiển thị logo trong client hỗ trợ. Không có gì: dấu kiểm verified (cái đó vẫn cần VMC + nhãn hiệu). Dấu kiểm dành cho thương hiệu có hạ tầng pháp lý để duy trì nhãn hiệu; hiển thị logo là cho tất cả người còn lại.

Trạng thái BIMI của Apple Mail: Có một số ý kiến trong cộng đồng cho rằng Apple đã thêm hỗ trợ BIMI vào năm 2022. Những ý kiến này đã được phản bác trong quá trình nghiên cứu bài viết này — không có nguồn gốc đáng tin cậy nào xác nhận trạng thái BIMI hiện tại của Apple. Đừng lên kế hoạch triển khai BIMI dựa vào Apple Mail cho đến khi điều đó được xác nhận.

Lộ trình thực tế cho indie newsletter operator:

Đạt DMARC p=reject (điều kiện tiên quyết — quy trình bốn tuần ở trên)
Tạo logo SVG Tiny PS hợp lệ
Lấy CMC từ certificate authority (chi phí và sẵn có tùy nhà cung cấp; xem danh sách của BIMI Group)
Publish DNS TXT record _bimi trỏ đến logo và certificate

Hiển thị logo BIMI là “theo quyết định của từng mailbox provider” theo spec — hỗ trợ CMC không bắt buộc với tất cả provider. Nhưng Gmail, Yahoo, và các enterprise client lớn đều đã cam kết hiển thị CMC logo, đủ để phủ phần lớn audience quan trọng.

Câu hỏi còn mở (đừng hành động mà không kiểm chứng)

Hai tuyên bố đang lưu truyền trong cộng đồng cần hoài nghi cho đến khi bạn tự kiểm chứng lại với nguồn gốc hiện tại:

Google enforcement escalation tháng 11/2025: Một số nguồn cộng đồng đề cập đến việc tăng cường enforcement sau baseline tháng 2/2024. Tính đến ngày nghiên cứu bài viết này, không có tài liệu nguồn gốc nào xác nhận điều này. Kiểm tra changelog Google Email Sender Guidelines trước khi trích dẫn thay đổi enforcement tháng 11/2025 như là sự thật đã được xác nhận.

Độ chính xác của GlockApps: Phương pháp GlockApps dùng seed list, không phải list người nhận thực. Inbox placement rate trong báo cáo của họ phản ánh tin test đến mạng địa chỉ đã biết của họ, không phải inbox rate thực tế của campaign của bạn. Dùng dữ liệu benchmark để so sánh định hướng giữa các ESP; đừng coi 56.97% là con số campaign của bạn sẽ đạt được.

Kết luận + checklist

Indie newsletter operator (dưới 100K subscriber):

Dùng Beehiiv nếu bạn muốn xử lý cold-start tự động mà không phải làm gì thêm
Dùng Resend nếu bạn thoải mái với code và có kế hoạch kết hợp transactional + newsletter
Tránh Mailchimp nếu inbox placement ở quy mô lớn là ưu tiên; con số 32.30% Q1 2025 phản ánh chất lượng pool mang tính cấu trúc

Developer tools company (kết hợp transactional + marketing):

Resend dẫn đầu về quản lý dedicated IP và DMARC tooling
Kit khả dụng nếu list của bạn sạch và bạn có thể xử lý DNS setup thủ công; VSD dip có thể quản lý được

SaaS drip sequence:

Authentication là điều kiện tối thiểu — đạt DMARC p=reject trước khi lo về bất cứ thứ gì khác
Volume > 150K tin/tuần: đánh giá dedicated IP tại Kit ($250/tháng) hoặc Resend (tối thiểu 500/ngày)
Spam rate ≥ 0.10%: suppress inactive contact trước lần gửi tiếp theo, không phải sau

Authentication checklist:

SPF record trên envelope-from domain
DKIM signing được cấu hình và aligned với header From: domain
DMARC record với tag rua trỏ đến địa chỉ aggregate report
DMARC policy ở p=quarantine hoặc p=reject (không phải p=none)
pct=100 (hoặc bỏ tag hoàn toàn)
One-click unsubscribe header (List-Unsubscribe-Post: List-Unsubscribe=One-Click) cho promotional mail
Xử lý yêu cầu unsubscribe trong 48 giờ
Spam complaint rate được theo dõi qua Google Postmaster Tools; vận hành dưới 0.10%
Inactive subscriber đã được suppress (không mở trong 6–12 tháng)

Đạt DMARC p=reject và bạn đã làm được nhiều hơn cho deliverability của mình so với 90% sender đã đi qua cùng authentication checklist rồi dừng lại ở p=none.