Outlook.com âm thầm chặn email từ domain thiếu DMARC

Từ ngày 5/11/2026, dịch vụ email tiêu dùng của Microsoft bắt đầu từ chối một phần thư đến từ các domain không công bố bản ghi DMARC. Nếu doanh nghiệp của bạn gửi email cho khách hàng, đối tác hay ứng viên dùng địa chỉ outlook.com, hotmail.com, live.com hoặc msn.com, một phần thư đó có thể đang bị trả lại ngay lúc này mà không có bất kỳ thông báo chính thức nào. Cách khắc phục chỉ gồm một bản ghi DNS.

Những điểm cần nắm

• Outlook.com, Hotmail, Live và MSN hiện từ chối một phần thư từ các domain không có bản ghi DMARC.
• Lỗi tác động tới cả người gửi thông thường, lưu lượng thấp, chứ không chỉ các nhà gửi hàng loạt mà quy định đã công bố của Microsoft nhắm tới.
• Chỉ một số thư bị trả lại, nên câu "thư của tôi vẫn tới được" không có nghĩa là domain của bạn an toàn.

Thư bị trả lại trông thế nào

Người gửi nhận được thư trả lại dạng như sau, kèm theo tên máy chủ và mã định danh trong ngoặc, khác nhau ở từng thư:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Ngày đầu tiên, cùng lỗi này trả về mà không có mã (AS9031519):

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records

Cách diễn đạt khiến người ta tưởng hệ thống hỏng nặng. Thường thì không phải vậy. Các domain bị trả lại mà chúng tôi quan sát được phần lớn đều có SPF (bản ghi xác thực máy chủ gửi thư) hoạt động, nhiều domain còn có cả DKIM (chữ ký số cho thư). Thứ còn thiếu là bản ghi DMARC, vốn dùng để gắn hai cơ chế trên với địa chỉ trong trường From.

Điều gì đã thay đổi

Microsoft thực tế đã có quy định dành cho người gửi. Từ tháng 5/2025, các domain gửi hơn 5.000 thư mỗi ngày tới Outlook.com buộc phải vượt qua SPF, DKIM và DMARC, nếu không sẽ nhận mã 550 5.7.515 Access denied. Quy định đó nhắm vào các nhà tiếp thị và người gửi hàng loạt, nên phần lớn doanh nghiệp nhỏ đương nhiên nghĩ mình không bị ảnh hưởng.

Lỗi từ chối mới này khác ở những điểm quan trọng:

• Nó chạm tới cả người gửi nhỏ. Một thư trả lời dài một dòng từ văn phòng nhỏ cũng có thể bị trả lại.
• Nó không được công bố. Tính đến ngày 6/11, Microsoft chưa đăng thông tin nào về việc này: không có thông báo postmaster, không có bài blog, không có mục tình trạng dịch vụ.
• Nó không cho biết cụ thể cái gì đã hỏng. Thư trả lại 5.7.515 liệt kê kết quả SPF, DKIM và DMARC, còn lỗi này chỉ nói rằng thiếu bản ghi.

Những thư trả lại này lần đầu xuất hiện trong nhật ký gửi thư ra của chính chúng tôi vào ngày 5/11. Báo cáo công khai từ các quản trị viên khác cũng bắt đầu xuất hiện cùng ngày.

Vì sao khó phát hiện

Microsoft chỉ từ chối một phần thư từ domain bị ảnh hưởng. Một thư tới địa chỉ Hotmail đi qua được, thư kế tiếp bị trả lại, gửi lại có thể thành công. Chính sự thiếu nhất quán này khiến nó nguy hiểm: người gửi thấy thư trả lại đầy chữ viết tắt, cho rằng đó là lỗi tạm thời rồi bỏ qua. Khách hàng ở đầu bên kia không hề biết đã có thư được gửi tới.

Nếu doanh nghiệp của bạn phụ thuộc vào việc liên lạc với người dùng địa chỉ email cá nhân (bệnh nhân, chủ nhà, ứng viên, phụ huynh, hội viên), chi phí rất âm thầm: hóa đơn không tới, xác nhận lịch hẹn không đến, thư trả lời khiến người nhận tưởng bạn phớt lờ họ.

Domain của bạn có bị ảnh hưởng?

Domain của bạn nằm trong vùng rủi ro nếu chưa có bản ghi DMARC. Có thể kiểm tra trong vài giây từ bất kỳ terminal nào. Thay example.com bằng domain của bạn:

dig +short TXT _dmarc.example.com

Dòng bắt đầu bằng "v=DMARC1" nghĩa là bạn đã có bản ghi. Không có kết quả nghĩa là chưa có — đây chính là trường hợp bị lỗi từ chối này nhắm tới.

Cách khắc phục chỉ là một bản ghi DNS

Thêm một bản ghi TXT tại nhà cung cấp DNS của bạn:

• Name: _dmarc
• Value: v=DMARC1; p=none

p=none là điểm khởi đầu an toàn. Nó khai báo domain của bạn có dùng DMARC và đề nghị phía nhận gửi báo cáo về cho bạn, nhưng không yêu cầu họ xử lý gì khi kiểm tra thất bại. Cách Gmail, Yahoo hay bất kỳ bên nào khác xử lý thư của bạn không thay đổi.

Có một điều kiện đi kèm. DMARC chỉ đạt khi SPF hoặc DKIM đạt đối với domain trong trường From của bạn. Nếu cả hai đều không khớp, chỉ riêng bản ghi DMARC sẽ không giải quyết được gì.

Nếu thư của bạn đi qua dịch vụ trung chuyển

Với thư gửi qua dịch vụ relay, các yêu cầu của DMARC thường đã được đáp ứng sẵn: thư giữ domain của bạn làm envelope sender và đi ra từ các máy chủ được SPF của dịch vụ cho phép, đồng thời mỗi thư ra được ký DKIM bằng domain của bạn. Khi đó, bản ghi DMARC chính là toàn bộ phần khắc phục còn thiếu.

Nếu thư không đi qua dịch vụ relay, bản ghi DMARC vẫn là cách khắc phục, nhưng dịch vụ gửi thư của bạn phải đạt SPF hoặc DKIM cho domain của bạn. Ví dụ, Microsoft 365 ký bằng domain onmicrosoft.com của chính họ cho tới khi bạn bật DKIM cho domain riêng, và chữ ký đó không được tính cho DMARC.

Xu hướng sắp tới

Đây là khuôn mẫu mà mọi nhà cung cấp hộp thư lớn đều đang theo: yêu cầu bắt đầu với các nhà gửi hàng loạt, được công bố kèm hạn chót, rồi lặng lẽ trở thành chuẩn mực chung cho tất cả. DMARC ở mức p=none giờ là mức tối thiểu, không còn là thực hành tốt nên có.

Điều đó không hẳn là xấu. Giả mạo danh tính là khởi nguồn của phần lớn các vụ lừa đảo phishing và chiếm đoạt email doanh nghiệp (BEC) hiện nay, và một domain biết tự xác thực là domain khó bị mạo danh hơn nhiều. Bản ghi p=none giúp thư của bạn tới được Outlook.com hôm nay cũng chính là bước đầu tiên hướng tới p=reject, mức yêu cầu phía nhận từ chối những thư giả mạo domain của bạn.

Góc nhìn

Với doanh nghiệp và kỹ sư Việt Nam đang vận hành hệ thống gửi email giao dịch (hóa đơn, xác nhận đơn hàng, thư mời phỏng vấn), bài học ở đây là đừng đợi thông báo chính thức rồi mới hành động. Chỉ cần một bản ghi TXT v=DMARC1; p=none là đã giảm rủi ro thư bị thất lạc mà không ảnh hưởng gì tới cách các nhà cung cấp khác xử lý thư. Việc nên làm ngay là rà lại toàn bộ domain mà mình dùng để gửi thư và kiểm tra bằng lệnh dig.

Về lâu dài, các đội kỹ thuật nên đưa kiểm tra SPF, DKIM và DMARC vào quy trình giám sát tự động thay vì chờ đến khi có khiếu nại từ khách. Việc này cũng có lợi về bảo mật: chính các bản ghi này là nền tảng để tiến tới p=reject, giúp giảm nguy cơ kẻ xấu mạo danh domain của doanh nghiệp trong các vụ lừa đảo.