Kiểm tra cấu hình xác thực email của tên miền: SPF, DKIM, DMARC và hơn thế
Thư gửi từ tên miền công ty rơi vào spam, khách báo không nhận được báo giá, hay có kẻ giả danh công ty gửi thư lừa đảo: phần lớn bắt nguồn từ bản ghi DNS xác thực email thiếu hoặc sai. Công cụ kiểm tra SPF, DKIM, DMARC này tra DNS thật qua DNS-over-HTTPS, đọc từng bản ghi MX, SPF, DMARC, DKIM, BIMI, MTA-STS, TLS-RPT của tên miền và chỉ ra lỗi cụ thể kèm cách sửa bằng tiếng Việt. Không cần đăng ký, không gửi thư thử, kết quả có sau vài giây.
Tính năng nổi bật
- Tra DNS thật qua DNS-over-HTTPS của Cloudflare, tự chuyển sang Google Public DNS khi Cloudflare lỗi hoặc quá 6 giây
- Đọc bản ghi MX, sắp xếp theo độ ưu tiên và nhận diện nhà cung cấp như Google Workspace, Microsoft 365, Zoho, Lark
- Phân tích SPF: đếm số lần tra DNS đệ quy qua mọi include và redirect, so với giới hạn 10 của RFC 7208
- Phát hiện nhiều bản ghi SPF, +all, ?all, thiếu all, cơ chế ptr, include trỏ tới tên miền không có SPF, lỗi cú pháp
- Hiển thị cây include SPF để thấy dịch vụ nào chiếm nhiều lượt tra cứu
- Đọc DMARC: chính sách p, sp, pct, địa chỉ nhận báo cáo rua; tự dò bản ghi của tên miền cha khi kiểm tra tên miền con
- Kiểm tra DKIM với selector bạn nhập và 20 selector phổ biến, đọc khóa công khai và tính độ dài khóa RSA thật từ dữ liệu khóa
- Đọc BIMI, MTA-STS và TLS-RPT nếu có
- Mỗi lỗi có nhãn Đạt, Cảnh báo, Lỗi, Thông tin và hướng dẫn sửa cụ thể
- Chạy trong trình duyệt, không cần tài khoản; nói rõ phần không kiểm tra được như blacklist
Vì sao cần kiểm tra bằng DNS thật thay vì nhìn bảng điều khiển
Bảng quản lý DNS của nhà cung cấp tên miền chỉ cho biết bạn đã gõ gì, không cho biết máy nhận thư sẽ hiểu thế nào. Một bản ghi SPF có thể trông đúng nhưng vượt 10 lần tra cứu khi tính cả các include lồng nhau của Google, Microsoft, công cụ gửi thư hàng loạt. Hai bản ghi SPF song song làm SPF hỏng hoàn toàn dù từng bản ghi đều đúng cú pháp. Khóa DKIM dán thiếu vài ký tự vẫn được lưu nhưng không xác minh được chữ ký. Công cụ này hỏi DNS công cộng đúng như máy chủ Gmail, Outlook hỏi, rồi đi theo từng include để đếm lượt tra cứu và đọc khóa DKIM ở mức byte, nên phát hiện được những lỗi mà mắt thường khó thấy.
Lợi ích khi sử dụng
- Biết chính xác vì sao thư vào spam thay vì đoán mò
- Phát hiện SPF vượt 10 lookup trước khi thêm dịch vụ gửi thư mới
- Tránh bị kẻ xấu giả mạo tên miền công ty để lừa khách hàng, đối tác
- Đáp ứng yêu cầu xác thực của Gmail và Yahoo áp dụng từ tháng 2/2024
- Hướng dẫn sửa bằng tiếng Việt, đưa cho bộ phận IT hoặc nhà cung cấp làm theo được ngay
- Kiểm tra lại ngay sau khi sửa, không giới hạn số lần
Cách kiểm tra SPF, DKIM, DMARC của tên miền
- 1Nhập tên miền gửi thư (ví dụ congty.vn) hoặc dán nguyên địa chỉ email, công cụ tự lấy phần sau dấu @.
- 2Nếu biết selector DKIM (xem ở bước sửa lỗi bên dưới), nhập vào ô Selector DKIM; có thể nhập nhiều selector cách nhau bằng dấu phẩy.
- 3Giữ ô Dò thêm selector phổ biến nếu chưa biết selector, công cụ sẽ thử 20 selector hay gặp.
- 4Bấm Kiểm tra và đợi vài giây trong lúc công cụ tra DNS.
- 5Đọc phần Tổng hợp để biết số lỗi, cảnh báo; sau đó xem từng mục MX, SPF, DMARC, DKIM, BIMI/MTA-STS/TLS-RPT.
- 6Sửa bản ghi theo dòng Cách sửa trong trang quản lý DNS, đợi hết thời gian TTL rồi bấm Kiểm tra lại.
SPF, DKIM, DMARC khác nhau thế nào
Ba bản ghi này giải quyết ba câu hỏi khác nhau. SPF (Sender Policy Framework, RFC 7208) trả lời: máy chủ nào được phép gửi thư cho tên miền này? Bản ghi là một dòng TXT bắt đầu bằng v=spf1, liệt kê IP hoặc include của dịch vụ gửi thư, kết thúc bằng all để nói cách xử lý máy chủ không có trong danh sách. DKIM (DomainKeys Identified Mail, RFC 6376) trả lời: thư có thật do tên miền này ký và không bị sửa trên đường đi? Máy chủ gửi ký thư bằng khóa bí mật, khóa công khai đặt ở bản ghi TXT selector._domainkey.tenmien. DMARC (RFC 7489) trả lời: khi SPF và DKIM không khớp với tên miền ở dòng From, máy nhận nên làm gì, và gửi báo cáo về đâu? Điểm hay bị hiểu sai là DMARC đòi hỏi căn chỉnh (alignment): SPF hoặc DKIM phải đạt VÀ tên miền được xác thực phải trùng tên miền người xem thấy ở dòng From. Thư gửi qua dịch vụ bên ngoài có thể qua SPF với tên miền của dịch vụ nhưng vẫn trượt DMARC. Cách chắc chắn nhất là bật DKIM với tên miền của chính bạn trên mọi dịch vụ gửi thư.
Giới hạn 10 lần tra DNS của SPF và cách công cụ đếm
RFC 7208 mục 4.6.4 giới hạn mỗi lần kiểm tra SPF được tra DNS tối đa 10 lần cho các cơ chế include, a, mx, ptr, exists và modifier redirect. Vượt giới hạn, kết quả là permerror và nhiều máy nhận coi như SPF không tồn tại. Cơ chế ip4, ip6 và all không tốn lượt. Điều dễ bỏ sót là lượt tra cứu tính cả bên trong các include: include:_spf.google.com trước đây tự kéo thêm ba include con, include của Microsoft 365 cũng kéo thêm, nên một bản ghi chỉ có năm include có thể đã tốn tám, chín lượt. Công cụ đi theo từng include và redirect, đọc bản ghi SPF của từng tên miền con và cộng dồn, đồng thời đếm lượt tra rỗng (include trỏ tới tên miền không có SPF), RFC khuyến nghị giới hạn 2. Cây include hiển thị ngay dưới mục SPF giúp bạn thấy dịch vụ nào tốn nhiều lượt. Khi sát giới hạn, cách xử lý là bỏ dịch vụ không còn dùng, thay a và mx bằng ip4 cụ thể, hoặc dùng dịch vụ làm phẳng SPF và theo dõi khi nhà cung cấp đổi IP.
Chọn -all hay ~all cho SPF
Phần all ở cuối bản ghi quyết định máy chủ lạ bị xử lý ra sao. -all (hardfail) tuyên bố rõ: ngoài danh sách là giả mạo. ~all (softfail) nói: ngoài danh sách là đáng ngờ, hãy xem xét thêm. ?all (neutral) không khẳng định gì, gần như vô dụng. +all cho phép mọi máy chủ trên Internet gửi thư thay bạn, là lỗi nghiêm trọng. Trên thực tế, khi đã có DMARC, ~all và -all cho kết quả gần như nhau vì quyết định cuối cùng do chính sách DMARC đưa ra. Nhiều quản trị viên chọn ~all để tránh thư hợp lệ bị chặn thẳng khi quên thêm một dịch vụ gửi, sau đó theo dõi báo cáo DMARC và chuyển sang -all khi chắc chắn. Công cụ đánh giá cả hai là Đạt, ?all là Cảnh báo, +all là Lỗi. Nếu bản ghi không có all mà dùng redirect, công cụ đi theo redirect để lấy all của bản ghi đích, đúng như cách máy nhận xử lý.
Lộ trình nâng DMARC từ p=none lên p=reject
Bật DMARC thẳng ở p=reject khi chưa biết hết các nguồn gửi thư là cách nhanh nhất để thư hóa đơn, thư từ phần mềm kế toán hay form liên hệ website bị chặn. Lộ trình an toàn gồm ba bước. Bước một: đặt v=DMARC1; p=none; rua=mailto:dmarc@tenmien để chỉ theo dõi. Máy nhận lớn như Google, Microsoft, Yahoo sẽ gửi báo cáo tổng hợp dạng XML hằng ngày, cho biết IP nào đang gửi thư nhân danh tên miền và có qua SPF, DKIM hay không. Bước hai: sau hai đến bốn tuần, khi mọi nguồn hợp lệ đã đạt, chuyển sang p=quarantine, có thể kèm pct=25 rồi tăng dần lên 100. Bước ba: chuyển sang p=reject. Gmail và Yahoo từ tháng 2/2024 yêu cầu người gửi trên 5.000 thư mỗi ngày tới Gmail phải có DMARC tối thiểu p=none, cùng với SPF, DKIM và dòng From khớp tên miền. Lưu ý thêm: thẻ sp= đặt chính sách riêng cho tên miền con; nếu sp=none trong khi p=reject, kẻ giả mạo vẫn dùng được tên miền con bất kỳ.
Tìm selector DKIM của tên miền
Khác với SPF và DMARC nằm ở vị trí cố định, khóa DKIM nằm ở selector._domainkey.tenmien, trong đó selector do nhà cung cấp đặt và DNS không cho phép liệt kê tất cả bản ghi. Vì vậy không có công cụ nào khẳng định chắc chắn một tên miền không có DKIM chỉ bằng cách tra DNS. Google Workspace mặc định dùng selector google, Microsoft 365 dùng selector1 và selector2 (bản ghi CNAME trỏ sang tên miền onmicrosoft.com), SendGrid dùng s1 và s2, Mailchimp dùng k1, k2, k3, HubSpot dùng hs1 và hs2, nhiều hosting cPanel dùng default. Công cụ thử sẵn 20 selector phổ biến. Cách chắc chắn nhất: mở một thư bạn đã gửi tới Gmail, chọn Hiển thị thư gốc, tìm dòng DKIM-Signature; giá trị sau s= là selector, sau d= là tên miền ký. Nếu d= là tên miền của nhà cung cấp chứ không phải tên miền của bạn, DKIM vẫn đạt nhưng không căn chỉnh với DMARC, cần cấu hình tên miền riêng trong dịch vụ đó.
Độ dài khóa DKIM: 1024 hay 2048 bit
Công cụ giải mã giá trị p= trong bản ghi DKIM (chuỗi base64 chứa khóa công khai theo cấu trúc ASN.1 DER), đọc phần modulus của khóa RSA và đếm số bit thật, không suy đoán từ độ dài chuỗi. RFC 8301 năm 2018 yêu cầu khóa RSA tối thiểu 1024 bit và khuyến nghị 2048 bit; khóa dưới 1024 bit bị nhiều máy nhận coi như không có chữ ký. Khóa 1024 bit vẫn được chấp nhận rộng rãi nhưng nên nâng lên 2048 khi nhà cung cấp hỗ trợ. Khóa 2048 bit dài hơn giới hạn 255 ký tự của một chuỗi TXT, nên DNS phải lưu thành nhiều chuỗi nối nhau; một số bảng quản lý DNS cũ cắt mất phần sau, khiến khóa hỏng. Khi công cụ báo không đọc được khóa RSA, khả năng cao là bản ghi đã bị cắt hoặc dán thừa ký tự. Ngoài RSA, RFC 8463 cho phép khóa Ed25519 ngắn hơn nhiều, nhưng nên ký kèm một khóa RSA vì chưa phải máy nhận nào cũng hỗ trợ. Công cụ cũng cảnh báo khi bản ghi còn t=y (chế độ thử nghiệm) hoặc chỉ cho phép thuật toán sha1 đã bị loại bỏ.
MTA-STS, TLS-RPT và BIMI có cần không
Ba bản ghi này là tùy chọn nâng cao nên công cụ chỉ đánh dấu Thông tin khi thiếu. MTA-STS (RFC 8461) cho phép bạn tuyên bố máy chủ nhận thư của mình luôn hỗ trợ TLS, buộc máy gửi phải mã hóa kết nối và kiểm tra chứng chỉ, chống tấn công hạ cấp xuống kết nối không mã hóa. Nó gồm bản ghi TXT _mta-sts.tenmien chứa id và một tệp chính sách tại https://mta-sts.tenmien/.well-known/mta-sts.txt. Công cụ đọc được bản ghi DNS nhưng không mở được tệp chính sách vì trình duyệt chặn đọc chéo tên miền, bạn cần mở tệp đó trực tiếp để xem mode là testing hay enforce. TLS-RPT (RFC 8460) tại _smtp._tls.tenmien cho bạn nhận báo cáo khi máy gửi không kết nối TLS được. BIMI tại default._bimi.tenmien cho phép hiển thị logo thương hiệu cạnh thư ở Gmail, Yahoo, Apple Mail; điều kiện là DMARC ở quarantine hoặc reject, logo dạng SVG Tiny PS và với Gmail thì cần chứng chỉ VMC hoặc CMC có phí.
Những gì công cụ không kiểm tra và vì sao
Công cụ chỉ báo những gì đo được từ DNS. Thứ nhất, không kiểm tra danh sách đen (DNSBL) như Spamhaus, Barracuda. Spamhaus chặn truy vấn đi qua các máy chủ DNS công cộng như Cloudflare, Google và trả về mã lỗi riêng, nên tra từ trình duyệt qua DNS-over-HTTPS sẽ cho kết quả sai; một số danh sách khác yêu cầu đăng ký. Hãy dùng trang tra cứu chính thức của từng danh sách với IP máy chủ gửi thư. Thứ hai, không gửi thư thử và không chấm điểm nội dung thư: tỷ lệ vào hộp thư còn phụ thuộc uy tín IP, lịch sử gửi, tỷ lệ người nhận đánh dấu spam, nội dung và liên kết trong thư. Thứ ba, không xác minh chữ ký DKIM của một thư cụ thể; muốn biết thư thật có qua SPF, DKIM, DMARC hay không, mở thư gốc trong Gmail và xem các dòng SPF, DKIM, DMARC: PASS, hoặc dán toàn bộ header vào công cụ phân tích header email. Kết quả DNS cũng có thể chậm cập nhật theo TTL sau khi bạn sửa bản ghi.
Câu hỏi thường gặp (FAQ)
Làm sao biết tên miền đã cài SPF, DKIM, DMARC chưa?
Nhập tên miền vào công cụ và bấm Kiểm tra. SPF và DMARC được tra ở vị trí cố định nên kết quả chắc chắn. DKIM phụ thuộc selector: nếu công cụ không tìm thấy với 20 selector phổ biến, hãy lấy selector từ dòng DKIM-Signature (giá trị s=) trong thư gốc rồi nhập vào ô Selector DKIM.
Vì sao email công ty gửi đi bị vào thư mục spam?
Nguyên nhân phổ biến nhất là thiếu SPF, DKIM hoặc DMARC, hoặc thư gửi qua dịch vụ chưa được khai báo trong SPF và chưa ký DKIM bằng tên miền của bạn. Ngoài ra còn do IP gửi nằm trong danh sách đen, nội dung giống thư rác, gửi hàng loạt tới danh sách cũ. Công cụ giúp loại trừ nhóm lỗi DNS trước.
Một tên miền có được để hai bản ghi SPF không?
Không. RFC 7208 chỉ cho phép một bản ghi v=spf1; có hai bản ghi thì máy nhận trả permerror và SPF coi như hỏng. Hãy gộp tất cả include, ip4 vào một bản ghi, ví dụ v=spf1 include:_spf.google.com include:servers.mcsv.net ~all.
SPF vượt quá 10 lookup thì sửa thế nào?
Xem cây include trong mục SPF để biết dịch vụ nào tốn nhiều lượt. Bỏ include của dịch vụ không còn dùng, thay cơ chế a và mx bằng ip4 cụ thể của máy chủ, bỏ ptr. Nếu vẫn vượt, dùng dịch vụ làm phẳng SPF (thay include bằng danh sách IP) và cập nhật định kỳ.
Nên dùng ~all hay -all?
Cả hai đều được công cụ đánh giá Đạt. Khi đã có DMARC, quyết định cuối cùng do DMARC đưa ra nên khác biệt không lớn. ~all an toàn hơn khi bạn chưa chắc đã liệt kê đủ nguồn gửi; chuyển sang -all khi báo cáo DMARC cho thấy mọi nguồn hợp lệ đều đạt. Tuyệt đối không dùng +all.
DMARC p=none có tác dụng gì không?
p=none chỉ theo dõi: thư giả mạo vẫn được giao, nhưng bạn nhận báo cáo về ai đang gửi thư nhân danh tên miền. Nó đủ yêu cầu tối thiểu của Gmail và Yahoo với người gửi số lượng lớn, nhưng không chống giả mạo. Nên nâng dần lên quarantine rồi reject.
Bản ghi DMARC đặt ở đâu?
Tạo bản ghi TXT với tên _dmarc (tức _dmarc.tenmien.vn), giá trị ví dụ v=DMARC1; p=none; rua=mailto:dmarc@tenmien.vn. Chỉ để một bản ghi DMARC; có nhiều bản ghi thì máy nhận bỏ qua DMARC.
Kiểm tra tên miền con thì DMARC lấy ở đâu?
Nếu tên miền con không có bản ghi _dmarc riêng, công cụ dò lên tên miền cha và báo bản ghi được kế thừa. Khi đó chính sách áp dụng là sp= nếu có, nếu không thì là p= của tên miền cha.
Google Workspace dùng selector DKIM gì?
Mặc định là google, tức bản ghi google._domainkey.tenmien. Bạn bật DKIM trong Google Admin, mục Ứng dụng, Google Workspace, Gmail, Xác thực email; tạo khóa 2048 bit, thêm bản ghi TXT rồi bấm Bắt đầu xác thực.
Microsoft 365 dùng selector DKIM gì?
Microsoft 365 dùng selector1 và selector2. Bạn tạo hai bản ghi CNAME selector1._domainkey và selector2._domainkey trỏ về tên miền onmicrosoft.com theo hướng dẫn trong Microsoft Defender, sau đó bật ký DKIM. Công cụ đi theo CNAME và đọc khóa thật ở đích.
Khóa DKIM 1024 bit có cần đổi không?
Không bắt buộc ngay vì 1024 bit vẫn được chấp nhận, nhưng khuyến nghị hiện nay là 2048 bit. Khi đổi, tạo selector mới với khóa 2048 bit, đợi DNS cập nhật rồi mới chuyển máy chủ sang ký bằng selector mới để không có thư nào trượt DKIM.
Công cụ có kiểm tra tên miền có nằm trong blacklist không?
Không. Danh sách đen lớn như Spamhaus chặn truy vấn qua DNS công cộng nên kết quả từ trình duyệt sẽ sai. Hãy tra IP máy chủ gửi thư trên trang chính thức của từng danh sách đen.
Vừa sửa bản ghi DNS mà công cụ vẫn báo lỗi cũ?
DNS có bộ nhớ đệm theo TTL của bản ghi, thường từ 5 phút đến vài giờ. Công cụ hỏi máy chủ DNS công cộng của Cloudflare hoặc Google nên có thể còn giữ giá trị cũ. Đợi hết TTL rồi kiểm tra lại.
Kiểm tra trên điện thoại được không?
Được. Công cụ chạy trên trình duyệt điện thoại, chỉ cần có mạng để gửi truy vấn DNS-over-HTTPS tới Cloudflare hoặc Google.
Tên miền không dùng email có cần SPF, DMARC không?
Nên có, để chống bị giả mạo. Đặt SPF v=spf1 -all (không máy chủ nào được gửi), DMARC v=DMARC1; p=reject và nếu không nhận thư thì đặt Null MX là MX 0 . theo RFC 7505.
Công cụ có lưu tên miền tôi kiểm tra không?
Không. Trình duyệt của bạn gửi truy vấn DNS trực tiếp tới Cloudflare (hoặc Google khi Cloudflare lỗi); máy chủ của Tấn Phát Digital không nhận và không lưu tên miền.
MTA-STS báo có bản ghi nhưng sao không biết mode?
Chế độ testing hay enforce nằm trong tệp chính sách https://mta-sts.tenmien/.well-known/mta-sts.txt. Trình duyệt chặn đọc tệp ở tên miền khác nên công cụ chỉ đọc bản ghi DNS; hãy mở trực tiếp đường dẫn đó để xem.
Từ khóa liên quan
- kiểm tra spf
- kiểm tra dkim
- kiểm tra dmarc
- check spf record
- check dmarc
- spf checker
- dmarc checker
- dkim checker
- email deliverability tester
- email vào spam
- cấu hình spf dkim dmarc
- bản ghi spf
- bản ghi dmarc
- selector dkim
- spf too many dns lookups
- kiểm tra mx record
- xác thực email tên miền
- email doanh nghiệp vào spam
- dmarc p=none
- spf softfail hardfail
- mta-sts
- bimi là gì
- google workspace dkim
- microsoft 365 dkim selector