Công cụ phổ biến

Giao diện

Kiểm Tra DKIM

Kiểm tra bản ghi DKIM của một tên miền theo cách các máy chủ thư nhận tìm thấy chúng, hoặc dán một email để kiểm tra chữ ký của nó: selector nào trả lời, ai ký, từng khóa mạnh đến đâu, và nó có căn chỉnh với DMARC hay không.

Nguồn: 140 selector phổ biến của 67 nhà cung cấp email, hỏi qua Google Public DNS (phía sau là Cloudflare) · kiểm tra khóa theo RFC 6376 và RFC 8301 · email được xác minh ngay trong trình duyệt của bạn · không lưu gì về bạn

Hỏi 140 selector mà các nhà cung cấp email dùng tại selector._domainkey. cộng với tên miền, vì DNS không liệt kê được chúng

Thử

Cách kiểm tra bản ghi DKIM

Hãy nhập tên miền ở trên: công cụ hỏi 140 selector mà các nhà cung cấp email dùng, hiển thị mọi khóa tìm thấy kèm kích thước và nhà cung cấp, và nói thẳng khi không tìm thấy khóa nào. Biết selector? Hãy chọn Tên miền + selector và nó được kiểm tra trước.

Làm thủ công thì bạn cần selector, vì DNS không liệt kê được chúng: dig +short TXT selector._domainkey.example.com, hoặc nslookup -type=TXT với cùng tên đó trên Windows. Selector là s= trong DKIM-Signature của bất kỳ email nào (RFC 6376 §3.6.2.1).

dig cho thấy văn bản, không cho thấy ý nghĩa của nó: nó không giải mã kích thước khóa, không đi theo CNAME của nhà cung cấp, và không phân biệt ô dự phòng với ô hỏng. Đó là điều công cụ kiểm tra bản ghi DKIM này bổ sung.

dig +short TXT selector._domainkey.example.com

Mọi chuỗi TXT tại tên đó: hãy nối chúng lại để đọc khóa.

Những gì dig cho thấy, và những gì nó không cho thấy

terminal

$ dig +short TXT 20251104._domainkey.google.com 1

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2

$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3

Public-Key: (2048 bit)

$ dig +short TXT selector1._domainkey.microsoft.com 4

selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.

  1. 1Tên có dạng selector._domainkey.domainKhông có selector thì không có câu trả lời: DNS không có lệnh “liệt kê mọi khóa”.
  2. 2Hai chuỗi, một bản ghiMột chuỗi TXT chứa 255 byte, nên khóa 2048 bit bị chia nhỏ; máy chủ nhận nối chúng lại không có gì ở giữa.
  3. 3Kích thước thật của khóaopenssl giải mã p=: 2048 bit là điều RFC 8301 khuyến nghị.
  4. 4Một CNAME vào nhà cung cấpPhía sau không có TXT: đó là ô dự phòng của Microsoft 365, không phải lỗi.
Khóa của google.com và selector1 của microsoft.com đúng như DNS của Cloudflare trả về vào 25 tháng 10, 2026.

Đọc kết quả: lượt quét selector

Câu trả lời đến trước, dưới dạng một câu. Bên dưới là ai ký và chính khóa, mỗi tag được tô màu đúng trên các ký tự của nó, kèm kích thước khóa trên thang của RFC 8301; trên nền xanh navy là mọi selector mà lượt kiểm tra đã hỏi, để bạn thấy những gì đã được thử.

Không chấm điểm: một khóa đã ngừng dùng hay một selector dự phòng trống của nhà cung cấp là bình thường, và “không tìm thấy trong các selector phổ biến” không bao giờ có nghĩa là “không có DKIM”.

Kiểm tra DKIM của github.com: mười hai khóa từ sáu nhà cung cấp, lượt quét selector và thước đo kích thước khóaKiểm tra DKIM của github.com: mười hai khóa từ sáu nhà cung cấp, lượt quét selector và thước đo kích thước khóaKết luậnMột câu: có bao nhiêu khóa, và cần làm gì.Ai kýMỗi nhà cung cấp một thẻ, tìm theo CNAME hoặc một selector có trong tài liệu. Mỗi chip selector mở ra khóa của nó.KhóaMỗi tag được tô màu trên các ký tự của nó, cùng kích thước khóa trên thang của RFC 8301.Lượt quét selectorMọi tên đã hỏi, sáng lên khi trả lời: xanh lá là một khóa, hổ phách là 1024 bit, nét đứt là một ô dự phòng.Căn chỉnh DMARCMột khóa có d= là tên miền này có căn chỉnh với chính sách DMARC của nó hay không.
Kết quả kiểm tra DKIM của github.com: kết luận, ai ký, khóa tách thành từng tag kèm kích thước, và trên nền xanh navy là mọi selector mà lượt kiểm tra đã hỏi. Chọn một số để xem từng phần thể hiện điều gì.

DKIM là gì?

DKIM (DomainKeys Identified Mail) là chữ ký mà máy chủ gửi thêm vào mỗi thư, và máy chủ nhận kiểm tra bằng một khóa công khai mà tên miền công bố trong DNS (RFC 6376). Một chữ ký hợp lệ chứng minh hai điều: tên miền trong d= đã ký nó, và các phần đã ký không thay đổi kể từ đó.

Bên gửi băm nội dung vào bh= rồi ký các header đã chọn cùng hàm băm đó bằng khóa riêng thành b=. Bên nhận đọc d= và s=, lấy khóa tại s._domainkey.d, rồi làm lại cả hai bước. Chỉ cần một byte trong nội dung, hoặc trong một header đã ký, bị đổi là nó fail.

DKIM không nói gì về việc phải làm khi nó fail, và tên miền nào cũng có thể ký. Đó là việc của DMARC: nó yêu cầu một chữ ký pass có d= khớp với tên miền From:.

Một thư, được ký ở bên gửi và kiểm tra ở bên nhận

Máy chủ của example.comký bằng khóa riêng của nó
thư, kèm DKIM-Signature của nó
Bên nhậnGmail, Outlook.com, Yahoo…

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…

dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048

Thư như lúc gửi

  • Body hash khớp bh=
  • Chữ ký header xác minh được

dkim=pass header.d=example.com

Cũng thư đó, nhưng Subject bị sửa trên đường

  • Body hash khớp bh=
  • Chữ ký header không xác minh được

dkim=fail (signature-mismatch)

Cả hai kết quả đều do engine tính, từ email mẫu trên trang này và chính email đó khi Subject bị đổi sau lúc ký. RFC 6376 §3.7, RFC 8301.

Selector DKIM là gì, và tìm selector của tôi ở đâu?

Selector là tên của một khóa DKIM: s= trong chữ ký, và nhãn đầu tiên của tên DNS nơi khóa nằm (s1._domainkey.github.com). Một tên miền có thể có bao nhiêu tùy ý: mỗi nhà cung cấp, mỗi máy chủ, mỗi năm một cái (RFC 6376 §3.1).

Để tìm selector của bạn, hãy mở một email bất kỳ mà tên miền đã gửi và xem bản gốc: trong Gmail, Tuỳ chọn khác (⋮) › Hiện thư gốc liệt kê DKIM-Signature, và s= của nó là selector. Hoặc dán email vào Xác minh một email ở trên.

Hầu hết nhà cung cấp dùng tên cố định, nên lượt quét tìm ra chúng. Amazon SES, Postmark, SparkPost và HubSpot tạo một tên cho mỗi tài khoản, và chỉ một email hoặc trang quản trị của nhà cung cấp mới cho bạn biết.

Từ chữ ký đến khóa, và các tên mà nhà cung cấp dùng

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …

s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048

Google Workspacegooglequản trị viên có thể đổi tiền tố
Microsoft 365selector1 · selector2CNAME vào tenant; một cái đang dùng, một cái dự phòng
Twilio SendGrids1 · s2CNAME tới u<id>.wl<n>.sendgrid.net
Mailchimpk2 · k3CNAME tới dkim2/dkim3.mcsv.net
Fastmailfm1 · fm2 · fm3ba CNAME, mỗi lúc chỉ một cái có khóa
Proton Mailprotonmail · 2 · 3CNAME vào domains.proton.ch
Amazon SES3 token ngẫu nhiênmỗi cái 32 ký tự ngẫu nhiên: không đoán được
Postmark20240101000000pmmột ngày và “pm”: không đoán được
SparkPostscph + MMYYscph và tháng khóa được tạo
HubSpoths1-<HubID>số tài khoản của bạn
s1 của github.com đúng như DNS của Cloudflare trả về vào 25 tháng 10, 2026. Tên của các nhà cung cấp lấy từ tài liệu của chính họ (67 nhà cung cấp, 140 selector trong lượt quét).

Định dạng bản ghi DKIM: giải thích từng tag

Bản ghi DKIM là một bản ghi TXT gồm các cặp tag=value ngăn cách bằng dấu chấm phẩy; chỉ p=, khóa công khai, là bắt buộc. v=DKIM1 không bắt buộc nhưng khi có thì phải đứng đầu (RFC 6376 §3.6.1).

k= cho biết loại khóa (rsa nếu không ghi ed25519), t= mang các cờ (y thử nghiệm, s strict), h= giới hạn hàm băm và s= giới hạn dịch vụ. Một p= trống thu hồi khóa có chủ ý.

Tên tag phân biệt chữ hoa chữ thường và một tag lặp lại làm bản ghi không hợp lệ. Tag lạ bị bỏ qua.

Bản ghi, từng tag một

v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB

TagĐặtGiá trịMặc địnhGhi chú
v=Phiên bảnDKIM1DKIM1nên có; đứng đầu nếu có
k=Loại khóarsa · ed25519rsaloại lạ: khóa bị bỏ qua
p=Khóa công khai (base64)chính khóa, hoặc để trốngbắt buộctrống = đã thu hồi
t=Cờy thử nghiệm · s strictkhông cóy: coi như không ký
h=Hàm băm được phépsha256 (cấm sha1)tất cảchỉ sha1 thì fail (RFC 8301)
s=Loại dịch vụ* · email*chỉ dịch vụ khác: bị bỏ qua
n=Ghi chú cho con ngườivăn bản bất kỳ–phần mềm không bao giờ đọc

p= dài bao nhiêu, và cần bao nhiêu chuỗi TXT

RSA 1024216 ký tự · 1 chuỗi TXT
RSA 2048392 ký tự · 2 chuỗi TXT
RSA 3072564 ký tự · 3 chuỗi TXT
RSA 4096736 ký tự · 3 chuỗi TXT
Ed2551944 ký tự · 1 chuỗi TXT

ranh giới chuỗi TXT 255 byte (tính cả “v=DKIM1; k=rsa; p=”)

Độ dài p= là của các khóa SubjectPublicKeyInfo đã đo. yahoo.com công bố khóa 2048 bit của mình trong 4 chuỗi: cách chia nào cũng được, vì máy chủ nhận nối chúng lại không có gì ở giữa (RFC 6376 §3.6.2.2).

Khóa DKIM 1024 bit so với 2048 bit, và cách xoay khóa

Hãy dùng RSA 2048 bit. RFC 8301 vẫn yêu cầu bên xác minh chấp nhận khóa 1024 bit, nhưng khuyến nghị bên ký dùng ít nhất 2048, và quy định bên xác minh từ chối khóa dưới 1024 bit. M3AAWG gọi 1024 bit là “ở bờ vực bị tấn công” và báo cáo một khóa 512 bit đã bị bẻ trong khoảng 72 giờ với khoảng 75 USD.

Khóa Ed25519 nhỏ (44 ký tự p=), và để tương thích ngược, RFC 8463 cho phép bên ký thêm một chữ ký RSA bên cạnh nó: hai selector, hai chữ ký (RFC 8463).

Hãy xoay khóa bằng cách công bố khóa mới ở một selector mới, chuyển sang ký bằng nó, giữ khóa cũ 7 đến 30 ngày cho thư đang trên đường, rồi để trống p= của nó. M3AAWG gợi ý sáu tháng một lần. Các nhà cung cấp như Fastmail và Microsoft 365 làm việc này giúp bạn bằng selector dự phòng.

Các khóa thật nằm ở đâu trên thang của RFC 8301

FailHợp lệ, nâng lên 2048TốtCó thể fail ở một số máy chủ nhận
  • microsoft.com · selector2
  • github.com · k1
  • google.com · 20251104
  • fastmail.com · fm2
  • archlinux.org · dkim-rsa
  • archlinux.org · dkim-ed25519 (Ed25519)

Xoay khóa không bị gián đoạn (M3AAWG)

  1. Ngày 0Công bố khóa mới ở một selector mới
  2. Ngày 1+Chuyển sang ký bằng nó
  3. +7–30 ngàyGiữ khóa cũ cho thư đang trên đường
  4. Sau đóĐể trống p= cũ; đừng dùng lại tên đó
fastmail.comfm1p= trốngfm22.048fm3p= trốngba CNAME, một cái có khóa: xoay khóa là một thay đổi DNS ở phía Fastmail
Kích thước khóa đọc từ DNS vào 25 tháng 10, 2026, giải mã từ từng p=. RFC 8301 §3.2; M3AAWG DKIM Key Rotation Best Common Practices (2019).

Vì sao DKIM fail? Body hash, chuyển tiếp và danh sách thư

DKIM fail khi các byte đã ký bị đổi, khi không tìm thấy khóa, hoặc khi khóa không khớp với chữ ký. Chuyển tiếp không làm đổi thư vẫn giữ nguyên DKIM (khác với SPF); danh sách thư thường làm hỏng nó, vì chúng thêm chân trang hoặc gắn thẻ vào tiêu đề.

Công cụ xác minh trên trang này kiểm tra body hash và chữ ký header riêng, nên nó phân biệt được một chân trang thêm vào giữa đường với một sự giả mạo.

Body hash không xác minh được

Một danh sách thư đã thêm chân trang 153 byte. Các header vẫn xác minh được với khóa của project.example, nên đây không phải giả mạo.

Cách sửa Dùng danh sách giữ nguyên nội dung, hoặc ARC (RFC 8617) để các máy chủ nhận sau đó thấy kết quả gốc.

body-hash-mismatch

Chữ ký không xác minh được

Một header đã ký bị đổi sau khi ký (danh sách thư thêm tên của nó vào Subject), hoặc selector giờ chứa một khóa khác.

Cách sửa Đừng viết lại các header đã ký; hãy công bố khóa mới ở một selector mới thay vì thay khóa.

signature-mismatch

Không có khóa cho chữ ký

s=2023old._domainkey.shop.example là NXDOMAIN: selector đã bị xóa trong khi thư ký bằng nó vẫn đang trên đường.

Cách sửa Giữ khóa cũ được công bố 7–30 ngày sau khi chuyển; hãy để trống p= thay vì xóa.

key-not-found

Chuyển tiếp: một bên chuyển tiếp giữ nguyên thư khi chuyển đi thì DKIM vẫn hợp lệ, đó là lý do DMARC thường vẫn qua được khi chuyển tiếp nhờ DKIM, kể cả khi SPF fail.

DKIM so với SPF và DMARC

SPF cho biết máy chủ nào được gửi thư cho một tên miền, DKIM chứng minh một tên miền đã ký thư và nó không bị đổi, còn DMARC gắn cả hai với địa chỉ From: và quy định phải làm gì khi chúng fail.

Chúng trả lời những câu hỏi khác nhau, nên bạn cần cả ba: Gmail và Yahoo yêu cầu bên gửi hàng loạt có SPF và DKIM, cộng một bản ghi DMARC, và RFC 9989 khuyến nghị các tên miền ở p=reject ký DKIM thay vì dựa vào SPF.

Ba bản ghi, ba câu hỏi

Ba bản ghi, ba câu hỏiSPFDKIMDMARC
Nó chứng minh gìMáy chủ này được gửi thư cho tên miền MAIL FROMTên miền d= đã ký; các phần đã ký không đổiFrom: khớp với một tên miền đã pass SPF hoặc DKIM
Nó nằm ở đâuTXT tại github.comTXT tại s1._domainkey.github.comTXT tại _dmarc.github.com
github.com hôm nayv=spf1 … ~all12 khóa, 6 nhà cung cấpp=quarantine; sp=reject
Có qua được chuyển tiếpKhông: IP của bên chuyển tiếp không có trong danh sáchCó, khi thư đến nơi không bị đổiCó, nhờ một kết quả DKIM pass đã căn chỉnh
Hỏng khimột dịch vụ gửi mới chưa có trong bản ghinội dung hoặc một header đã ký bị đổicả hai đều không pass cho tên miền From:

Kiểm Tra Bản Ghi SPFKiểm Tra DMARC

Các bản ghi của github.com đọc vào 25 tháng 10, 2026.

Cách đọc header DKIM-Signature trong một email

Hãy mở thư gốc và tìm header DKIM-Signature: d= là người ký, s= là khóa nào, h= liệt kê các header đã ký, còn bh= và b= là hai hàm băm mà bên nhận kiểm tra.

Kết luận của bên nhận nằm ở một header riêng được thêm khi thư đến: Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. Trang Hiện thư gốc của Gmail (bằng tiếng Anh) tóm tắt nó thành “DKIM: 'PASS' with domain example.com”.

Một thư có thể mang nhiều chữ ký, mỗi bên ký một chữ ký (tên miền của bạn và dịch vụ email của bạn, hoặc một danh sách thư). Chỉ cần một chữ ký pass có d= căn chỉnh là đủ cho DMARC.

Chữ ký của email mẫu, từng tag một

v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9

  1. 1Phiên bản v=luôn là 1
  2. 2Thuật toán a=rsa-sha256 (hoặc ed25519-sha256)
  3. 3Chuẩn hóa c=relaxed chấp nhận xuống dòng lại
  4. 4Tên miền ký d=được so với From: cho DMARC
  5. 5Selector s=khóa tại s._domainkey.d
  6. 6Thời điểm ký t=Thời gian Unix: 09:12 24 thg 10, 2026
  7. 7Header đã ký h=from hai lần = ký dư
  8. 8Body hash bh=SHA-256 của nội dung đã chuẩn hóa
  9. 9Chữ ký b=trên các header h= và trường này

Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample

Email mẫu tự tạo mà trang này tải (example.com, một khóa tạo riêng cho nó), được engine xác minh.

Kiểm tra DKIM: câu hỏi thường gặp

Bản ghi DKIM là gì?

Bản ghi DKIM là một bản ghi TXT công bố khóa công khai của tên miền tại selector._domainkey.domain, ví dụ google._domainkey.example.com. Nó chứa các cặp tag=value: p= là khóa base64 và bắt buộc, k= là loại khóa, t= là các cờ. Máy chủ nhận lấy nó để kiểm tra DKIM-Signature trên thư đến. Một tên miền có thể công bố nhiều bản ghi, thường mỗi dịch vụ gửi một cái.

Làm sao tìm selector DKIM của tôi?

Hãy mở một email bất kỳ mà tên miền đã gửi, xem thư gốc và tìm header DKIM-Signature: giá trị sau s= là selector, còn d= là tên miền. Trong Gmail dùng Tuỳ chọn khác (⋮) › Hiện thư gốc; trong Outlook trên web, View › View message source. Hoặc dán email vào Xác minh một email ở trên, nó đọc s= và d= giúp bạn.

Vì sao công cụ không tìm thấy khóa dù thư của tôi có ký?

Vì DNS không liệt kê được selector: một khóa chỉ tìm thấy khi hỏi đúng tên của nó. Công cụ hỏi 140 tên mà các nhà cung cấp dùng; nếu bạn ký bằng tên khác (Amazon SES và Postmark tạo một tên cho mỗi tài khoản), lượt quét không thấy được. Hãy thêm selector từ s= của một email và nó được kiểm tra trước, hoặc xác minh một email.

Khóa DKIM 1024 bit có còn ổn không?

Nó vẫn chạy: RFC 8301 yêu cầu bên xác minh chấp nhận khóa RSA từ 1024 đến 4096 bit, và Gmail cùng Yahoo đặt 1024 bit làm mức tối thiểu. Nhưng RFC 8301 khuyến nghị bên ký dùng ít nhất 2048 bit, và M3AAWG gọi 1024 là ở bờ vực bị tấn công. Hãy lên kế hoạch xoay khóa: Microsoft 365 và Google Workspace đều có khóa 2048 bit. RFC 8301 quy định bên xác minh từ chối khóa dưới 1024 bit.

p= trống nghĩa là gì?

p= trống nghĩa là khóa đã bị thu hồi: chữ ký với selector đó fail, y như khi không có khóa. Thường đó là chủ ý. Google giữ các selector có ngày cũ của mình theo cách này, còn Fastmail và Microsoft 365 giữ các selector dự phòng trống để xoay khóa vào. Chỉ là vấn đề nếu đó đúng là selector mà thư của bạn đang ký hôm nay.

t=y trong bản ghi DKIM nghĩa là gì?

t=y đánh dấu khóa ở chế độ thử nghiệm: máy chủ nhận nên coi thư ký bằng nó như thư không ký, kể cả khi chữ ký xác minh được. Nó dành cho lần cài đặt đầu và hay bị quên. t=s thì khác: nó có nghĩa là strict, nên i= trong chữ ký phải đúng bằng tên miền ký, không phải tên miền con. Một số dịch vụ email công bố t=s trên khóa của họ; khóa SendGrid cho github.com có nó.

Vì sao DKIM fail với “body hash did not verify”?

Nội dung mà bên nhận băm không khớp với giá trị bh= trong chữ ký, nên nội dung đã đổi sau khi ký. Danh sách thư thêm chân trang, gateway bảo mật viết lại liên kết và tuyên bố miễn trừ do máy chủ thêm đều gây ra điều này. Nếu chữ ký header vẫn xác minh được, thư là thật nhưng đã bị sửa; công cụ xác minh của trang này kiểm tra riêng cả hai.

DKIM có qua được việc chuyển tiếp email không?

Thường là có. Một bên chuyển tiếp giữ nguyên thư khi chuyển đi thì chữ ký vẫn hợp lệ, vì DKIM ký nội dung, không ký đường đi. Đó là điểm khác với SPF, vốn fail ở địa chỉ IP của bên chuyển tiếp. Những bên chuyển tiếp sửa thư, như danh sách thư thêm chân trang hay thẻ tiêu đề, làm hỏng DKIM; ARC cho phép họ xác nhận kết quả gốc.

Tôi đã có SPF thì có cần DKIM không?

Có. SPF hỏng khi thư được chuyển tiếp và chỉ bao phủ địa chỉ MAIL FROM ẩn, còn DKIM qua được việc chuyển tiếp và có thể căn chỉnh với tên miền From: mà DMARC kiểm tra. Gmail và Yahoo yêu cầu cả hai từ bên gửi hàng loạt, Outlook.com từ tháng 5 năm 2025, và RFC 9989 khuyến nghị các tên miền có p=reject ký DKIM cho thư của mình.

Bao lâu nên xoay khóa DKIM một lần?

M3AAWG khuyến nghị ít nhất sáu tháng một lần. Hãy công bố khóa mới ở một selector mới, chuyển sang ký bằng nó, giữ khóa cũ được công bố 7 đến 30 ngày để thư đang trên đường vẫn xác minh được, rồi để trống p= của nó thay vì xóa. Đừng bao giờ dùng lại một tên selector. Các nhà cung cấp lưu trữ dùng selector CNAME sẽ xoay khóa giúp bạn.

Email của tôi có bị tải lên khi tôi xác minh ở đây không?

Không. Công cụ này kiểm tra email ngay trong trình duyệt của bạn: DNS công cộng chỉ được hỏi tên khóa (s._domainkey.d), còn dnsrobot.net chỉ được hỏi chính sách DMARC của tên miền From và tên miền ký. Ngoại lệ duy nhất là chữ ký Ed25519 mà trình duyệt không kiểm tra được: trang hỏi bạn trước khi gửi email một lần tới máy chủ của chúng tôi, nơi nó được kiểm tra trong bộ nhớ và không lưu.

Tôi có dùng được khóa DKIM Ed25519 không?

Có. RFC 8463 định nghĩa nó và yêu cầu bên xác minh hỗ trợ. Để tương thích ngược, hãy công bố nó ở selector riêng cạnh một khóa RSA và ký mỗi thư hai lần, như archlinux.org làm với dkim-ed25519 và dkim-rsa: máy chủ nhận không xác minh được Ed25519 vẫn còn chữ ký RSA. Microsoft 365 và Google Workspace chỉ có khóa RSA.

Còn thiếu điều gì?Đề xuất tính năng hoặc công cụ mới

Công cụ email và DNS liên quan