Giải thích về Xác thực Email

Email Concepts Encyclopedia Published March 2026

ELI5: Hãy tưởng tượng bạn nhận được một lá thư tuyên bố là từ ngân hàng của bạn. SPF giống như kiểm tra xem lá thư có được gửi từ một địa chỉ mà ngân hàng của bạn thực sự sử dụng hay không. DKIM giống như một con dấu chống giả mạo — nếu bất kỳ ai thay đổi lá thư trong quá trình vận chuyển, con dấu sẽ bị phá vỡ. DMARC là chính sách mà ngân hàng của bạn công bố nói rằng "nếu một lá thư không vượt qua cả hai kiểm tra, hãy vứt nó đi." ARC là chuỗi giám sát khi thư đi qua các trung gian như dịch vụ chuyển tiếp.

SPF, DKIM, DMARC và ARC hoạt động cùng nhau như thế nào như một hệ thống — và những gì xảy ra từng bước khi một tin nhắn đến máy chủ nhận.

Tại Sao Email Cần Xác Thực

SMTP được thiết kế vào những năm 1980 mà không có xác minh người gửi tích hợp sẵn. Bất kỳ máy chủ nào cũng có thể kết nối với bất kỳ máy chủ nào khác và tuyên bố gửi mail từ bất kỳ địa chỉ nào. Đây không phải một lỗi — nó là cách giao thức được xây dựng.

Xác thực email là một tập hợp các tiêu chuẩn được xếp lớp trên SMTP để trả lời ba câu hỏi:

SPF: Máy chủ này có được phép gửi mail cho miền này không?
DKIM: Tin nhắn này thực sự được gửi bởi miền được tuyên bố và không được sửa đổi?
DMARC: Tôi nên làm gì nếu SPF và DKIM đều thất bại — và kết quả nào phù hợp với tiêu đề From:?

Mỗi cơ chế giải quyết một bề mặt tấn công khác nhau. Cùng nhau, chúng tạo thành một hệ thống phòng thủ nhiều lớp.

SPF: Ai Được Phép Gửi

SPF (Sender Policy Framework, RFC 7208) cho phép một miền công bố danh sách các máy chủ được phép gửi mail thay mặt nó. Đó là một bản ghi DNS TXT:

example.com. IN TXT "v=spf1 include:_spf.mailertogo.com ip4:198.51.100.0/24 -all"

Khi một tin nhắn đến, máy chủ nhận trích xuất miền từ MAIL FROM (người gửi bao lì bì) và truy vấn DNS cho bản ghi SPF. Nó kiểm tra xem địa chỉ IP của máy chủ kết nối có phù hợp với bất kỳ cơ chế nào được phép hay không.

Kết quả đánh giá SPF:

pass — IP được phép rõ ràng
fail — IP không được phép rõ ràng (-all)
softfail — IP có thể không được phép (~all) — chấp nhận nhưng đánh dấu
neutral — Miền không có khẳng định về IP này (?all)
temperror / permerror — Tra cứu DNS thất bại hoặc bản ghi bị lỗi

Hạn chế của SPF

SPF xác thực người gửi bao lì bì, không phải tiêu đề From: mà người dùng nhìn thấy. Một kẻ lừa có thể vượt qua SPF bằng cách sử dụng miền riêng của họ trong bao lì bì trong khi giả mạo miền của bạn trong tiêu đề From:. SPF cũng bị hỏng khi mail được chuyển tiếp, vì IP của máy chủ chuyển tiếp không nằm trong bản ghi SPF của miền ban đầu. Những hạn chế này là lý do tại sao SPF một mình là không đủ.

DKIM: Ký Thư Mật Mã

DKIM (DomainKeys Identified Mail, RFC 6376) thêm một chữ ký số vào tin nhắn. Máy chủ gửi ký các tiêu đề được chọn và phần thân bằng khóa riêng. Khóa công khai tương ứng được công bố trong DNS:

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Chữ ký được thêm vào dưới dạng tiêu đề DKIM-Signature:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector;
c=relaxed/relaxed; q=dns/txt;
h=from:to:subject:date:message-id:mime-version:content-type;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yA...

Các trường DKIM-Signature quan trọng:

d= — Miền ký (đây là những gì DMARC kiểm tra để căn chỉnh)
s= — Bộ chọn, được sử dụng để tra cứu khóa công khai trong DNS
h= — Tiêu đề nào được đưa vào chữ ký
bh= — Băm của phần thân tin nhắn
b= — Chữ ký thực tế
c= — Thuật toán chuẩn hóa (relaxed/relaxed là tiêu chuẩn — chịu đựng những thay đổi khoảng trắng nhỏ)

Máy chủ nhận tìm nạp khóa công khai từ DNS, tính toán lại băm trên các tiêu đề và phần thân được ký, và xác minh chữ ký. Nếu nó khớp, tin nhắn đã được ký bởi ai đó có quyền truy cập vào khóa riêng cho miền đó, và nội dung được ký không bị thay đổi.

Hạn chế của DKIM

DKIM vượt qua chuyển tiếp (không giống SPF) vì chữ ký đi kèm với tin nhắn. Tuy nhiên, danh sách gửi thư sửa đổi Chủ đề hoặc phần thân sẽ phá vỡ chữ ký. DKIM cũng không cho người nhận biết phải làm gì với chữ ký thất bại — đó là công việc của DMARC.

DMARC: Lớp Chính Sách

DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) liên kết SPF và DKIM lại với nhau và thêm một chính sách. Nó được công bố dưới dạng bản ghi DNS TXT trên _dmarc.example.com:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"

DMARC giới thiệu khái niệm quan trọng của căn chỉnh — miền trong kết quả xác thực phải khớp với miền trong tiêu đề From: mà người dùng nhìn thấy:

Căn chỉnh SPF: Miền trong MAIL FROM phải khớp (hoặc là miền con của) miền tiêu đề From:, VÀ SPF phải pass.
Căn chỉnh DKIM: Miền d= trong chữ ký DKIM hợp lệ phải khớp (hoặc là miền con của) miền tiêu đề From:.

Một tin nhắn vượt qua DMARC nếu SPF hoặc DKIM pass với căn chỉnh. Cả hai có thể thất bại riêng lẻ miễn là một cái thành công với căn chỉnh.

Chính sách DMARC

p=none — Chỉ giám sát. Không thực hiện hành động khi thất bại. Sử dụng điều này trong khi triển khai.
p=quarantine — Coi các lỗi là đáng ngờ (thường định tuyến đến thư rác).
p=reject — Từ chối tin nhắn thất bại DMARC. Đây là mục tiêu.

Thẻ rua= chỉ định nơi gửi báo cáo tổng hợp — báo cáo XML hiển thị kết quả xác thực cho tất cả tin nhắn tuyên bố từ miền của bạn. Những báo cáo này rất cần thiết để hiểu hệ sinh thái email của bạn trước khi siết chặt chính sách.

Điều Gì Xảy Ra Khi Một Tin Nhắn Đến

Đây là toàn bộ chuỗi xác thực, từng bước, khi mx.receiver.com nhận một tin nhắn tuyên bố từ alice@example.com:

Kết nối: Máy chủ gửi kết nối từ IP 198.51.100.42 và gửi MAIL FROM:<bounce-123@sender.example.com>.
Kiểm tra SPF: Máy nhận truy vấn sender.example.com cho bản ghi SPF của nó. IP 198.51.100.42 được liệt kê → SPF pass. Nhưng miền bao lì bì là sender.example.com, và tiêu đề From: nói example.com — chúng không khớp, vì vậy không có căn chỉnh SPF.
Tin nhắn nhận: Giai đoạn DATA cung cấp tiêu đề và phần thân.
Kiểm tra DKIM: Máy nhận tìm thấy tiêu đề DKIM-Signature với d=example.com; s=mtg. Nó tìm nạp khóa công khai từ mtg._domainkey.example.com, xác minh chữ ký → DKIM pass. Miền d= khớp với tiêu đề From: → DKIM căn chỉnh.
Kiểm tra DMARC: Máy nhận tìm nạp _dmarc.example.com. Chính sách là p=reject. SPF pass nhưng không căn chỉnh. DKIM pass và CÓ căn chỉnh. Ít nhất một cơ chế pass với căn chỉnh → DMARC pass.
Authentication-Results: Máy nhận ghi lại kết quả trong tiêu đề:

Authentication-Results: mx.receiver.com;
spf=pass (sender SPF authorized) smtp.mailfrom=sender.example.com;
dkim=pass header.d=example.com header.s=mtg;
dmarc=pass (policy=reject) header.from=example.com

Tiêu đề này (RFC 8601) được thêm bởi máy chủ nhận và là bản ghi chính thức của kết quả xác thực cho hop đó.

ARC: Bảo Toàn Xác Thực Qua Chuyển Tiếp

ARC (Authenticated Received Chain, RFC 8617) giải quyết vấn đề chuyển tiếp. Khi một tin nhắn đi qua một trung gian (như danh sách gửi thư hoặc dịch vụ chuyển tiếp), SPF bị hỏng (IP của người chuyển tiếp không nằm trong bản ghi SPF ban đầu) và DKIM có thể bị hỏng (nếu danh sách sửa đổi tin nhắn).

ARC hoạt động bằng cách mỗi trung gian ghi lại kết quả xác thực mà nó quan sát trước khi sửa đổi tin nhắn, sau đó ký các kết quả đó. Nó thêm ba tiêu đề trên mỗi hop:

ARC-Authentication-Results (AAR): Kết quả xác thực tại hop này
ARC-Message-Signature (AMS): Chữ ký giống DKIM của tin nhắn khi nó ở hop này
ARC-Seal (AS): Chữ ký trên tất cả các tiêu đề ARC trước đó, kết nối chúng lại với nhau

Mỗi tập hợp tiêu đề được đánh số (i=1, i=2, v.v.), tạo thành một chuỗi. Máy nhận cuối cùng có thể kiểm tra chuỗi để thấy rằng tin nhắn ban đầu pass DMARC tại hop 1, ngay cả khi nó bây giờ thất bại vì một người chuyển tiếp đã sửa đổi nó tại hop 2.

ARC không ghi đè DMARC. Nó cung cấp bằng chứng mà máy nhận cuối cùng có thể chọn để tin tưởng. Việc có danh dự kết quả ARC hay không là tùy theo quyết định của máy nhận.

Cấu Hình Chung: Gửi Qua Bên Thứ Ba

Khi bạn sử dụng dịch vụ email giao dịch như Mailer To Go để gửi mail dưới dạng your-domain.com, bạn cần cấu hình cả ba lớp:

; SPF - phép cấp các IP của dịch vụ
your-domain.com. IN TXT "v=spf1 include:_spf.mailertogo.com -all"

; DKIM - công bố khóa ký của dịch vụ
mtg._domainkey.your-domain.com. IN CNAME mtg._domainkey.mailertogo.com.

; DMARC - đặt chính sách của bạn
_dmarc.your-domain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.com"

Dịch vụ email gửi với miền của bạn trong trường DKIM d=, đảm bảo căn chỉnh DKIM. Chỉ thị SPF include: phép cấp máy chủ của họ. DMARC kết nối nó lại.

Những Gì Có Thể Xảy Ra Sai

SPF quá nhiều tra cứu DNS

SPF có giới hạn cứng 10 tra cứu DNS. Mỗi cơ chế include:, a:, mx: và redirect= tính một tra cứu. Include lồng nhau tính vào tổng số. Nếu bạn vượt quá 10, đánh giá SPF trả về permerror và DMARC coi nó là thất bại. Kiểm toán bản ghi SPF của bạn bằng công cụ trình xác thực.

Lỗi xoay vòng khóa DKIM

Nếu bạn xoay khóa DKIM (công bố khóa công khai mới) trước khi cơ sở hạ tầng gửi của bạn bắt đầu sử dụng khóa riêng mới, tất cả tin nhắn đang bay sẽ thất bại xác minh DKIM. Luôn công bố khóa mới trước, chờ đợi lan truyền DNS, chuyển sang khóa riêng mới, sau đó xóa khóa công khai cũ sau một khoảng thời gian ân hạn.

Sự không khớp căn chỉnh DMARC

SPF của bạn pass và DKIM của bạn pass, nhưng DMARC vẫn thất bại. Điều này xảy ra khi kết quả không căn chỉnh với tiêu đề From:. Ví dụ, SPF xác thực bounces.esp.com (người gửi bao lì bì) nhưng tiêu đề From: nói your-domain.com. Sửa: đảm bảo DKIM ký bằng d=your-domain.com.

Mail được chuyển tiếp bị từ chối

Người dùng chuyển tiếp email old@example.com của họ đến new@gmail.com. Tin nhắn của bạn pass DMARC tại máy chủ ban đầu, nhưng Gmail thấy IP của máy chủ chuyển tiếp (fail SPF) và tin nhắn có thể được sửa đổi (fail DKIM). Với p=reject, bản sao được chuyển tiếp bị từ chối. ARC có thể giúp, nhưng việc áp dụng khác nhau.

Khoảng trống chính sách miền con

Bạn công bố p=reject trên _dmarc.example.com, nhưng kẻ lừa gửi từ billing.example.com, không có bản ghi DMARC. Không có sp=reject (chính sách miền con) trong bản ghi DMARC của bạn, miền con kế thừa chính sách tổ chức — nhưng chỉ khi không có bản ghi riêng. Rõ ràng đặt sp=reject hoặc công bố bản ghi DMARC cho tất cả miền con.

Những Điểm Chính Cần Ghi Nhớ

SPF kiểm tra IP của máy chủ gửi dựa vào DNS. Nó xác thực người gửi bao lì bì, không phải tiêu đề From:.
DKIM ký thư mật mã tin nhắn. Nó vượt qua chuyển tiếp (trừ khi tin nhắn được sửa đổi) và xác thực miền ký.
DMARC yêu cầu SPF hoặc DKIM pass với căn chỉnh với tiêu đề From:. Nó công bố chính sách khi thất bại.
ARC bảo toàn bằng chứng xác thực qua các hop chuyển tiếp.
Bạn cần cả ba (SPF, DKIM, DMARC) được cấu hình đúng. Bất kỳ cái nào một mình có khoảng trống có thể khai thác.
Bắt đầu với p=none, đọc báo cáo tổng hợp DMARC của bạn, sau đó tiến tới p=reject.