Microsoft từ chối email thiếu bản ghi DMARC mà không báo trước

Vào sáng thứ Sáu, ngày 7 tháng 11 năm 2026, các quản trị viên nhận thấy sự gia tăng đột biến số lượng email bị từ chối khi gửi đến các tên miền do Microsoft vận hành như hotmail.com và outlook.com. Thông báo từ chối chỉ ra việc thiếu các bản ghi xác thực, cụ thể là sự vắng mặt của chính sách DMARC mặc dù cấu hình SPF và DKIM đều hợp lệ. Thay đổi không được thông báo trước này đã làm gián đoạn giao tiếp cho nhiều máy chủ email tự lưu trữ (self-hosted) và các doanh nghiệp nhỏ dựa trên thiết lập DNS tiêu chuẩn.

Chuyện gì đã xảy ra

Sự cố lần đầu tiên được phát hiện bởi Mythic Beasts, một nhà cung cấp dịch vụ hosting, sau khi nhật ký hệ thống của họ ghi nhận hơn 500 trường hợp từ chối vào thứ Năm mà trước đó chưa từng xảy ra. Mã lỗi trả về từ máy chủ của Microsoft là 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records. Điều quan trọng là, các tin nhắn bị từ chối đều có bản ghi Sender Policy Framework (SPF) và DomainKeys Identified Mail (DKIM) hoàn toàn hợp lệ. Thành phần duy nhất còn thiếu là bản ghi Domain-based Message Authentication, Reporting, and Conformance (DMARC) trong vùng DNS của tên miền.

Để thử nghiệm cách khắc phục, nhóm kỹ thuật đã thêm một bản ghi DMARC với chính sách đặt thành "none" cho một số tên miền bị ảnh hưởng. Chính sách này thông báo cho máy chủ nhận rằng chủ sở hữu tên miền không có chỉ định cụ thể nào về cách xử lý thư không được xác thực, về cơ bản hoạt động như thể không tồn tại chính sách nào. Ngay khi bản ghi này được công bố, máy chủ của Microsoft lại chấp nhận các email. Một khảo sát rộng rãi hơn trên Fediverse xác nhận rằng các nhà khai thác độc lập khác cũng gặp phải những lỗi tương tự, cho thấy đây là một thay đổi phổ biến trong logic lọc thư inbound của Microsoft chứ không phải là lỗi cấu hình riêng lẻ.

Ban đầu, việc thiếu thông báo dẫn đến suy đoán rằng đây có thể là một nỗ lực siết chặt các tiêu chuẩn bảo mật có chủ đích. Năm ngoái, Microsoft đã đưa ra yêu cầu đối với các tên miền gửi hơn 5.000 tin nhắn mỗi ngày phải công bố bản ghi DMARC, nhưng thay đổi đó đã được thông báo trước rất lâu. Sự thay đổi gần đây dường như áp dụng cho tất cả người gửi bất kể khối lượng và không có cảnh báo trước. Một cập nhật cho báo cáo ban đầu sau đó làm rõ rằng thay đổi này có khả năng là vô ý, tuy nhiên Microsoft vẫn chưa xác định được cách để hoàn tác lỗi cấu hình.

Chi tiết chính

• Thông báo lỗi: Email bị từ chối sẽ trả về mã 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records.
• Dịch vụ bị ảnh hưởng: Việc gửi thư đến hotmail.com và outlook.com bị tác động.
• Nguyên nhân gốc rễ: Thiếu bản ghi DNS DMARC, ngay cả khi SPF và DKIM được cấu hình đúng.
• Khắc phục tạm thời: Công bố một bản ghi DMARC với chính sách p=none giúp khôi phục khả năng gửi thư thành công.
• Phạm vi: Thay đổi dường như ảnh hưởng đến tất cả người gửi, không chỉ những người gửi khối lượng lớn vượt quá 5.000 tin nhắn hàng ngày.
• Trạng thái: Microsoft chưa đưa ra tuyên bố chính thức hoặc lộ trình hoàn tác, mặc dù các nguồn tin nội bộ cho biết thay đổi này là do sơ suất.

Bối cảnh

Xác thực email dựa vào ba giao thức chính để ngăn chặn giả mạo và lừa đảo. SPF liệt kê các địa chỉ IP được ủy quyền gửi email cho một tên miền. DKIM thêm chữ ký số vào mỗi tin nhắn, cho phép máy thu xác minh rằng tin nhắn không bị thay đổi trong quá trình truyền tải. DMARC xây dựng dựa trên hai giao thức này bằng cách chỉ định máy chủ nhận nên làm gì nếu tin nhắn thất bại trong kiểm tra SPF hoặc DKIM. Các chính sách có thể được đặt thành "none" (chỉ giám sát), "quarantine" (chuyển vào spam) hoặc "reject" (chặn hoàn toàn).

Mặc dù DMARC là một thực hành tốt cho bảo mật, nhiều thiết lập tự lưu trữ nhỏ thường bỏ qua nó vì cần theo dõi cẩn thận để đảm bảo thư hợp pháp không bị chặn nhầm. Trong lịch sử, các nhà cung cấp lớn đã triển khai dần các yêu cầu DMARC, thường bắt đầu với những người gửi khối lượng lớn. Việc áp dụng đột ngột yêu cầu phải có DMARC, ngay cả với chính sách thụ động "none", đại diện cho một sự thay đổi đáng kể trong cách các bộ lọc inbound xác thực danh tính người gửi. Nó chuyển DMARC từ một cải tiến bảo mật được khuyến nghị thành một yêu cầu cấu trúc bắt buộc cho việc gửi thư cơ bản.

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

Đối với các đội ngũ chạy phần mềm riêng hoặc quản lý email tự lưu trữ, sự cố này nhấn mạnh tính dễ tổn thương khi phụ thuộc vào các nền tảng bên ngoài với những thay đổi vận hành không minh bạch. Nếu không có thông báo trước, các giao tiếp kinh doanh quan trọng có thể rơi vào "hố đen", không có cách nào chẩn đoán vấn đề ngay lập tức trừ khi theo dõi sát sao nhật ký bounce. Thực tế rằng SPF và DKIM hợp lệ là không đủ cho thấy các yêu cầu tuân thủ đang phát triển nhanh hơn khả năng theo dõi của nhiều nhà khai thác nhỏ.

Hơn nữa, việc không thể liên hệ với Microsoft để hỗ trợ làm trầm trọng thêm vấn đề. Các trưởng nhóm IT và nhà phát triển nhỏ phải dựa vào diễn đàn cộng đồng và phương pháp thử-sai để giải quyết các vấn đề gửi thư. Điều này làm tăng gánh nặng vận hành cho các đội ngũ nhỏ có thể không có chuyên gia riêng về khả năng gửi thư (email deliverability). Nó cũng là lời nhắc nhở rằng các cấu hình DNS kiểu "cài đặt rồi quên đi" (set and forget) là rủi ro khi các nhà nhận lớn thay đổi logic xác thực của họ một cách bất ngờ.

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

• Kiểm tra DNS của bạn: Xác minh xem tên miền của bạn có bản ghi DMARC hay không bằng cách sử dụng các công cụ tra cứu trực tuyến hoặc tiện ích dòng lệnh như dig.
• Thêm bản ghi tạm thời: Nếu thiếu, hãy thêm một bản ghi TXT cho _dmarc.yourdomain.com với giá trị v=DMARC1; p=none; để khôi phục khả năng gửi thư ngay lập tức.
• Theo dõi nhật ký bounce: Xem xét nhật ký máy chủ mail của bạn để tìm các lỗi 550 5.7.1 nhằm xác định bất kỳ tin nhắn nào bị lỡ trong vài ngày qua.
• Xác thực các bản ghi hiện có: Đảm bảo rằng các bản ghi SPF và DKIM của bạn vẫn hợp lệ và phù hợp với hạ tầng mail hiện tại.
• Giao tiếp với người dùng: Nếu bạn biết khách hàng sử dụng email Microsoft, hãy thông báo cho họ về khả năng chậm trễ và yêu cầu họ kiểm tra hộp thư rác.
• Lên kế hoạch cho các chính sách nghiêm ngặt hơn: Sau khi khả năng gửi thư được khôi phục, hãy cân nhắc chuyển từ p=none sang p=quarantine hoặc p=reject sau khi xác minh rằng tất cả các nguồn hợp pháp đều vượt qua xác thực.