# Chuyển DMARC từ p=none sang p=reject trong 30 ngày URL chính tắc: https://brew.new/vi/blog/dmarc-p-none-to-reject-in-30-days Tác giả: Thomas Park Ngày đăng: 2026-10-04 Ngày cập nhật: 2026-10-04 DMARC là một bản ghi TXT tại `_dmarc.`, cho bên nhận thư biết phải xử lý thế nào với những email dùng tên miền của bạn trong header From nhưng không đạt cả SPF lẫn DKIM được căn chỉnh (alignment) với tên miền đó, và gửi báo cáo về đâu. `p=none` chỉ yêu cầu gửi báo cáo, `p=quarantine` yêu cầu bên nhận coi thư không đạt là đáng ngờ, còn `p=reject` yêu cầu họ từ chối thư đó. Gmail, Yahoo và Microsoft chấp nhận `p=none` từ người gửi hàng loạt, nên nhiều tên miền công bố chính sách này rồi dừng ở đó: nhận báo cáo về kẻ giả mạo mà không chặn chúng. Phân tích của Red Sift trên 73,3 triệu tên miền, được trích dẫn vào [tháng 4/2026](https://redsift.com/blog/email-authentication-bespinlabs-redsift), cho thấy 14,9% có chính sách DMARC (ở bất kỳ mức nào) và 2,5% thực thi `p=reject`. EasyDMARC, một nhà cung cấp dịch vụ DMARC khác, [báo cáo năm 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) rằng trong số các công ty Fortune 500 có DMARC, 62,7% dùng `p=reject`, so với 15,2% ở các công ty thuộc Inc. 5000. Dưới đây là kế hoạch 30 ngày để lên `p=reject`, đi qua từng bản ghi, dành cho một tên miền gửi email từ hộp thư công việc, một hoặc hai ESP, một phần mềm hỗ trợ khách hàng và một công cụ thanh toán. Ba mươi ngày phù hợp với một tên miền phụ chuyên để gửi email. Tên miền mà nhân viên dùng cho email hằng ngày cần nhiều thời gian hơn. ## Những điểm chính - Công bố `v=DMARC1; p=none; rua=mailto:...` ngay từ ngày 1. Nếu không có `rua`, bên nhận thư không được phép gửi báo cáo tổng hợp. - Mọi nguồn gửi hợp lệ đều phải đạt SPF hoặc DKIM được căn chỉnh với tên miền From của bạn. Với hầu hết công cụ, điều đó nghĩa là ký DKIM bằng tên miền của bạn. - Giữ SPF ở mức tối đa 10 thành phần cần truy vấn DNS, tính cả các include lồng nhau, nếu không toàn bộ email của bạn sẽ nhận kết quả `permerror`. - Chuyển sang `p=quarantine` vào ngày 15 và `p=reject` vào ngày 22, mỗi lần sau một tuần báo cáo sạch. Với tên miền nhân viên dùng cho email hằng ngày, RFC 9989 yêu cầu dành một tháng cho mỗi giai đoạn trong hai giai đoạn đầu. - RFC 9989 (tháng 5/2026) xếp `pct` vào nhóm “historic” (đã lỗi thời). Hãy bỏ qua lộ trình tăng dần `pct=10`, `pct=50`. - BIMI cần `p=quarantine` hoặc `p=reject` trên tên miền tổ chức, không có `sp=none`, một logo SVG Tiny PS và, với Gmail, một chứng chỉ VMC hoặc CMC. ## Những thay đổi của DMARC trong năm 2026 Vào tháng 5/2026, IETF đã thay RFC 7489, một tài liệu thuộc loại Informational từ năm 2015, bằng DMARCbis: [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), một Proposed Standard (tiêu chuẩn đề xuất) đồng thời thay thế RFC 9091, cùng [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) cho báo cáo tổng hợp. Có ba thay đổi quan trọng ở đây: - **`pct` đã lỗi thời.** Phụ lục A.6 cho biết thẻ này “thường không được áp dụng chính xác, trừ khi giá trị được chỉ định là 0 hoặc 100”. - **`t=y` thay cho `pct=0`.** Bên nhận thư áp dụng mức thấp hơn chính sách của bạn một bậc, nên `p=reject; t=y` hoạt động như quarantine. Đây là một công tắc thử nghiệm. - **`np` là thẻ mới.** Thẻ này áp dụng cho các tên miền phụ không tồn tại trong DNS, và bên nhận thư đời cũ phải bỏ qua nó. Việc duyệt cây DNS (DNS tree walk) cũng thay thế danh sách hậu tố công khai (Public Suffix List) trong việc xác định tên miền tổ chức (organizational domain). ## Ba bản ghi mà DMARC dựa vào DMARC đạt khi SPF hoặc DKIM đạt **và** tên miền đạt kiểm tra đó căn chỉnh với tên miền From. Chỉ cần một kết quả đạt đã căn chỉnh là đủ. ### SPF và giới hạn 10 lượt tra cứu SPF cấp quyền gửi cho các máy chủ đối với tên miền phong bì (`MAIL FROM` hoặc return-path), danh tính duy nhất mà DMARC sử dụng, chứ không phải HELO. [RFC 7208, mục 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) giới hạn tối đa 10 thành phần cần truy vấn DNS: `include`, `a`, `mx`, `ptr`, `exists` và `redirect`, tính qua mọi include lồng nhau. `ip4`, `ip6` và `all` không bị tính. Vượt quá giới hạn này, kết quả sẽ là `permerror`. Mục này cũng chỉ cho phép tối đa hai “lượt tra cứu rỗng” (void lookup), thường là một include trỏ tới tên máy chủ không còn tồn tại. ```dns example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all" ``` Bản ghi trên đã dùng 4 lượt tra cứu, chưa kể những gì mỗi nhà cung cấp lồng bên trong, nên hãy phân giải từng include bằng `dig +short TXT ` theo cả chuỗi. Để không vượt quá 10, hãy bỏ các công cụ không còn dùng, hoặc cấp cho mỗi ESP một tên miền phụ return-path riêng như `bounce.example.com`, với hạn mức 10 lượt tra cứu của riêng nó. [Hướng dẫn thiết lập SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) của Microsoft khuyến nghị kết thúc bằng `-all` trên những tên miền đồng thời dùng DKIM và DMARC. Nhiều ESP mặc định dùng tên miền return-path của chính họ, vốn không căn chỉnh với tên miền của bạn. Hãy thiết lập return-path tùy chỉnh hoặc dựa vào DKIM. ### DKIM: khóa 2048 bit, selector và xoay vòng khóa DKIM ký mỗi email bằng một tên miền `d=` và một selector `s=`; bên nhận lấy khóa từ `._domainkey.`. Một công cụ ký bằng `d=vendor-mail.example` sẽ đạt DKIM nhưng không đạt DMARC. [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) quy định bên ký phải dùng khóa RSA tối thiểu 1024 bit và nên dùng 2048 bit. [Hướng dẫn dành cho người gửi](https://support.google.com/mail/answer/81126) của Google cũng yêu cầu tương tự đối với email gửi tới tài khoản Gmail cá nhân. Khóa 2048 bit vượt quá giới hạn 255 ký tự của một chuỗi TXT, nên khóa được nhập dưới dạng nhiều chuỗi đặt trong ngoặc kép trong cùng một bản ghi; hầu hết nhà cung cấp DNS sẽ tự tách giúp bạn. ```dns s202610._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..." "...remainder-of-the-2048-bit-key...IDAQAB" ) ``` Hãy cấp cho mỗi hệ thống gửi một selector riêng và đừng bao giờ dùng lại tên cũ. Đặt tên theo ngày, như `s202610`, giúp lịch sử dễ theo dõi. [Thực tiễn xoay vòng khóa](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) của M3AAWG khuyến nghị xoay vòng ít nhất sáu tháng một lần: 1. Công bố selector mới và chờ bản ghi lan truyền. 2. Chuyển sang ký bằng khóa mới. 3. Giữ khóa công khai cũ trong DNS từ 7 đến 30 ngày để email đang trên đường đi vẫn xác minh được. 4. Ngừng dùng selector cũ bằng cách để trống `p=`. Đừng xóa selector đó. ### Căn chỉnh: nới lỏng hay nghiêm ngặt RFC 9989 định nghĩa hai chế độ: | Chế độ | Thẻ | Tên miền đạt SPF/DKIM | Tên miền From | Đã căn chỉnh? | |---|---|---|---|---| | Nới lỏng (relaxed, mặc định) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Có, cùng tên miền tổ chức | | Nghiêm ngặt (strict) | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Không, tên phải trùng khớp | | Cả hai chế độ | | `vendor.example.net` | `example.com` | Không | RFC 9989 ghi nhận rằng “gần như mọi Chủ sở hữu tên miền đều thấy căn chỉnh nới lỏng là đủ”. Hãy bỏ `aspf` và `adkim` ra khỏi bản ghi. Căn chỉnh SPF nghiêm ngặt sẽ làm hỏng cách dùng return-path thông thường trên một tên miền phụ. ## Kế hoạch 30 ngày ![Lộ trình DMARC 30 ngày gồm bốn giai đoạn: ngày 1 đến 7 ở p=none với báo cáo rua, ngày 8 đến 14 sửa các nguồn gửi, ngày 15 chuyển sang p=quarantine, ngày 22 chuyển sang p=reject, rồi BIMI từ ngày 30, kèm bản ghi TXT chính xác cho từng giai đoạn.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *Bản ghi cho từng giai đoạn. Chỉ chuyển bước sau một tuần báo cáo sạch.* | Ngày | Chính sách | Việc cần làm | Điều kiện để chuyển bước | |---|---|---|---| | 1 đến 7 | `p=none` | Công bố kèm `rua`, liệt kê mọi nguồn gửi | 7 ngày báo cáo từ Google, Yahoo và Microsoft | | 8 đến 14 | `p=none` | Sửa DKIM và SPF, loại bỏ các nguồn gửi không còn dùng | Mọi nguồn gửi hợp lệ đều đạt SPF hoặc DKIM đã căn chỉnh | | 15 đến 21 | `p=quarantine` | Theo dõi thư hợp lệ bị cách ly | 7 ngày không có nguồn gửi hợp lệ nào không đạt | | 22 đến 30 | `p=reject` | Tiếp tục đọc báo cáo, thêm `np=reject` | Ổn định trong một tuần | | 30+ | `p=reject` | Bắt đầu với BIMI | Đã được cấp chứng chỉ | Nếu tuần thứ hai phát hiện một nguồn gửi mà không ai sửa được, hãy giữ nguyên `p=none`. Từ chối chính hóa đơn của mình còn tệ hơn việc thực thi muộn. ### Ngày 1 đến 7: công bố p=none kèm báo cáo ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` Báo cáo là tệp XML nén gzip, mỗi bên nhận gửi ít nhất một lần mỗi ngày, nên hãy trỏ `rua` tới một công cụ xử lý báo cáo chứ không phải tới một người. Nếu địa chỉ đó thuộc một tên miền tổ chức khác, theo RFC 9990, bên nhận sẽ bỏ qua địa chỉ này trừ khi `example.com._report._dmarc.` cho phép. Các dịch vụ xử lý báo cáo sẽ công bố bản ghi đó; với các tên miền của chính bạn, hãy tự thêm. Chỉ công bố đúng một bản ghi DMARC. Nếu các trình hướng dẫn thiết lập để lại hai bản ghi `v=DMARC1` tại `_dmarc.example.com`, bên nhận sẽ loại bỏ cả hai. Hãy bỏ qua `ruf`. RFC 9989 lưu ý rằng những bên nhận chú trọng quyền riêng tư sẽ lược bỏ rất nhiều thông tin trong báo cáo lỗi (failure report) hoặc không gửi, và phần câu hỏi thường gặp trong [thông báo dành cho người gửi số lượng lớn](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) của Microsoft cho biết Microsoft gửi báo cáo `rua` và không có kế hoạch gửi `ruf`. ### Cách đọc báo cáo tổng hợp RFC 9990 mô tả các báo cáo XML “hằng ngày (hoặc thường xuyên hơn)”, mỗi tên miền chính sách một báo cáo. Dưới đây là một bản ghi, phỏng theo mẫu trong RFC: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` Trong `policy_evaluated`, `dkim` và `spf` là kết quả **căn chỉnh**, còn `disposition` là cách bên nhận đã xử lý thư. `auth_results` chứa kết quả gốc cùng tên miền tương ứng. Ở đây cả hai đều đạt cho `vendor.example`, nên cả hai đều không đạt căn chỉnh: một nhà cung cấp đang gửi email dưới danh nghĩa của bạn mà không ký bằng tên miền của bạn. Hãy bật DKIM tùy chỉnh hoặc tính năng xác thực tên miền của nhà cung cấp đó. ### Ngày 1 đến 7: tìm các nguồn gửi chưa xác định Nhóm theo `source_ip`, `envelope_from` và cặp `domain` cùng `selector` của DKIM, sắp xếp theo `count`, rồi phân loại: | Dấu hiệu trong báo cáo | Nguyên nhân có thể | Hành động | |---|---|---| | DKIM hoặc SPF đạt và đã căn chỉnh | Đã cấu hình đúng | Không cần | | DKIM và SPF đạt cho tên miền của nhà cung cấp | Công cụ SaaS dùng danh tính của chính nó | Bật DKIM tùy chỉnh | | DKIM đạt và đã căn chỉnh, SPF không đạt, IP của nhà cung cấp hộp thư hoặc danh sách thư | Chuyển tiếp hoặc danh sách thư | Thường không cần. DKIM đã căn chỉnh vẫn đạt khi thư được chuyển tiếp | | Không có DKIM, SPF không đạt, IP không xác định được nguồn | Giả mạo | Không cần. Đây chính là thứ mà `p=reject` ngăn chặn | Để xác định một IP thuộc về ai, hãy chạy `dig -x 192.0.2.123 +short` và xem selector, vốn thường mang tên nhà cung cấp. Sau đó, hỏi bộ phận tài chính, hỗ trợ và kinh doanh xem những gì đang gửi email dưới danh nghĩa công ty: hệ thống thanh toán, phần mềm hỗ trợ khách hàng, lời mời lịch họp, máy quét văn phòng. Thư chuyển tiếp và thư từ danh sách thư sẽ không đạt theo những cách bạn không sửa được, và [trang câu hỏi thường gặp dành cho người gửi](https://support.google.com/mail/answer/14229414) của Google không yêu cầu căn chỉnh với những thư này, nên đừng vì chúng mà trì hoãn kế hoạch. ### Ngày 8 đến 14: sửa mọi nguồn gửi hợp lệ Làm lần lượt từ nguồn có `count` cao nhất xuống: 1. **Hộp thư công việc** (Google Workspace, Microsoft 365). Bật DKIM trong bảng điều khiển quản trị, dùng khóa 2048 bit nếu có, và xác nhận include của nhà cung cấp đã có trong SPF. 2. **ESP và công cụ tiếp thị.** Thiết lập xác thực tên miền để các công cụ này ký bằng `d=` của bạn, kèm return-path tùy chỉnh nếu được hỗ trợ. 3. **Phần mềm hỗ trợ khách hàng, thanh toán, CRM.** Làm tương tự như với ESP. Nếu công cụ nào không ký được bằng tên miền của bạn, hãy dùng một tên miền phụ mà công cụ đó ký được, hoặc dùng tên miền của chính nó. 4. **Công cụ không còn dùng.** Xóa include và selector của chúng. Sau đó, đếm lại số lượt tra cứu SPF. ### Ngày 15: p=quarantine ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` Quarantine thường đồng nghĩa với thư mục spam. Hãy để ý những nguồn gửi hợp lệ có disposition là `quarantine`. Để diễn tập, `p=quarantine; t=y` yêu cầu các bên nhận tuân theo RFC 9989 áp dụng `none`, dù RFC này mới ra đời được vài tháng và chưa phải bên nhận nào cũng hỗ trợ `t`. ### Ngày 22: p=reject ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com" ``` Những bên nhận tuân thủ `p=reject` sẽ từ chối thư không đạt ngay trong phiên SMTP, nhưng RFC 9989 yêu cầu họ cách ly thư khi chính sách là bằng chứng duy nhất, nên một phần thư sẽ rơi vào spam. RFC này cũng quy định một tên miền ở mức `p=reject` “KHÔNG ĐƯỢC chỉ dựa vào SPF” và phải ký bằng DKIM, vì việc chuyển tiếp làm hỏng SPF nhưng không làm hỏng DKIM. Hãy xác nhận DKIM đã căn chỉnh trên mọi nguồn gửi trước. Hãy giữ `rua` vĩnh viễn. Công cụ mới của quý sau sẽ xuất hiện trong báo cáo của bạn trước khi xuất hiện trong hàng đợi hỗ trợ. ### Khi nào nên kéo dài kế hoạch RFC 9989, mục 7.4, quy định những tên miền có người dùng gửi bài lên danh sách thư “KHÔNG NÊN” công bố `p=reject`, và nếu công bố thì trước hết nên dành “ít nhất một tháng” ở `p=none` và “một khoảng thời gian dài tương đương” ở `p=quarantine`. Phần lớn tên miền gốc của các công ty thuộc trường hợp này, nên với những tên miền đó, hãy dành một tháng cho mỗi giai đoạn trong hai giai đoạn đầu. Tên miền phụ chỉ dùng cho ESP không có lưu lượng từ danh sách thư và có thể giữ nhịp 30 ngày. ### Chính sách cho tên miền phụ: sp= và np= `p` áp dụng cho tên miền và các tên miền phụ của nó. `sp` ghi đè `p` cho các tên miền phụ đang tồn tại, còn `np` cho các tên miền phụ không tồn tại. Tên miền phụ có bản ghi riêng sẽ dùng bản ghi đó, và RFC 9989 bỏ qua `sp` trong trường hợp này. Một tên miền phụ chuyên để gửi như `mail.example.com`, chỉ do một ESP sử dụng với SPF và DKIM đã xác minh, có thể công bố `p=reject` ngay từ ngày đầu. Đặt `p=none; sp=reject` trên tên miền gốc sẽ bảo vệ các tên miền phụ trong lúc bạn hoàn tất tên miền chính, nhưng sẽ chặn BIMI. Các tên miền không sử dụng (parked domain) nên công bố `v=spf1 -all`, theo hướng dẫn SPF của Microsoft, cùng `v=DMARC1; p=reject;` tại `_dmarc`. ## Từ ngày 30 trở đi: BIMI BIMI hiển thị logo của bạn bên cạnh email đã xác thực trong những hộp thư có hỗ trợ: | Yêu cầu | Chi tiết | Nguồn | |---|---|---| | Chính sách DMARC | `p=quarantine` hoặc `p=reject` trên tên miền tổ chức và tên miền From | Bản dự thảo BIMI | | Chính sách tên miền phụ | Nếu có công bố `sp`, giá trị không được là `none` | Bản dự thảo BIMI | | Tỷ lệ phần trăm | Quarantine không được có `pct` dưới 100 | Bản dự thảo BIMI | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, một thẻ ``, không có script hay tham chiếu bên ngoài, không có `x=` hoặc `y=` ở phần tử gốc | BIMI Group | | Chứng chỉ | Gmail cần VMC (nhãn hiệu đã đăng ký, có dấu tích xác minh) hoặc CMC (không cần nhãn hiệu, không có dấu tích) | Google | [Bản dự thảo BIMI](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) đang ở phiên bản sửa đổi 14 (tháng 5/2026), vẫn là một Internet-Draft được viết dựa trên RFC 7489, nên mới còn nhắc đến `pct`. Hãy bỏ `pct` và đừng đặt `t=y`. Quy tắc về tên miền tổ chức gây khó cho những ai gửi từ tên miền phụ: khi `mail.example.com` ở `p=reject` còn `example.com` ở `p=none`, bên nhận không được hiển thị logo, nên tên miền gốc cũng phải đi hết kế hoạch. [Hướng dẫn về SVG của BIMI Group](https://bimigroup.org/creating-bimi-svg-logo-files/) khuyến nghị dùng logo vuông, căn giữa, trên nền màu đồng nhất, dung lượng dưới 32 KB. Google [đã bổ sung hỗ trợ CMC vào tháng 9/2024](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). Bản ghi theo [hướng dẫn triển khai của BIMI Group](https://bimigroup.org/implementation-guide/): ```dns default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem" ``` Việc đăng ký nhãn hiệu mất nhiều tháng, nên nếu cần VMC, hãy bắt đầu ngay từ bây giờ. ## Gmail, Yahoo và Microsoft yêu cầu gì Không bên nào trong ba bên yêu cầu chế độ thực thi, mà chỉ yêu cầu có bản ghi DMARC và căn chỉnh. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Ngưỡng áp dụng | Gần 5.000 email mỗi ngày tới tài khoản Gmail cá nhân, tính theo tên miền chính, áp dụng vĩnh viễn khi đã đạt ngưỡng | Người gửi hàng loạt, không nêu con số | Hơn 5.000 email mỗi ngày tới outlook.com, hotmail.com và live.com, tính theo tên miền From | | SPF và DKIM | Cả hai | Cả hai | Cả hai đều phải đạt | | DMARC | Bắt buộc có bản ghi, chấp nhận `p=none` | Tối thiểu `p=none`, rất nên có `rua` | Tối thiểu `p=none` | | Căn chỉnh | SPF hoặc DKIM | SPF hoặc DKIM, chế độ nới lỏng là được | SPF hoặc DKIM | | Khi không đạt | Từ chối thư tạm thời và vĩnh viễn từ tháng 11/2025 | Không nêu rõ | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Nguồn: [Hướng dẫn dành cho người gửi](https://support.google.com/mail/answer/81126) và [trang câu hỏi thường gặp](https://support.google.com/mail/answer/14229414) của Google, [Các phương pháp hay nhất dành cho người gửi](https://senders.yahooinc.com/best-practices/) của Yahoo, cùng [thông báo tháng 4/2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) và [trang hỗ trợ về lỗi 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) của Microsoft. Microsoft bắt đầu thực thi từ ngày 5/5/2025, sau khi bản cập nhật ngày 29/4 đổi cách xử lý từ chuyển vào thư mục rác sang từ chối thư. Trang câu hỏi thường gặp của Google cho biết căn chỉnh cả SPF lẫn DKIM “cuối cùng sẽ trở thành yêu cầu đối với người gửi”, nên hãy căn chỉnh cả hai ngay trong tuần thứ hai. Về tỷ lệ hủy đăng ký và tỷ lệ spam, hãy xem [những gì vẫn áp dụng khi agent gửi email thay bạn](/vi/blog/agent-email-deliverability) và [hướng dẫn về khả năng gửi đến](/vi/blog/email-deliverability) của chúng tôi. ## DMARC trên tên miền gửi trong Brew [Quy trình thiết lập tên miền](https://docs.brew.new/get-started/verify-your-sending-domain) của Brew yêu cầu: - **DKIM**, một bản ghi TXT tại một selector `._domainkey` bên dưới tên miền gửi của bạn. Bắt buộc. - **SPF**, một bản ghi MX và một bản ghi TXT trên `send.<your sending domain>`, return-path của Brew. Bắt buộc. - **DMARC**, một bản ghi TXT tại `_dmarc.<your sending domain>`. Không bắt buộc nhưng được khuyến nghị. - Một bản ghi **CNAME** cho theo dõi lượt nhấp, chỉ khi dùng tên miền phụ theo dõi tùy chỉnh. Tên miền có thể gửi email ngay khi SPF và DKIM được xác minh, và Brew sẽ gợi ý một giá trị DMARC phù hợp: ```dns ; dedicated sending subdomain, e.g. mail.example.com _dmarc.mail.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com" ; apex domain, or a domain Brew can't prove is dedicated _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` Tên miền phụ chuyên dụng được gợi ý `p=reject` vì không có gì gửi từ tên miền đó trước khi SPF và DKIM của Brew được xác minh. Tên miền gốc được gợi ý `p=none` vì nhiều khả năng các công cụ khác của bạn cũng gửi email dưới tên miền đó, nên hãy áp dụng kế hoạch ở trên. Căn chỉnh vẫn ở chế độ nới lỏng vì return-path `send.<domain>` chỉ căn chỉnh được ở chế độ này. Brew đọc bản ghi `_dmarc.<sending domain>` đang được công bố khi thêm tên miền, khi xác minh và ở mỗi lần kiểm tra lại. **Tên miền** hiển thị kết quả, cũng như `get_domain_health` qua MCP và `GET /v1/domains/{domainId}/health`: - **`dmarc_missing`**, một cảnh báo kèm chính xác bản ghi cần thêm. - **`dmarc_invalid`**, khi có hai bản ghi DMARC tại cùng một tên, hoặc sai phiên bản, sai chính sách hay có thẻ bị trùng. Kết quả này chỉ rõ bản ghi cần xóa. - **Đã xác minh**, khi tìm thấy đúng một bản ghi hợp lệ. Thiết lập DNS tự động chỉ ghi bản ghi DMARC khi chưa có bản ghi nào, nên không bao giờ tạo bản ghi trùng. Việc kiểm tra diễn ra ở tên miền gửi chứ không phải tên miền cha, nên hãy tạo bản ghi riêng cho mỗi tên miền phụ dùng để gửi, kể cả tên miền cho [email giao dịch](/vi/blog/transactional-emails) nếu bạn tách riêng hai loại email như tài liệu khuyến nghị. Công cụ xử lý `rua` là nơi bạn đọc báo cáo và quyết định khi nào chuyển sang reject. ## Câu hỏi thường gặp ### Nên giữ p=none bao lâu trước khi chuyển sang quarantine? Cho đến khi báo cáo của trọn một tuần cho thấy mọi nguồn gửi hợp lệ đều đạt SPF hoặc DKIM đã căn chỉnh, thường là một đến hai tuần với một tên miền phụ dùng để gửi. Với tên miền nhân viên dùng cho email hằng ngày, RFC 9989 yêu cầu ít nhất một tháng. Hai năm ở `p=none` mà không ai đọc báo cáo thì chẳng có ý nghĩa gì. ### Thẻ pct của DMARC đã lỗi thời chưa? Có. RFC 9989 xếp `pct` vào nhóm “historic” và thay những giá trị đáng tin cậy duy nhất của nó bằng `t`: `t=y` hoạt động như `pct=0`, `t=n` như `pct=100`. Bên nhận đời cũ có thể vẫn đọc `pct`, nhưng chưa bao giờ áp dụng nhất quán các giá trị ở giữa, nên hãy chuyển theo từng bước trọn vẹn. ### p=reject có chặn email được chuyển tiếp của tôi không? Việc chuyển tiếp đơn thuần thường làm hỏng SPF nhưng không làm hỏng DKIM, nên DKIM đã căn chỉnh vẫn đạt. Những danh sách thư sửa tiêu đề hoặc chân email sẽ làm hỏng DKIM, và một số danh sách viết lại header From để bù lại. Có DKIM đã căn chỉnh trên mọi nguồn gửi là cách bảo vệ tốt nhất. ### Gmail và Yahoo có yêu cầu p=reject không? Không. Cả hai đều yêu cầu người gửi hàng loạt công bố DMARC và chấp nhận `p=none`, Microsoft cũng vậy với người gửi hơn 5.000 email mỗi ngày tới Outlook.com. Chế độ thực thi ngăn chặn hành vi giả mạo và là điều kiện bắt buộc của BIMI, nhưng không bên nào trong ba bên yêu cầu. ### Tôi có cần VMC cho BIMI không? Với Gmail, bạn cần VMC, loại chứng chỉ yêu cầu nhãn hiệu đã đăng ký và hiển thị dấu tích xác minh, hoặc CMC, loại hiển thị logo mà không có dấu tích. [BIMI Group](https://bimigroup.org/understanding-bimi-certificate-types/) cho biết một số nhà cung cấp, gồm Yahoo và Fastmail, cũng hiển thị logo tự khai báo mà không cần chứng chỉ.