Trả lời nhanh
Làm sao kiểm tra MX, SPF, DKIM và DMARC?
Chạy dig MX yourdomain +short để lấy MX, dig TXT yourdomain +short để lấy SPF, dig CNAME selector._domainkey.yourdomain +short cho DKIM, và dig TXT _dmarc.yourdomain +short cho DMARC. Trên Windows, nslookup làm điều tương tự. Một thiết lập Proton Mail đầy đủ trên tên miền Postelva cần 6 truy vấn cho 8 bản ghi.
Truy vấn nào kiểm tra bản ghi nào
| Bản ghi | Lệnh dig | Câu trả lời đúng trông như thế nào |
|---|---|---|
| MX | dig MX example.com +short | 10 mail.protonmail.ch. và 20 mailsec.protonmail.ch. (Proton Mail) |
| SPF | dig TXT example.com +short | Một dòng bắt đầu bằng v=spf1, ví dụ "v=spf1 include:_spf.protonmail.ch ~all" |
| DKIM | dig CNAME fm1._domainkey.example.com +short | Đích của nhà cung cấp, ví dụ fm1.example.com.dkim.fmhosted.com. (Fastmail) |
| DMARC | dig TXT _dmarc.example.com +short | Một dòng bắt đầu bằng v=DMARC1, ví dụ "v=DMARC1; p=none; rua=mailto:[email protected]" |
| MTA-STS (tùy chọn) | dig TXT _mta-sts.example.com +short | "v=STSv1; id=..." |
Kiểm tra lần cuối vào ; các số liệu cũ hơn có ngày riêng
# dig (macOS, Linux, Windows with BIND tools)
dig MX example.com +short
dig TXT example.com +short
dig CNAME protonmail._domainkey.example.com +short
dig TXT _dmarc.example.com +short
# Ask the authoritative nameserver directly, skipping caches
dig NS example.com +short
dig MX example.com +short @ns1.your-nameserver.example
# nslookup (Windows, macOS, Linux)
nslookup -type=MX example.com
nslookup -type=TXT _dmarc.example.com
# PowerShell
Resolve-DnsName -Type MX example.com
Resolve-DnsName -Type TXT _dmarc.example.comLàm sao kiểm tra một bản ghi MX?
Chạy dig MX với tên miền của bạn và +short, rồi so sánh độ ưu tiên và tên máy chủ với các giá trị nhà cung cấp đã cho bạn. Câu trả lời in một dòng cho mỗi bản ghi: độ ưu tiên, một khoảng trắng, và tên máy chủ. Với Proton Mail bạn kỳ vọng 10 mail.protonmail.ch. và 20 mailsec.protonmail.ch.; với Fastmail là 10 in1-smtp.messagingengine.com. và 20 in2-smtp.messagingengine.com.; với Mailbox.org là bốn máy chủ mxext.
Hai vấn đề hiện ra ở đây. Một bản ghi của nhà cung cấp cũ còn trong danh sách làm việc giao thư không ổn định, nên hãy xóa nó. Và một câu trả lời rỗng nghĩa là không có MX: người gửi sau đó quay về bản ghi địa chỉ của tên miền, như RFC 5321 mô tả. Ý nghĩa từng dòng được giải thích trong MX record là gì.
Làm sao kiểm tra một bản ghi SPF?
Hỏi các bản ghi TXT ở gốc tên miền và xác nhận đúng một dòng bắt đầu bằng v=spf1. Gốc cũng chứa các bản ghi TXT khác, như bằng chứng quyền sở hữu của nhà cung cấp email, nên hãy đọc toàn bộ danh sách. Hai dòng bắt đầu bằng v=spf1 là một lỗi: RFC 7208 trả về lỗi vĩnh viễn khi một tên miền có nhiều hơn một bản ghi SPF.
Sau đó đếm số truy vấn. Mỗi include, a, mx, ptr và exists, cùng với modifier redirect, đều tính vào giới hạn 10, và một include cũng tính những gì lồng bên trong nó. Một bản ghi vượt giới hạn sẽ lỗi với mọi người gửi. Cách tạo bản ghi được trình bày chi tiết trong cách tạo bản ghi SPF.
Làm sao kiểm tra DKIM khi tôi không biết selector?
Dùng selector của nhà cung cấp: bạn không thể liệt kê selector từ DNS, nên hãy lấy chúng từ màn hình DKIM của nhà cung cấp. DNS không cho phép liệt kê các tên dưới _domainkey. Selector ở Proton Mail là protonmail, protonmail2 và protonmail3; ở Fastmail là fm1, fm2 và fm3; và MBO0001 đến MBO0004 ở Mailbox.org.
Tên tra cứu là selector._domainkey.yourdomain. Một nhà cung cấp dùng bản ghi CNAME, như cả ba, sẽ trả lời bằng một CNAME tới máy chủ riêng của họ. Một nhà cung cấp công bố khóa trực tiếp sẽ trả lời bằng bản ghi TXT chứa v=DKIM1 và p= theo sau là khóa công khai. p= rỗng nghĩa là khóa đã bị thu hồi. Phép thử mạnh nhất là một thư thật, vì một bản ghi tồn tại vẫn có thể không được dùng: gửi thư sang một nhà cung cấp khác và đọc dkim=pass trong header đầy đủ.
Làm sao kiểm tra bản ghi DMARC?
Hỏi bản ghi TXT tại _dmarc.yourdomain và xác nhận một dòng bắt đầu bằng v=DMARC1 và có chính sách p=. Nếu thiếu p, người nhận coi chính sách là none. Nếu dòng không có rua, không có báo cáo tổng hợp nào được tạo, và giai đoạn giám sát của việc triển khai DMARC không cho bạn biết gì. Các bản ghi viết theo kiểu cũ có thể vẫn mang thẻ pct, mà RFC 9989 đã bỏ.
Một tên miền phụ không có bản ghi riêng sẽ theo chính sách của tên miền cha qua việc duyệt cây DNS, với tối đa tám truy vấn. Tra một tên không có bản ghi trả về rỗng, nghĩa là không có DMARC.
Vì sao tra cứu của tôi vẫn hiện giá trị cũ?
Bộ nhớ đệm giữ câu trả lời cũ cho đến khi TTL của nó hết, và một bản ghi bị thiếu cũng có thể được lưu đệm. Thời gian để thay đổi lan rộng xấp xỉ TTL cũ của bản ghi tại thời điểm bạn đổi. Hướng dẫn của nhà cung cấp cho một thay đổi MX thông thường mất một đến bốn giờ, và tối đa 24 đến 48 giờ trong trường hợp xấu nhất. RFC 2308 bổ sung rằng các câu trả lời phủ định được lưu đệm với TTL lấy từ bản ghi SOA của vùng, nên một bản ghi vừa tạo có thể trông như không tồn tại ở một số resolver.
Để bỏ qua bộ nhớ đệm, hỏi máy chủ tên có thẩm quyền: tìm nó bằng dig NS, rồi lặp lại truy vấn với @ và tên của nó, như trong khối lệnh trên. Nếu máy chủ có thẩm quyền hiển thị giá trị mới còn resolver của bạn thì không, hãy chờ. Nếu cả hai đều không, bản ghi chưa được lưu hoặc tên máy chủ sai, thường nhất là vì trình soạn DNS đã thêm tên miền hai lần.
Nếu thư vẫn không đến sau khi các bản ghi trông đúng, hãy đi tới vì sao email không đến tên miền riêng.
Công cụ trực tuyến nào kiểm tra bản ghi email?
Bất kỳ công cụ tra cứu DNS trực tuyến hay công cụ kiểm tra xác thực email nào truy vấn DNS công khai đều cho cùng câu trả lời như dig, với hiển thị thân thiện hơn. Hãy dùng công cụ hiển thị văn bản bản ghi thô, để bạn so sánh từng ký tự với giá trị của nhà cung cấp. Đừng dán dữ liệu riêng tư vào đó: tên miền là tất cả những gì nó cần.
Theo cách Postelva đếm ngày 12 tháng 11 năm 2026, một thiết lập Proton Mail đầy đủ cần 8 bản ghi (1 TXT xác minh, 2 MX, 1 SPF, 3 DKIM, 1 DMARC) và 6 truy vấn, vì hai bản ghi MX dùng chung một truy vấn, và bản ghi xác minh và SPF dùng chung truy vấn TXT ở gốc. Lưu sáu lệnh một lần và chạy lại sau mỗi thay đổi. Các bản ghi tương tự được so sánh trong SPF vs DKIM vs DMARC.
Một quy tắc có thể trích dẫn: sau mỗi thay đổi DNS, truy vấn bốn loại bản ghi và gửi một thư thử; một bản ghi chỉ đúng khi tra cứu và thư khớp nhau.
Câu hỏi về kiểm tra bản ghi email
Vì sao dig in giá trị TXT trong dấu ngoặc kép?
Dấu ngoặc kép đánh dấu ranh giới của các chuỗi TXT. Một giá trị dài hơn 255 ký tự xuất hiện như nhiều chuỗi trong ngoặc, và người nhận nối chúng lại mà không có khoảng trắng.
dig có chạy trên Windows không?
Chỉ khi bạn cài bộ công cụ BIND. Windows có sẵn nslookup, và PowerShell có Resolve-DnsName, cả hai đều đọc cùng các bản ghi.
Làm sao xem kết quả SPF, DKIM và DMARC của một thư thật?
Mở header đầy đủ của một thư đã nhận. Máy chủ nhận ghi kết quả SPF, DKIM và DMARC của nó vào header, thường là pass hoặc fail.
Tôi nên chờ bao lâu trước khi kết luận một bản ghi sai?
Hãy chờ ít nhất TTL mà bản ghi cũ có, rồi truy vấn máy chủ tên có thẩm quyền. Nếu máy chủ đó hiển thị giá trị sai, bản ghi cần được sửa.
Tôi có thể kiểm tra bản ghi của một tên miền không phải của mình không?
Có. Bản ghi DNS là công khai, và một tra cứu chỉ cần tên.
Tóm lại
- MX: dig MX example.com +short; so sánh độ ưu tiên và máy chủ với nhà cung cấp của bạn.
- SPF: dig TXT example.com +short; đúng một dòng bắt đầu bằng v=spf1, tối đa 10 truy vấn.
- DKIM: dig CNAME selector._domainkey.example.com +short, với selector từ nhà cung cấp của bạn.
- DMARC: dig TXT _dmarc.example.com +short; một dòng bắt đầu bằng v=DMARC1 với p= và rua=.
- Một thiết lập Proton Mail đầy đủ gồm 8 bản ghi và 6 truy vấn.
- Yêu cầu máy chủ tên có thẩm quyền bỏ qua bộ nhớ đệm; một thay đổi mất khoảng TTL cũ để lan rộng.
- Postelva lưu các bản ghi trong DNS miễn phí; một .com tốn 12,49 US$/năm mỗi năm.
Nguồn (7)
- RFC 5321, Simple Mail Transfer Protocol, mục 5.1 — RFC Editor (đọc 2026-11-12)
- RFC 7208, Sender Policy Framework — RFC Editor (đọc 2026-11-12)
- RFC 6376, DKIM Signatures — RFC Editor (đọc 2026-11-12)
- RFC 9989, DMARC — RFC Editor (đọc 2026-11-12)
- RFC 2308, Negative Caching of DNS Queries — RFC Editor (đọc 2026-11-12)
- DNS mất bao lâu để thay đổi bản ghi lan truyền — Suped (đọc 2026-11-12)
- Tên miền riêng và chống giả mạo — Proton (đọc 2026-11-12)