27,9% tên miền hàng đầu vẫn dễ bị giả mạo email vào cuối năm 2026

Phân tích gần đây về top 1.000 tên miền trong danh sách Majestic Million cho thấy 27,9% vẫn dễ bị giả mạo email tính đến ngày 19/10/2026. Nghiên cứu chỉ ra rằng mặc dù các nền tảng lớn đã cải thiện tỷ lệ áp dụng, nhiều tổ chức vẫn phụ thuộc vào các bản ghi DNS cho phép, không đủ khả năng chặn email giả mạo.

Chuyện gì đã xảy ra

Cuộc điều tra đã xem xét các bản ghi Domain-based Message Authentication, Reporting, and Conformance (DMARC) của 974 tên miền có thể đăng ký từ danh sách Majestic Million. Bảng xếp hạng này đo lường sự hiện diện trên web toàn cầu dựa trên số lượng backlink. Mục tiêu là xác định xem bao nhiêu tên miền nổi tiếng thực sự ngăn chặn được kẻ tấn công gửi email trông như xuất phát từ họ. Kết quả cho thấy 272 tên miền hoặc không công bố bản ghi DMARC, sử dụng chính sách không bắt buộc, hoặc có cấu hình không hợp lệ.

Mặc dù 72,1% số tên miền được kiểm toán hiện đã áp dụng DMARC, một tỷ lệ đáng kể vẫn còn rủi ro. Trong nhóm áp dụng, 53,1% sử dụng chính sách nghiêm ngặt "reject" (từ chối), yêu cầu máy chủ nhận loại bỏ hoàn toàn các tin nhắn chưa được xác thực. Khoảng 19,0% khác sử dụng "quarantine" (cách ly), thường chuyển các thư đáng ngờ vào thư mục spam. Tuy nhiên, 16,9% vẫn sử dụng "none", chế độ chỉ giám sát cho phép tất cả thư đi qua bất kể trạng thái xác thực, và 11,0% không có bản ghi nào.

Dữ liệu cũng tiết lộ sự chênh lệch dựa trên hạ tầng email. Các tên miền sử dụng nhà cung cấp lưu trữ lớn như Google Workspace hoặc Microsoft 365 có tỷ lệ dễ bị giả mạo thấp hơn, dao động từ 18,1% đến 20,5%. Ngược lại, các tên miền sử dụng giải pháp mail tự host hoặc của bên thứ ba khác có tỷ lệ dễ bị giả mạo lên tới 40,7%. Ngay cả những tên miền không có bản ghi trao đổi mail (MX), về mặt lý thuyết không nhận email, cũng cho thấy tỷ lệ dễ bị giả mạo là 38,2% vì chúng thường thiếu các bản ghi DNS bảo vệ.

Chi tiết quan trọng

• Định nghĩa dễ bị giả mạo: Một tên miền được coi là dễ bị giả mạo nếu chính sách DMARC hiệu lực của nó bị thiếu, đặt thành p=none, hoặc không hợp lệ.
• Khoảng cách giữa các nhà cung cấp: Các nhà cung cấp email tự host hoặc ngách có tỷ lệ dễ bị giả mạo gấp đôi (40,7%) so với các nền tảng lớn như Google (18,1%).
• Tuân thủ vs. Bảo mật: Các nhà cung cấp lớn như Gmail và Yahoo chỉ yêu cầu p=none đối với người gửi khối lượng lớn, nghĩa là tuân thủ quy định không đồng nghĩa với bảo vệ đầy đủ.
• Vấn đề SPF: 15,5% tên miền hoàn toàn thiếu bản ghi SPF, và 1,0% vượt quá giới hạn 10 lần tra cứu DNS, gây ra lỗi xác thực.
• Bảo mật truyền tải: Chỉ 1,5% tên miền áp dụng MTA-STS, một giao thức đảm bảo việc gửi email được mã hóa.
• Tên miền không dùng cho mail: Các tên miền không nhận email nên công bố v=spf1 -all và p=reject để ngăn chặn giả mạo, nhưng nhiều tên miền không làm vậy.

Bối cảnh

DMARC hoạt động kết hợp với SPF (Sender Policy Framework) và DKIM (DomainKeys Identified Mail) để xác minh tính xác thực của email. SPF liệt kê các địa chỉ IP được ủy quyền để gửi thư, trong khi DKIM thêm chữ ký số vào tin nhắn. DMARC liên kết các yếu tố này bằng cách hướng dẫn máy chủ nhận phải làm gì nếu email không vượt qua các bước kiểm tra này. Chính sách p=none chỉ thị cho máy chủ nhận vẫn chuyển tiếp thư nhưng gửi báo cáo cho chủ sở hữu tên miền. Điều này hữu ích cho giai đoạn thiết lập ban đầu nhưng không cung cấp biện pháp bảo vệ chống lại lừa đảo (phishing).

Xu hướng chuyển sang áp dụng nghiêm ngặt hơn được thúc đẩy bởi các yêu cầu mới từ các nhà cung cấp hộp thư lớn. Từ đầu năm 2024, Gmail và Yahoo đã bắt buộc người gửi khối lượng lớn phải công bố bản ghi DMARC, dù ban đầu chấp nhận p=none. Microsoft tiếp theo vào tháng 5/2025 với các quy tắc tương tự cho người dùng Outlook.com. Những quy định này đã thành công trong việc tăng số lượng tên miền công bố bản ghi DMARC, nhưng chưa thúc đẩy phổ biến các tổ chức áp dụng chính sách nghiêm ngặt p=reject cần thiết để ngăn chặn giả mạo.

Tại sao điều này quan trọng

Đối với các đội ngũ quản lý phần mềm và hạ tầng riêng, dữ liệu này nhấn mạnh rủi ro khi chỉ dựa vào cấu hình mặc định hoặc mức tuân thủ tối thiểu. Nếu tổ chức của bạn sử dụng máy chủ email tự host hoặc nhà cung cấp ngách, bạn có nguy cơ cao hơn về mặt thống kê gặp lỗi cấu hình so với các đối thủ trên nền tảng lớn. Kẻ tấn công nhắm vào các tên miền nổi tiếng vì người dùng tin tưởng chúng. Chính sách p=none thực chất mời gọi kẻ lừa đảo giả mạo thương hiệu của bạn, vì máy chủ nhận sẽ không chặn các tin nhắn giả mạo của chúng.

Hơn nữa, tỷ lệ áp dụng thấp các tiêu chuẩn bảo mật truyền tải như MTA-STS cho thấy nhiều tổ chức không bảo vệ email trong quá trình truyền tải khỏi các cuộc tấn công hạ cấp (downgrade attacks). Trong khi DMARC ngăn chặn giả mạo, MTA-STS đảm bảo rằng kết nối giữa các máy chủ mail được mã hóa và không thể bị đánh chặn. Bỏ qua các lớp bảo vệ này khiến cả uy tín và thông tin liên lạc của bạn trở nên dễ tổn thương.

Sự khác biệt giữa tuân thủ và bảo mật là rất quan trọng. Đáp ứng các yêu cầu tối thiểu của Gmail hoặc Yahoo giúp email marketing của bạn không bị đưa vào thư rác, nhưng không bảo vệ tên miền của bạn khỏi lạm dụng. Các lãnh đạo IT phải nhận ra rằng vượt qua bài kiểm tra người gửi khối lượng lớn chỉ là bước đầu tiên trong một chiến lược bảo mật rộng lớn hơn.

Bạn có thể làm gì

• Kiểm toán chính sách DMARC: Kiểm tra xem tên miền của bạn có đang dùng p=none không và lên kế hoạch di chuyển sang p=quarantine và cuối cùng là p=reject.
• Bảo vệ tên miền không dùng cho mail: Đối với bất kỳ tên miền nào không nhận email, hãy công bố v=spf1 -all và p=reject để chặn tất cả thư gửi đi.
• Xem xét bản ghi SPF: Đảm bảo bản ghi SPF của bạn chỉ bao gồm các dịch vụ cần thiết và nằm dưới giới hạn 10 lần tra cứu DNS để tránh lỗi vĩnh viễn.
• Bật báo cáo: Sử dụng thẻ rua trong bản ghi DMARC để nhận báo cáo tổng hợp, giúp bạn xác định các người gửi hợp pháp trước khi áp dụng chính sách nghiêm ngặt.
• Triển khai MTA-STS: Triển khai MTA-STS và TLS-RPT để áp dụng kết nối mã hóa và nhận báo cáo về các thương lượng TLS thất bại.
• Giám sát liên tục: Thường xuyên kiểm tra bản ghi DNS của bạn để phát hiện thay đổi vô tình hoặc hết hạn, đặc biệt nếu bạn quản lý nhiều tên miền con.