Hệ thống xác thực email (SPF, DKIM, DMARC)

1. Tổng quan

Hệ thống xác thực email là tập hợp các công nghệ tiêu chuẩn nhằm kiểm chứng tính hợp lệ của tên miền gửi để lọc bỏ thư của người gửi giả mạo (spoofing), gồm SPF (Sender Policy Framework, RFC 7208) cấp phép IP gửi, DKIM (DomainKeys Identified Mail, RFC 6376) gắn chữ ký số vào thông điệp, và DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) căn chỉnh (alignment) kết quả kiểm chứng của hai công nghệ trên với tên miền gửi (From) rồi gắn với chính sách và báo cáo.

Bối cảnh gốc rễ khiến hệ thống xác thực email trở nên cần thiết nằm ở hạn chế bẩm sinh là bản thân SMTP (Simple Mail Transfer Protocol) không xác minh người gửi. SMTP, được định nghĩa bằng RFC 821 năm 1982, được thiết kế trên tiền đề một mạng nhỏ đáng tin cậy, nên dù người gửi đặt địa chỉ tùy ý vào MAIL FROM và header From thì nó cũng không kiểm tra. Kết quả là bất kỳ ai cũng có thể dễ dàng gửi thư mạo danh tên miền của người khác như From: ceo@mybank.com, và đây trở thành nền tảng kỹ thuật cho phishing, spear phishing và xâm phạm email doanh nghiệp (BEC, Business Email Compromise).

Thiệt hại do BEC đã ở mức nghiêm trọng trong toàn ngành. Báo cáo thường niên của FBI IC3 (Mỹ) ghi nhận tổn thất do BEC ở quy mô hàng tỷ đô la mỗi năm, và tại Hàn Quốc các vụ thư mạo danh chiếm đoạt tiền thanh toán thương mại cũng liên tục xảy ra. Mối đe dọa này khó ngăn chặn chỉ bằng phán đoán thống kê của bộ lọc spam, vì thư mạo danh có ngữ pháp và định dạng giống hệt thư bình thường, đôi khi chỉ yêu cầu thay đổi tài khoản mà không có tệp đính kèm độc hại. Vì vậy, xác thực tên miền gửi — kiểm chứng “thư này có thực sự được gửi từ tên miền đó không” bằng chính sách do chủ sở hữu tên miền công bố và bằng chứng mật mã — đã trở thành bắt buộc. SPF, DKIM, DMARC lần lượt đảm nhận các vai trò bổ trợ lẫn nhau là cấp phép IP, toàn vẹn và chữ ký, chính sách–căn chỉnh–báo cáo, cấu thành một hệ thống tin cậy duy nhất.

2. Luồng xác thực tổng thể và cấu trúc

Xác thực email hoạt động theo mô hình tin cậy phân tán, trong đó phía gửi công bố chính sách và khóa công khai lên DNS, còn máy chủ thư phía nhận tra cứu và kiểm chứng chúng tại thời điểm nhận thư. Sơ đồ khái niệm dưới đây cho thấy toàn bộ cấu trúc từ gửi đến nhận, kiểm chứng và báo cáo.

graph TB
    subgraph SENDER["Tên miền gửi (example.com)"]
      APP["Máy chủ gửi thư/MTA"]
      DNS1["Vùng DNS<br/>SPF TXT, khóa công khai DKIM, chính sách DMARC"]
    end
    APP -->|"Ký bằng khóa riêng DKIM"| MSG["Thông điệp thư"]
    MSG -->|"Truyền SMTP"| RCV
    subgraph RECEIVER["Tên miền nhận (MTA)"]
      RCV["MTA nhận"]
      C1["Kiểm tra SPF<br/>(cấp phép IP MAIL FROM)"]
      C2["Kiểm tra DKIM<br/>(xác minh chữ ký)"]
      C3["Đánh giá DMARC<br/>(căn chỉnh, áp dụng chính sách)"]
    end
    RCV --> C1 --> C3
    RCV --> C2 --> C3
    DNS1 -.Tra cứu TXT.-> C1
    DNS1 -.Tra cứu khóa công khai.-> C2
    DNS1 -.Tra cứu chính sách.-> C3
    C3 -->|"none/quarantine/reject"| DEC["Hộp thư đến, thư rác, chặn"]
    C3 -.Báo cáo tổng hợp, thất bại(RUA/RUF).-> DNS1

Trong luồng này, vai trò của phía gửi và phía nhận được tách biệt rõ ràng. Phía gửi có trách nhiệm ‘khai báo’ qua DNS về IP, khóa ký và chính sách xử lý của các máy chủ gửi do mình kiểm soát, còn phía nhận có trách nhiệm ‘kiểm chứng và thực thi’ khai báo đó theo tiêu chuẩn. Chỉ một phía sẵn sàng thì không có hiệu quả. Dù tên miền gửi công bố chính sách nghiêm ngặt đến đâu, nếu máy chủ nhận không diễn giải và thực thi thì thư mạo danh vẫn được chuyển đến; ngược lại, dù máy chủ nhận cố gắng kiểm chứng nhưng tên miền gửi không có bản ghi thì cũng không có căn cứ phán đoán. Vì thế, xác thực email mang tính chất bảo mật tập thể (collective security), chỉ có năng lực phòng thủ ở cấp hệ sinh thái khi các nhà cung cấp dịch vụ thư và chủ sở hữu tên miền trên toàn thế giới cùng áp dụng tiêu chuẩn chung.

Cốt lõi của cấu trúc này là chủ sở hữu tên miền nắm quyền kiểm soát. Phía gửi chỉ cần công bố chính sách trên DNS của mình, và các máy chủ nhận trên toàn thế giới diễn giải nó theo tiêu chuẩn. Dù không có cơ quan chứng thực trung tâm (CA) riêng, niềm tin vẫn được hình thành trên hạ tầng sẵn có là DNS nên khả năng mở rộng rất tốt. Tuy nhiên, quản lý DNS chính là quản lý bảo mật, nên độ chính xác của bản ghi DNS và sự an toàn trong lưu giữ khóa riêng quyết định niềm tin của toàn bộ hệ thống.

Ba công nghệ khác nhau về đối tượng và phương thức kiểm chứng. SPF xem xét “máy chủ (IP) nào được gửi thay mặt tên miền này”, còn DKIM xem xét “thông điệp có được ký bằng khóa của tên miền đó mà không bị giả mạo, sửa đổi không”. Tuy nhiên, cả hai đều có khoảng trống là không trực tiếp kiểm chứng địa chỉ header From mà người dùng thực sự nhìn thấy, và DMARC ra đời chính là để lấp khoảng trống này.

3. Chi tiết từng thành phần

A. SPF — Cấp phép IP gửi

SPF là phương thức chủ sở hữu tên miền công bố “danh sách IP của các máy chủ được phép gửi thư thay mặt tên miền của tôi” bằng bản ghi DNS TXT. Máy chủ nhận tra cứu bản ghi SPF của tên miền người gửi trên phong bì (envelope sender, MAIL FROM) trong phiên SMTP, rồi đối chiếu xem IP gửi thực sự kết nối có nằm trong danh sách được cấp phép hay không. Ví dụ, v=spf1 include:_spf.google.com ip4:203.0.113.10 -all có nghĩa là cho phép nhóm máy chủ gửi của Google Workspace và một IP cụ thể, còn lại đều từ chối (-all, hard fail). ~all (soft fail) nghĩa là “đáng ngờ nhưng cho qua”, còn ?all (neutral) nghĩa là bảo lưu phán đoán.

Điểm mạnh của SPF là triển khai đơn giản và có thể kiểm soát tường minh hạ tầng máy chủ gửi. Tuy nhiên, nó có hai hạn chế căn bản. Thứ nhất, bị phá vỡ khi chuyển tiếp (forwarding). Khi người dùng tự động chuyển tiếp thư sang địa chỉ khác, IP gửi đổi thành IP của máy chủ chuyển tiếp nên không khớp với SPF của tên miền gốc. Thứ hai, thứ SPF kiểm chứng là người gửi trên phong bì chứ không phải header From mà người dùng nhìn thấy trên màn hình. Kẻ tấn công có thể cho SPF vượt qua bằng tên miền mình kiểm soát, đồng thời chỉ mạo danh header From. Ngoài ra, SPF có giới hạn 10 lần tra cứu DNS, nên nếu lạm dụng include thì xác thực sẽ thất bại với permerror. Trong thực tế, mỗi khi thêm dịch vụ thư SaaS (công cụ marketing, CRM, v.v.) cần làm phẳng (flattening) hoặc dọn dẹp bản ghi để không vượt quá giới hạn này.

Kết quả phán định SPF có ý nghĩa lớn hơn khi được dùng làm đầu vào cho căn chỉnh DMARC thay vì tự mình chặn thư. Ví dụ, dù thư có tên miền người gửi phong bì khác tên miền header From vẫn vượt qua SPF, nếu lệch với tiêu chí căn chỉnh SPF (aspf) của DMARC thì không được công nhận là xác thực thành công. Vì vậy, nên thiết kế sao cho SPF được xem là “công trình nền tảng khai báo tường minh hạ tầng gửi”, còn phán đoán cuối cùng về chặn mạo danh được ủy thác cho DMARC. Góc nhìn này là điểm xuất phát để vận hành ba công nghệ như một hệ thống thống nhất chứ không phải các chức năng riêng lẻ.

B. DKIM — Toàn vẹn dựa trên chữ ký số

DKIM để máy chủ gửi ký bằng khóa riêng lên các header chính và phần thân của thông điệp, đồng thời công bố khóa công khai tương ứng trên DNS để phía nhận kiểm chứng chữ ký. Thông tin chữ ký nằm trong header DKIM-Signature, và dùng selector để tìm khóa công khai (TXT) tại vị trí selector._domainkey.domain. Chữ ký chứa danh sách header được ký (h=), hàm băm phần thân (bh=), giá trị chữ ký (b=), v.v., nên nếu trong quá trình truyền phần thân hoặc header được ký thay đổi dù chỉ một ký tự thì kiểm chứng sẽ thất bại. Tức là DKIM đồng thời cung cấp xác nhận tên miền gửi và tính toàn vẹn của thông điệp.

Yếu tố chi tiết quyết định sự ổn định của ký và kiểm chứng là chuẩn hóa (canonicalization). Trong quá trình chuyển tiếp, thư có thể bị thay đổi nhỏ về khoảng trắng, xuống dòng, gập header (folding), và phương thức chuẩn hóa (tham số c=) quyết định có chấp nhận những biến đổi nhỏ này khi kiểm chứng chữ ký hay không. simple không cho phép bất kỳ biến đổi nào nên nghiêm ngặt nhưng dễ bị ảnh hưởng bởi biến đổi khi chuyển tiếp, còn relaxed hấp thụ các thay đổi vô hại như chuẩn hóa khoảng trắng nên được dùng rộng rãi trong thực tế. Thông thường header chọn relaxed, phần thân cũng chọn relaxed để giảm cảnh báo sai do biến đổi chuyển tiếp hợp lệ, trong khi thay đổi về nội dung thực chất của phần thân vẫn được phát hiện. Như vậy, DKIM dùng chuẩn hóa để cân bằng giữa ‘tính toàn vẹn’ và ‘khả năng chịu đựng chuyển tiếp’.

DKIM tương đối vững trước chuyển tiếp. Vì chữ ký gắn vào chính thông điệp chứ không phải IP, nên chừng nào phần thân và header được ký còn nguyên thì dù đi qua nhiều máy chủ, kiểm chứng vẫn được duy trì. Tuy nhiên, nếu mailing list gắn thẻ [list] vào tiêu đề hoặc thêm chân trang thì chữ ký có thể bị phá vỡ. Điều quan trọng về mặt vận hành là quản lý khóa. Độ dài khóa khuyến nghị tối thiểu 2048 bit (1024 bit là yếu), và để phòng xâm phạm, nên xoay vòng khóa định kỳ bằng selector. Nếu khóa riêng dùng để ký bị lộ, kẻ tấn công có thể giả mạo chữ ký hợp lệ, nên khóa riêng phải được bảo vệ bằng HSM hoặc hệ thống quản lý bí mật.

C. DMARC — Căn chỉnh, chính sách, báo cáo

DMARC là lớp cao hơn, căn chỉnh (alignment) kết quả của SPF, DKIM với tên miền header From, và cho phép chủ sở hữu tên miền chỉ định chính sách xử lý khi thất bại cũng như địa chỉ nhận báo cáo. Căn chỉnh là khái niệm kiểm tra “tên miền dùng để xác thực có khớp với tên miền From mà người dùng nhìn thấy không”, qua đó lấp khoảng trống ‘không kiểm chứng header From’ mà SPF, DKIM để lại. Chế độ căn chỉnh được chia thành nghiêm ngặt (strict) yêu cầu khớp hoàn toàn và nới lỏng (relaxed) cho phép khớp ở cấp tên miền tổ chức.

Ví dụ bản ghi DMARC có dạng v=DMARC1; p=reject; rua=mailto:agg@example.com; ruf=mailto:forensic@example.com; pct=100; adkim=s; aspf=r. Chính sách p chỉ thị cách xử lý thư không có xác thực nào được căn chỉnh thành công, và có ba mức. none chỉ giám sát mà không hành động (dùng để quan sát giai đoạn đầu), quarantine chuyển vào thư rác hoặc cách ly, reject từ chối hoàn toàn. Đến địa chỉ chỉ định bằng rua, máy chủ nhận gửi báo cáo tổng hợp (aggregate report, XML) theo ngày, cho biết IP nào đã gửi bao nhiêu thư dưới tên miền của chúng ta và kết quả xác thực ra sao. Báo cáo này là giá trị thực chất của DMARC. Qua đó, chủ sở hữu tên miền có thể làm hiện rõ cả những nguồn gửi hợp lệ chưa nắm được (shadow IT) lẫn các nỗ lực mạo danh.

Việc triển khai DMARC nhất thiết phải tiến hành theo từng bước. Cách chuẩn mực là bắt đầu với p=none, dùng báo cáo tổng hợp để đưa mọi nguồn gửi hợp lệ vào SPF, DKIM, sau đó nâng dần pct (tỷ lệ áp dụng), đi qua quarantine và cuối cùng đạt p=reject. Nếu vội vàng bắt đầu bằng reject, sẽ xảy ra sự cố các hệ thống hợp lệ chưa kịp đăng ký (thư lương, thông báo, marketing, v.v.) bị chặn hàng loạt.

Dưới đây là lưu đồ thể hiện quy trình đánh giá DMARC của máy chủ nhận.

flowchart TD
    A["Nhận thư"] --> B["Kiểm tra SPF"]
    A --> C["Kiểm tra DKIM"]
    B --> D{"SPF pass và<br/>căn chỉnh với From?"}
    C --> E{"DKIM pass và<br/>căn chỉnh với From?"}
    D -->|"Có"| F["DMARC đạt"]
    E -->|"Có"| F
    D -->|"Không"| G{"Cả hai đều thất bại?"}
    E -->|"Không"| G
    G -->|"Có"| H["Tra cứu chính sách DMARC<br/>áp dụng giá trị p="]
    H --> I["none: chuyển · quarantine: cách ly · reject: từ chối"]
    F --> J["Chuyển phát bình thường"]
    H -.Báo cáo tổng hợp(RUA).-> K["Chủ sở hữu tên miền"]

4. So sánh và quan hệ bổ trợ

Ba công nghệ không phải là vật thay thế mà là vật bổ trợ phân tầng. Chỉ dùng SPF thì dễ tổn thương trước chuyển tiếp và mạo danh header; chỉ dùng DKIM thì không thể bắt buộc bằng chính sách nguồn gửi nào là hợp lệ; còn DMARC không có căn cứ phán đoán nếu thiếu SPF, DKIM. Chỉ khi triển khai cả ba cùng nhau mới đạt được mục tiêu “thư gửi từ tên miền hợp lệ được thông qua, mạo danh bị chặn, nguồn gửi không rõ được làm hiện rõ bằng báo cáo”.

Phân loại	SPF	DKIM	DMARC
Đối tượng kiểm chứng	IP người gửi phong bì (MAIL FROM)	Chữ ký, tính toàn vẹn thông điệp	Căn chỉnh header From, chính sách
Phương thức	Danh sách IP được cấp phép trong DNS TXT	Chữ ký số khóa công khai	Phán định căn chỉnh kết quả SPF/DKIM
Khả năng chịu chuyển tiếp	Yếu (thất bại khi IP đổi)	Mạnh (đạt nếu chữ ký còn nguyên)	Phụ thuộc kết quả tầng dưới
Phòng chống mạo danh	Chỉ tên miền phong bì	Chỉ tên miền ký	Bảo vệ From mà người dùng thấy
Báo cáo	Không	Không	Cung cấp báo cáo tổng hợp, thất bại
Hạn chế chính	Giới hạn 10 lần tra cứu DNS	Bị phá khi list biến đổi	Cần hai công nghệ tầng dưới trước

Hiểu qua một tình huống cụ thể sẽ thấy rõ sự phân công của ba công nghệ. Giả sử kẻ tấn công cấu hình SPF, DKIM bình thường cho tên miền mình kiểm soát là evil.example, rồi chỉ giả mạo header thành From: ceo@mybank.com để gửi thư. Trong trường hợp này, SPF và DKIM đều vượt qua (pass) theo tiêu chí evil.example. Tuy nhiên, DMARC nhận ra rằng tên miền dùng để xác thực (evil.example) và tên miền From mà người dùng thấy (mybank.com) không được căn chỉnh, và từ chối thư này theo chính sách DMARC của mybank.com (p=reject). Ngược lại, với thư gửi hợp lệ thì tên miền xác thực và tên miền From trùng khớp nên căn chỉnh thành lập và thư được chuyển phát bình thường. Như vậy, phải có kiểm tra căn chỉnh của DMARC thì việc phòng thủ đối với ‘người gửi mà người dùng thực sự nhìn thấy’ mới hoàn chỉnh.

Để khắc phục vấn đề xác thực thất bại do chuyển tiếp, ARC (Authenticated Received Chain, RFC 8617) đã được đề xuất. ARC là phương thức mà khi thư đi qua các máy chủ trung gian (mailing list, bộ chuyển tiếp), mỗi điểm chuyển tiếp ký để bảo toàn kết quả xác thực ban đầu, giúp người nhận cuối cùng có thể tin vào chuỗi “thư này bị phá SPF trong quá trình chuyển tiếp nhưng ban đầu là hợp lệ”. Các dịch vụ thư lớn đã áp dụng ARC để giảm cảnh báo sai đối với thư chuyển tiếp.

5. Chuyên sâu — Xu hướng mới và ứng dụng thực tiễn

A. Bắt buộc xác thực đối với người gửi số lượng lớn (2024~)

Từ mốc năm 2024, xác thực email đã chuyển từ ‘khuyến nghị’ sang ‘bắt buộc’ trên thực tế. Từ tháng 2/2024, Google và Yahoo bắt đầu yêu cầu người gửi số lượng lớn gửi từ 5.000 thư mỗi ngày trở lên phải có đủ SPF, DKIM, DMARC, đồng thời bắt buộc cung cấp hủy đăng ký một lần nhấp (one-click unsubscribe, RFC 8058) và duy trì tỷ lệ báo cáo spam dưới 0,3%. Microsoft cũng đang lần lượt áp dụng các yêu cầu tương tự. Điều này có nghĩa là mọi doanh nghiệp xử lý thư marketing và thông báo giao dịch phải chỉnh đốn lại cấu hình xác thực theo từng nguồn gửi, và nếu không thực hiện sẽ dẫn đến tổn thất kinh doanh trực tiếp là tỷ lệ chuyển phát (deliverability) giảm mạnh. Thực tế, nhiều doanh nghiệp thương mại và tài chính đã nhân dịp này chỉnh đốn việc tách tên miền phụ theo từng công cụ CRM, marketing và ủy quyền ký DKIM.

B. BIMI — Logo thương hiệu và trực quan hóa niềm tin

BIMI (Brand Indicators for Message Identification) là đặc tả cho phép hiển thị logo thương hiệu đã được xác minh trong hộp thư đến đối với thư gửi từ các tên miền áp dụng DMARC ở mức quarantine trở lên. Tính hợp lệ của logo được bảo đảm bằng chứng chỉ VMC (Verified Mark Certificate), và gần đây CMC (Common Mark Certificate) có thể cấp mà không cần đăng ký nhãn hiệu cũng đang được đưa vào. BIMI bản thân không hẳn là công nghệ xác thực mà hoạt động như một động lực kinh doanh thúc đẩy áp dụng DMARC. Tức là cấu trúc “muốn hiển thị logo thì trước hết phải làm DMARC cho đúng”, đặc trưng ở chỗ kết nối marketing thương hiệu với bảo mật email.

C. Tình huống triển khai và các lỗi cấu hình thường gặp

Trong thực tế, thành bại của việc triển khai DMARC thường được quyết định bởi ‘đã nhận diện đầy đủ các nguồn gửi hợp lệ đến mức nào’. Các tổ chức lớn, ngoài máy chủ thư của trụ sở, thường có hàng chục nguồn gửi sử dụng tên miền như hệ thống thông báo lương và nhân sự, công cụ tự động hóa marketing, hệ thống ticket helpdesk, bộ gửi biên lai thanh toán. Như trường hợp một doanh nghiệp toàn cầu thu thập báo cáo tổng hợp trong 3 tháng với p=none và phát hiện khoảng 20 hệ thống gửi thư mà nội bộ chưa nắm được, nếu không làm trước công việc kiểm kê nguồn gửi dựa trên báo cáo thì khi chuyển sang reject, thư nghiệp vụ hợp lệ sẽ bị chặn hàng loạt. Thông thường phải mất vài tháng đến 1 năm mới triển khai xong, vì việc sắp xếp có tổ chức ‘ai đang gửi thư bằng tên miền của chúng ta’ tốn thời gian hơn cấu hình kỹ thuật.

Các lỗi cấu hình tiêu biểu gồm: ① lạm dụng SPF include vượt giới hạn 10 lần tra cứu DNS gây permerror; ② đăng ký trùng nhiều bản ghi SPF TXT (chỉ cho phép một) làm vô hiệu hóa kiểm chứng; ③ đặt DMARC ở reject nhưng không chỉ định chính sách tên miền phụ (sp=) khiến tên miền phụ không được bảo vệ; ④ không chỉ định địa chỉ báo cáo (rua) nên hoàn toàn không quan sát được các nỗ lực mạo danh. Những lỗi cấu hình này bề ngoài có vẻ vẫn hoạt động bình thường nên khó chẩn đoán, và chỉ được phát hiện qua kiểm tra trạng thái xác thực định kỳ và giám sát báo cáo.

D. Áp dụng tại Hàn Quốc và liên kết đề thi

Tại Hàn Quốc, khu vực công và tài chính cũng có xu hướng mở rộng triển khai DMARC để ứng phó với thư mạo danh, và từ góc độ bảo vệ thông tin cá nhân và hệ thống quản lý bảo vệ thông tin (ISMS-P), bảo mật thư gắn liền với các hạng mục kiểm soát quản lý và kỹ thuật. Trong kỳ thi Kỹ sư chuyên nghiệp (Professional Engineer), đề thi dễ ra dưới dạng hỏi nguyên lý riêng của SPF, DKIM, DMARC, quan hệ bổ trợ giữa ba công nghệ, chiến lược triển khai từng bước (none→reject), và phương án ứng phó BEC, phishing. Khi viết bài, thay vì liệt kê đơn thuần, nên tổ chức theo mạch nhân quả “hạn chế cấu trúc của SMTP → phân công vai trò của từng công nghệ → hệ thống tin cậy hoàn thiện nhờ căn chỉnh → chiến lược triển khai từng bước” để có lợi cho điểm cao.

6. Lưu ý và hàm ý

• Triển khai từng bước và tận dụng báo cáo (chiến lược áp dụng): DMARC nhất thiết phải bắt đầu bằng p=none, dùng báo cáo tổng hợp để nhận diện và đăng ký mọi nguồn gửi hợp lệ, rồi mới nâng lên quarantine, reject. Phân tích báo cáo thủ công rất khó, nên mấu chốt là có hệ thống vận hành dùng công cụ, dịch vụ phân tích chuyên dụng để liên tục quản lý danh mục nguồn gửi.

• Đánh đổi giữa tính sẵn sàng và bảo mật: p=reject và căn chỉnh nghiêm ngặt (strict) có hiệu quả chặn mạo danh lớn, nhưng có thể chặn cả thư của hệ thống hợp lệ chưa đăng ký, gây gián đoạn nghiệp vụ. Ngược lại, cấu hình nới lỏng an toàn nhưng năng lực phòng thủ yếu. Cần tìm điểm cân bằng phù hợp với mức chấp nhận rủi ro của tổ chức và mức trưởng thành của hạ tầng gửi thư.

• Tầm quan trọng của quản lý khóa và DNS: Lộ khóa riêng DKIM và lỗi bản ghi DNS lần lượt dẫn thẳng tới giả mạo chữ ký và cảnh báo sai hàng loạt. Cần củng cố gốc rễ của niềm tin bằng khóa từ 2048 bit trở lên, xoay vòng selector định kỳ, quản lý cấu hình các thay đổi DNS và song hành DNSSEC.

• Ứng phó môi trường chuyển tiếp và mailing list (công nghệ liên kết): Trong môi trường mailing list và tự động chuyển tiếp, SPF dễ bị phá vỡ, nên cần dùng kết hợp DKIM và ARC, và khi cần nên tách tên miền phụ chuyên dùng để gửi nhằm cô lập và quản lý uy tín (reputation).

• Quản trị và quản lý có tổ chức: Xác thực email không phải là thiết lập kỹ thuật của một bộ phận cụ thể mà là vấn đề quản lý tài sản toàn doanh nghiệp liên quan đến mọi chủ thể gửi thư bằng tên miền như marketing, nhân sự, IT, bảo mật. Nếu không định nghĩa quy trình kiểm soát việc đăng ký, thay đổi nguồn gửi và trách nhiệm (RACI), thì mỗi khi đưa vào SaaS mới, khoảng trống xác thực lại tái diễn.

• Triển vọng: Với việc bắt buộc xác thực đối với người gửi số lượng lớn và sự lan rộng của BIMI, xác thực email đang trở thành hạ tầng bắt buộc chứ không còn là lựa chọn; trong tương lai, để ứng phó với phishing ngày càng tinh vi nhờ AI, dự kiến sẽ phát triển thành phòng thủ đa tầng kết hợp xác thực tên miền gửi với phân tích dựa trên nội dung và hành vi (tình báo mối đe dọa, XDR).

Tài liệu tham khảo

• RFC 7208, Sender Policy Framework (SPF): https://datatracker.ietf.org/doc/html/rfc7208
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures: https://datatracker.ietf.org/doc/html/rfc6376
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC): https://datatracker.ietf.org/doc/html/rfc7489
• RFC 8617, The Authenticated Received Chain (ARC) Protocol: https://datatracker.ietf.org/doc/html/rfc8617
• Google, Email sender guidelines: https://support.google.com/a/answer/81126
• BIMI Group: https://bimigroup.org/

---

Tóm tắt một câu: SPF (cấp phép IP gửi), DKIM (toàn vẹn bằng chữ ký số) và DMARC (căn chỉnh header From, chính sách, báo cáo) là hệ thống xác thực email bổ trợ lẫn nhau, khắc phục theo tầng hạn chế không xác minh người gửi của SMTP để chặn mạo danh, phishing và BEC; triển khai từng bước từ p=none đến reject và quản lý nguồn gửi dựa trên báo cáo là chìa khóa thành công.