Kế hoạch theo từng tuần để đưa tên miền từ DMARC p=none sang quarantine rồi reject, kèm bản ghi DNS chính xác, cách đọc báo cáo và những gì BIMI cần sau đó.
DMARC là một bản ghi TXT tại _dmarc.<your domain>, 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, 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 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.
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.permerror.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.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.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.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, một Proposed Standard (tiêu chuẩn đề xuất) đồng thời thay thế RFC 9091, cùng RFC 9990 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).
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 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 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.
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 <name> 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 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 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ừ <selector>._domainkey.<d domain>. Một công cụ ký bằng d=vendor-mail.example sẽ đạt DKIM nhưng không đạt DMARC.
RFC 8301 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 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.
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 của M3AAWG khuyến nghị xoay vòng ít nhất sáu tháng một lần:
p=. Đừng xóa selector đó.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ụ.
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.
_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.<report domain> 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 của Microsoft cho biết Microsoft gửi báo cáo rua và không có kế hoạch gửi ruf.
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:
<record>
<row>
<source_ip>192.0.2.123</source_ip>
<count>123</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<envelope_from>bounces.vendor.example</envelope_from>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>vendor.example</domain>
<selector>abc123</selector>
<result>pass</result>
</dkim>
<spf>
<domain>bounces.vendor.example</domain>
<result>pass</result>
</spf>
</auth_results>
</record>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 đó.
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 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.
Làm lần lượt từ nguồn có count cao nhất xuống:
d= của bạn, kèm return-path tùy chỉnh nếu được hỗ trợ.Sau đó, đếm lại số lượt tra cứu SPF.
_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.
_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ợ.
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.
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.
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ẻ <title>, 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) |
Bản dự thảo BIMI đ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 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. Bản ghi theo hướng dẫn triển khai của BIMI Group:
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ờ.
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 và trang câu hỏi thường gặp của Google, Các phương pháp hay nhất dành cho người gửi của Yahoo, cùng thông báo tháng 4/2025 và trang hỗ trợ về lỗi 5.7.515 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 và hướng dẫn về khả năng gửi đến của chúng tôi.
Quy trình thiết lập tên miền của Brew yêu cầu:
._domainkey bên dưới tên miền gửi của bạn. Bắt buộc.send.<your sending domain>, return-path của Brew. Bắt buộc._dmarc.<your sending domain>. Không bắt buộc nhưng được khuyến nghị.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:
; 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.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 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.
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ì.
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.
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.
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.
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 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ỉ.
