DNS Security và Email Authentication là gì? Hướng dẫn DNSSEC, DoH, DoT, SPF, DKIM, DMARC và CAA

Ảnh raster/preview đã được kiểm tra hiển thị trước khi đưa vào file Markdown, dùng minh họa cho DNS authoritative/recursive server. Không dùng SVG.¹

Ảnh raster/preview đã được kiểm tra hiển thị trước khi đưa vào file Markdown, dùng minh họa cho DMARC/email authentication. Không dùng SVG.²

Ảnh raster/preview đã được kiểm tra hiển thị trước khi đưa vào file Markdown, dùng minh họa cho kiểm tra tiêu chuẩn Internet như DNSSEC, HTTPS và email security. Không dùng SVG.³

Tóm tắt nhanh

DNS Security là tập hợp các biện pháp bảo vệ hệ thống tên miền khỏi giả mạo, chiếm quyền, cấu hình sai, rò rỉ thông tin và tấn công vào quá trình phân giải tên miền. Các thành phần quan trọng gồm DNSSEC, DNS provider bảo mật, registrar lock, CAA record, kiểm soát zone file, audit log, DNS monitoring, DoH/DoT cho resolver và quy trình thay đổi DNS an toàn.

Email Authentication là tập hợp các cơ chế xác thực email gửi từ domain của bạn. Ba cơ chế cốt lõi là SPF, DKIM và DMARC. SPF xác định máy chủ nào được phép gửi email cho domain; DKIM ký email bằng khóa mật mã; DMARC kết hợp SPF/DKIM với alignment và policy để hướng dẫn mail receiver xử lý email không đạt xác thực.

Cloudflare mô tả DNSSEC là cơ chế thêm chữ ký mật mã vào DNS records để resolver có thể xác minh bản ghi DNS đến từ authoritative name server và không bị sửa trên đường truyền.⁴ RFC 7208 định nghĩa SPF như cơ chế cho phép domain owner công bố host nào được phép dùng domain trong email.⁵ RFC 6376 định nghĩa DKIM signatures.⁶ RFC 7489 định nghĩa DMARC.⁷

Nói ngắn gọn: DNS Security bảo vệ cách người dùng tìm đến domain của bạn; Email Authentication bảo vệ việc người khác giả mạo email từ domain của bạn.

Vì sao DNS và email là bề mặt tấn công lớn?

Domain là tài sản nền tảng. Nếu attacker kiểm soát DNS hoặc giả mạo email từ domain của bạn, họ có thể:

• chuyển website sang IP độc hại;
• tạo subdomain phishing;
• đổi MX để nhận email nội bộ;
• xin certificate trái phép nếu CAA yếu;
• gửi email giả mạo CEO/support/billing;
• lừa khách hàng thanh toán sai;
• bypass một số luồng xác minh qua email;
• làm hỏng reputation domain;
• gây downtime khi bản ghi DNS bị xóa hoặc sai;
• khai thác API hoặc SaaS dựa trên domain ownership.

Một hệ thống bảo mật tốt cần bảo vệ cả DNS control plane và email identity của domain.

DNS Security không phải là gì?

Email Authentication không phải là gì?

Email authentication không làm email của bạn “không bao giờ vào spam”. Nó giúp receiver xác minh email có thật sự được gửi thay mặt domain của bạn hay không.

DNSSEC là gì?

DNSSEC là phần mở rộng bảo mật cho DNS. DNSSEC không mã hóa DNS query/response; nó ký dữ liệu DNS để resolver có thể phát hiện bản ghi giả mạo hoặc bị sửa.

Cloudflare giải thích rằng DNSSEC thêm digital signatures vào DNS records; khi kiểm tra chữ ký, resolver có thể xác minh DNS record đến từ authoritative name server và không bị sửa trên đường truyền.⁴

Các record quan trọng:

DNSSEC hoạt động thế nào?

Mô hình đơn giản:

Root zone
  ↓ ký/ủy quyền tin cậy
TLD zone (.com, .vn, ...)
  ↓ DS record
Domain zone (example.com)
  ↓ DNSKEY + RRSIG
DNS record thật

Resolver kiểm tra chain of trust từ root xuống domain. Nếu chữ ký hợp lệ, response được tin cậy. Nếu chain bị đứt hoặc chữ ký sai, resolver có thể từ chối response.

DNSSEC giúp chống:

• DNS spoofing;
• cache poisoning;
• man-in-the-middle sửa DNS response;
• một số kiểu giả mạo DNS trên đường truyền.

DNSSEC không chống:

• registrar account bị chiếm;
• DNS provider bị compromise;
• admin cấu hình sai;
• domain hết hạn;
• malware đổi resolver local;
• phishing bằng domain tương tự.

DoH và DoT là gì?

DoH là DNS over HTTPS, được định nghĩa trong RFC 8484.⁸ DoT là DNS over TLS, được định nghĩa trong RFC 7858.⁹

Điểm quan trọng:

• DNSSEC bảo vệ tính toàn vẹn và xác thực của dữ liệu.
• DoH/DoT bảo vệ đường truyền giữa client và resolver khỏi nghe lén/sửa đổi ở đoạn đó.
• DNSSEC và DoH/DoT bổ sung nhau, không thay thế hoàn toàn cho nhau.

CAA record là gì?

CAA là DNS record cho phép domain owner chỉ định Certificate Authority nào được phép cấp certificate cho domain. RFC 8659 định nghĩa DNS CAA Resource Record.¹⁰

Ví dụ:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

Ý nghĩa:

• issue: CA được phép cấp certificate thường.
• issuewild: CA được phép cấp wildcard certificate.
• iodef: nơi nhận báo cáo vi phạm.

CAA không thay thế quản lý TLS certificate, nhưng giảm rủi ro CA không mong muốn cấp certificate cho domain.

SPF là gì?

SPF cho phép domain owner công bố danh sách server được phép gửi email thay mặt domain. RFC 7208 mô tả SPF là giao thức để Administrative Management Domains cho phép rõ host nào được dùng domain name của họ trong email và receiver có thể kiểm tra authorization đó.⁵

Ví dụ:

example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Cách hiểu:

Sai lầm phổ biến:

• quá nhiều DNS lookup vượt giới hạn;
• dùng +all;
• quên SaaS gửi mail như CRM, billing, helpdesk;
• SPF pass nhưng DMARC fail vì không aligned;
• SPF record trùng nhiều TXT;
• để ~all mãi mà không tiến tới policy chặt hơn.

DKIM là gì?

DKIM ký email bằng private key ở mail sender; receiver lấy public key từ DNS để xác minh chữ ký. RFC 6376 định nghĩa DKIM signatures.⁶

DKIM record thường nằm ở:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=..."

Trong email header có:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

Ý nghĩa:

Khuyến nghị:

• bật DKIM cho mọi nguồn gửi mail hợp lệ;
• dùng key đủ mạnh;
• rotate DKIM key định kỳ;
• dùng selector riêng cho provider;
• kiểm tra DKIM alignment với domain From;
• không dùng chung key cho mọi hệ thống nếu có thể.

DMARC là gì?

DMARC dùng SPF/DKIM + alignment để xác định email có hợp lệ với domain trong header From hay không. RFC 7489 định nghĩa DMARC như cơ chế để domain owner công bố policy trong DNS và yêu cầu receiver báo cáo kết quả xử lý.⁷

DMARC record nằm ở:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Policy chính:

DMARC pass khi:

SPF pass và SPF domain aligned với Header From
hoặc
DKIM pass và DKIM d= domain aligned với Header From

Alignment là điểm nhiều người bỏ sót. Email có thể SPF pass nhưng DMARC fail nếu domain không aligned với From.

SPF, DKIM, DMARC phối hợp ra sao?

Email đến receiver
  ↓
SPF: server gửi có được domain cho phép không?
  ↓
DKIM: chữ ký email có hợp lệ không?
  ↓
DMARC: SPF/DKIM có aligned với Header From không?
  ↓
Áp policy: none / quarantine / reject
  ↓
Gửi aggregate report về domain owner

Cấu hình đúng nên có cả SPF và DKIM. DMARC cần ít nhất một trong hai cơ chế pass và aligned.

MTA-STS và TLS-RPT

MTA-STS giúp domain công bố policy yêu cầu mail server nhận email qua TLS, giảm rủi ro downgrade hoặc MITM trong SMTP delivery. RFC 8461 định nghĩa SMTP MTA Strict Transport Security.¹¹

TLS-RPT cho phép domain nhận báo cáo lỗi TLS khi mail delivery không đạt policy. RFC 8460 định nghĩa SMTP TLS Reporting.¹²

Ví dụ DNS record MTA-STS:

_mta-sts.example.com. TXT "v=STSv1; id=20260605"

Policy file được host qua HTTPS:

https://mta-sts.example.com/.well-known/mta-sts.txt

Ví dụ TLS-RPT:

_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Domain không gửi email thì làm gì?

Nếu domain hoặc subdomain không gửi email, vẫn nên cấu hình để chống spoofing.

Ví dụ:

example.com. TXT "v=spf1 -all"
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
*._domainkey.example.com. TXT "v=DKIM1; p="

Với subdomain không gửi mail:

_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject"

sp=reject áp policy cho subdomain nếu subdomain không có DMARC riêng.

Checklist bảo vệ DNS

Registrar

• bật MFA/passkey cho tài khoản registrar;
• dùng registry lock/domain lock nếu có;
• bật auto-renew domain;
• dùng email admin bảo mật;
• hạn chế người có quyền transfer;
• bật cảnh báo thay đổi domain;
• kiểm tra expiry date;
• lưu recovery codes an toàn.

DNS provider

• MFA/SSO;
• RBAC theo vai trò;
• audit logs;
• change review;
• backup/export zone file;
• cảnh báo thay đổi NS/MX/TXT/CAA;
• hạn chế API token;
• token có scope tối thiểu;
• không dùng chung API token giữa hệ thống.

DNS records

• bật DNSSEC nếu provider/registrar hỗ trợ tốt;
• cấu hình CAA;
• kiểm tra MX hợp lệ;
• xóa record cũ;
• giảm wildcard nguy hiểm;
• kiểm tra subdomain takeover;
• giám sát record quan trọng;
• document owner của từng record.

Checklist email authentication

SPF

• chỉ có một SPF TXT record cho domain;
• không dùng +all;
• kiểm tra 10-DNS-lookup limit;
• include đúng provider gửi mail;
• dùng -all khi đã chắc chắn;
• kiểm tra SPF alignment với DMARC.

DKIM

• bật DKIM cho từng mail provider;
• selector riêng theo provider;
• key đủ mạnh;
• rotate key;
• kiểm tra DKIM pass;
• kiểm tra DKIM alignment.

DMARC

• bắt đầu với p=none;
• thu thập report ít nhất vài tuần;
• xác định nguồn gửi hợp lệ;
• sửa SPF/DKIM/alignment;
• chuyển dần pct=..., p=quarantine, rồi p=reject;
• dùng sp= cho subdomain;
• theo dõi report liên tục.

MTA-STS/TLS-RPT

• bật TLS đúng trên MX;
• publish MTA-STS policy;
• bật TLS-RPT;
• monitor lỗi delivery;
• không bật enforce khi chưa test.

Lộ trình triển khai 30/60/90 ngày

Ngày 1–30: kiểm kê và monitor

• Kiểm kê domain/subdomain.
• Kiểm tra registrar lock và MFA.
• Kiểm kê DNS provider/API token.
• Export zone file.
• Kiểm tra MX, SPF, DKIM, DMARC hiện tại.
• Tạo DMARC p=none.
• Tạo mailbox nhận DMARC report.
• Cấu hình CAA cơ bản.
• Kiểm tra domain không gửi mail.
• Thiết lập cảnh báo thay đổi DNS quan trọng.

Ngày 31–60: sửa nguồn gửi và tăng policy

• Xác định mọi nguồn gửi email: Google Workspace, Microsoft 365, SendGrid, Mailgun, CRM, billing, helpdesk.
• Bật DKIM cho từng nguồn.
• Sửa SPF include.
• Loại bỏ nguồn gửi cũ.
• Kiểm tra DMARC alignment.
• Chuyển DMARC sang p=quarantine với pct thấp.
• Bật DNSSEC cho domain ít rủi ro trước.
• Test resolver validation.
• Tạo runbook rollback DNSSEC/DMARC.

Ngày 61–90: enforce và vận hành

• Chuyển domain chính sang p=reject khi report sạch.
• Áp sp=reject cho subdomain nếu phù hợp.
• Bật MTA-STS/TLS-RPT.
• Rotate DKIM key theo lịch.
• Kiểm tra CAA nâng cao.
• Audit API token DNS.
• Tạo dashboard DMARC.
• Kiểm tra subdomain takeover định kỳ.
• Diễn tập sự cố: domain hijack, MX bị đổi, spoofing campaign.
• Ghi ownership cho từng domain.

Sai lầm phổ biến

• Đặt DMARC p=reject ngay khi chưa xem report.
• Quên SaaS đang gửi email thay domain.
• SPF record có quá nhiều DNS lookup.
• Dùng include bừa bãi.
• DKIM pass nhưng không aligned với From domain.
• Không cấu hình DKIM cho marketing/helpdesk.
• Chỉ bảo vệ domain chính, bỏ qua subdomain.
• Không cấu hình domain không gửi email.
• Không bật MFA cho registrar.
• Không bật auto-renew domain.
• Không có CAA.
• Bật DNSSEC nhưng DS record sai làm domain lỗi phân giải.
• Không monitor thay đổi MX/TXT/NS.
• Log report nhưng không ai đọc.

Ví dụ bản ghi DNS

SPF cho Google Workspace và SendGrid

example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

DKIM selector

google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

DMARC monitor

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

DMARC reject

_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"

CAA

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:[email protected]"

MTA-STS và TLS-RPT

_mta-sts.example.com. TXT "v=STSv1; id=20260605"
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Tooling tham khảo

FAQ

DNS Security là gì?

DNS Security là tập hợp các biện pháp bảo vệ domain, DNS zone, DNS records, registrar, resolver và quy trình thay đổi DNS khỏi giả mạo, chiếm quyền và cấu hình sai.

DNSSEC có mã hóa DNS không?

Không. DNSSEC ký dữ liệu DNS để xác minh tính toàn vẹn và nguồn gốc. Nó không mã hóa nội dung DNS query/response. DoH/DoT mới tập trung vào mã hóa đường truyền giữa client và resolver.⁴⁸⁹

SPF, DKIM, DMARC khác nhau thế nào?

SPF xác minh server gửi có được domain cho phép không; DKIM xác minh chữ ký email; DMARC kiểm tra alignment với domain trong From và áp policy xử lý email fail.⁵⁶⁷

Có cần cả SPF, DKIM và DMARC không?

Có. Nên bật cả ba. SPF hoặc DKIM có thể giúp DMARC pass nếu aligned, nhưng triển khai cả SPF và DKIM giúp tăng khả năng xác thực hợp lệ qua nhiều luồng gửi.

DMARC nên bắt đầu bằng policy nào?

Thường bắt đầu bằng p=none để thu thập report, sau đó sửa nguồn gửi, rồi chuyển dần sang quarantine và reject.

Domain không gửi email có cần DMARC không?

Có. Domain không gửi email nên đặt SPF -all và DMARC p=reject để giảm rủi ro bị giả mạo.

Kết luận

DNS Security và Email Authentication là hai lớp bảo vệ domain rất quan trọng nhưng thường bị xem nhẹ. DNS quyết định người dùng và hệ thống đi tới đâu; email authentication quyết định receiver có thể tin email từ domain của bạn hay không. Một cấu hình sai ở NS, MX, TXT, CAA, SPF, DKIM hoặc DMARC đều có thể dẫn tới downtime, phishing, spoofing hoặc mất uy tín domain.

Cách triển khai đúng là bắt đầu bằng kiểm kê domain, bật MFA/lock cho registrar, giám sát DNS records quan trọng, cấu hình CAA, bật DNSSEC có kiểm soát, triển khai SPF/DKIM/DMARC theo lộ trình và theo dõi report liên tục. Với email, không nên nhảy thẳng tới p=reject nếu chưa biết tất cả nguồn gửi hợp lệ. Với DNS, không nên bật DNSSEC nếu chưa có runbook xử lý DS/key rollover. Làm cẩn thận, hai lớp này sẽ giảm mạnh rủi ro domain spoofing, DNS tampering và email phishing.

Nguồn tham khảo

Footnotes

1. GitHub Open Graph preview image for PowerDNS/pdns. https://opengraph.githubassets.com/dns-security-guide/PowerDNS/pdns ↩

2. GitHub Open Graph preview image for trusted-domain-project/OpenDMARC. https://opengraph.githubassets.com/dns-security-guide/trusted-domain-project/OpenDMARC ↩

3. GitHub Open Graph preview image for internetstandards/Internet.nl. https://opengraph.githubassets.com/dns-security-guide/internetstandards/Internet.nl ↩

4. Cloudflare Learning Center. “How does DNSSEC work?” https://www.cloudflare.com/learning/dns/dnssec/how-dnssec-works/ ↩ ↩² ↩³

5. RFC 7208. “Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1.” https://datatracker.ietf.org/doc/html/rfc7208 ↩ ↩² ↩³

6. RFC 6376. “DomainKeys Identified Mail (DKIM) Signatures.” https://datatracker.ietf.org/doc/html/rfc6376 ↩ ↩² ↩³

7. RFC 7489. “Domain-based Message Authentication, Reporting, and Conformance (DMARC).” https://datatracker.ietf.org/doc/html/rfc7489 ↩ ↩² ↩³

8. RFC 8484. “DNS Queries over HTTPS.” https://datatracker.ietf.org/doc/html/rfc8484 ↩ ↩²

9. RFC 7858. “Specification for DNS over Transport Layer Security.” https://datatracker.ietf.org/doc/html/rfc7858 ↩ ↩²

10. RFC 8659. “DNS Certification Authority Authorization (CAA) Resource Record.” https://datatracker.ietf.org/doc/html/rfc8659 ↩

11. RFC 8461. “SMTP MTA Strict Transport Security (MTA-STS).” https://datatracker.ietf.org/doc/html/rfc8461 ↩

12. RFC 8460. “SMTP TLS Reporting.” https://datatracker.ietf.org/doc/html/rfc8460 ↩