Defaults.Exposed › Cách khắc phục › Guides
Outlook Từ Chối Email Của Bạn: 550 5.7.515, 550 5.7.509 và compauth=fail — Giải Thích và Cách Sửa (2026)
Đã xuất bản 2026-07-08
Số liệu tính đến 2026-06-29 · phương pháp luận v7. Dữ liệu tổng hợp từ 261 triệu tên miền được chấm điểm. Xem cách chúng tôi chấm điểm.
Hai hệ thống Microsoft khác nhau từ chối thư. Outlook.com dành cho người dùng phổ thông chặn người gửi khối lượng lớn không qua xác thực (550 5.7.515, áp dụng từ tháng 5/2025); Exchange Online chặn thư vi phạm chính sách DMARC reject của chính bạn (550 5.7.509). Trong số 10,205,070 tên miền cho phép spf.protection.outlook.com, 85.0% có SPF strict nhưng chỉ 21.7% thực thi DMARC, theo dữ liệu khảo sát 261,086,232 tên miền của Defaults.Exposed.
Hầu hết các vấn đề “Outlook từ chối email của tôi” thực ra không phải bị từ chối — mà là thư lặng lẽ rơi vào Thư rác với compauth=fail trong header. Hướng dẫn này giải mã các mã lỗi Microsoft, chỉ cách đọc header Authentication-Results, và hướng dẫn cách sửa theo thứ tự: xác nhận SPF, bật DKIM cho tên miền tùy chỉnh, xuất bản và thực thi DMARC, kiểm tra lại.
Bạn thực sự gặp lỗi Microsoft nào?
Microsoft có hai bề mặt nhận thư riêng biệt và từ chối vì những lý do khác nhau. Hãy xác định đúng triệu chứng trước — chẩn đoán sai sẽ mất cả ngày.
| Mã / tín hiệu | Xuất phát từ đâu | Ý nghĩa | Dữ liệu tính đến 2026-06-29 |
|---|---|---|---|
| 550 5.7.515 | Outlook.com / Hotmail / Live dành cho người dùng phổ thông | Bạn gửi >5.000 thư/ngày đến Outlook phổ thông và không đáp ứng yêu cầu xác thực (SPF + DKIM + DMARC), áp dụng từ tháng 5/2025 | — |
| 550 5.7.509 | Exchange Online / EOP (tenant doanh nghiệp) | Máy chủ nhận áp dụng chính sách DMARC p=reject của chính tên miền bạn — thư không qua DMARC | Chỉ 10.59% trong tổng số 261,086,232 tên miền được chấm điểm thực thi DMARC |
| 550 5.7.511 | Exchange Online / EOP | Địa chỉ hoặc tên miền gửi của bạn nằm trong danh sách chặn của tổ chức nhận hoặc của Microsoft | — |
| S3140 / S3150 | Outlook.com phổ thông | IP gửi của bạn có uy tín kém — đây là chặn IP, không phải lỗi xác thực | — |
compauth=fail (headers) | Cả hai bề mặt — trường hợp phổ biến nhất | Thư được chấp nhận nhưng bị đưa vào Thư rác: xác thực tổng hợp của Microsoft thất bại. Không có bounce, không có NDR — chỉ là thư rác | Trong số 10,205,070 tên miền gửi qua M365, chỉ 21.7% thực thi DMARC |
Nội dung NDR chính xác có thể thay đổi; hãy xác minh các chuỗi bạn trích dẫn với một bounce thực tế trước khi dựa vào chúng.
550 5.7.515 có nghĩa là gì?
Đây là yêu cầu của Outlook.com / Hotmail dành cho người dùng phổ thông, không phải lỗi của tenant Microsoft 365. Từ tháng 5/2025, người gửi hơn 5.000 thư mỗi ngày đến địa chỉ Outlook phổ thông phải vượt qua SPF, DKIM, và xuất bản bản ghi DMARC (ít nhất p=none) căn chỉnh với tên miền From. Không đáp ứng được thì Outlook phổ thông từ chối với thông báo kiểu:
550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.
Hai điều đây không phải: đây không phải quy định năm 2026 (nếu thư mới bắt đầu bị trả lại, thì khối lượng hoặc DNS của bạn đã thay đổi, không phải quy tắc), và đây không liên quan đến cài đặt tenant M365 của người nhận. Cách sửa là thực hiện các bước xác thực bên dưới — và những ngày chiến dịch vượt 5.000 thư/ngày cũng tính.
550 5.7.509 có nghĩa là gì?
Mã này đến từ Exchange Online Protection trên tenant doanh nghiệp và có nghĩa là chính sách DMARC của bạn đang được áp dụng:
550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.
Đọc kỹ — đây không phải Microsoft gây khó dễ. Tên miền của bạn xuất bản p=reject, thư này không qua DMARC, và máy chủ nhận đã làm đúng những gì bạn yêu cầu. Nếu thư bị trả lại là thư hợp lệ, có một nguồn gửi nào đó (công cụ newsletter, CRM, thiết bị scan-to-email) chưa được xác thực theo cách căn chỉnh. Đừng làm yếu chính sách; hãy cấp cho nguồn đó SPF hoặc DKIM căn chỉnh — xem sửa DMARC và từ p=none đến p=reject.
Tại sao Outlook đưa thư vào Thư rác với compauth=fail thay vì từ chối?
Hầu hết vấn đề deliverability của Microsoft không bao giờ tạo ra bounce. Thư được chấp nhận, chấm điểm, rồi được đưa vào Thư rác — bằng chứng duy nhất là header Authentication-Results. Trong hộp thư của người nhận (hoặc hộp thư outlook.com test của bạn), mở thư, chọn Xem nguồn thư, và tìm dòng:
Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001
compauth là kết quả xác thực tổng hợp của Microsoft: ngay cả khi tên miền không xuất bản bản ghi DMARC, Microsoft vẫn áp dụng các kiểm tra ngầm định tương tự DMARC. Các giá trị thường gặp:
compauth=fail reason=000— thư không qua xác thực rõ ràng: chính sách DMARC của tên miền bạn là quarantine/reject và thư không vượt qua.compauth=fail reason=001— thư không qua xác thực ngầm định: tên miền bạn không xuất bản (hoặc xuất bản không đủ) bản ghi xác thực, và thư trông không giống đến từ bạn. Đây là đặc điểm điển hình của “chưa cài đặt DKIM/DMARC”.compauth=fail reason=6xx— các biến thể lỗi xác thực ngầm định;601cụ thể có nghĩa là tên miền gửi là một trong các tên miền được chấp nhận của tổ chức bạn (giả mạo nội bộ, tự gửi cho chính mình).
Bài học: với Microsoft, hãy đọc header chứ không chỉ xem NDR. Các kết quả spf=, dkim= và dmarc= trên cùng dòng đó chỉ chính xác bước nào cần sửa.
Cách sửa lỗi từ chối và thư rác của Outlook?
- Chạy quét miễn phí trước. Công cụ này chấm điểm SPF, DKIM và DMARC của bạn trong một lần và cho thấy bước nào đang lỗi trước khi bạn chạm vào DNS.
- Xác nhận SPF — thường đã ổn trên Microsoft 365. Bản ghi chuẩn là
v=spf1 include:spf.protection.outlook.com -all, và quá trình cài đặt M365 đã đặt sẵn: 85.0% trong số 10,205,070 tên miền cho phép spf.protection.outlook.com đã kết thúc bằng-allstrict (dữ liệu tính đến 2026-06-29). Một lưu ý: máy chủ nhận kiểm tra SPF theo tên miền Return-Path (RFC5321.MailFrom), không phải tiêu đề From — vì vậy một công cụ newsletter có thể qua SPF trên tên miền bounce của nó mà không giúp ích gì cho tên miền của bạn. Đó là lý do các bước 3 và 4 quan trọng hơn. - Bật DKIM cho tên miền tùy chỉnh — hai CNAME selector. M365 ký với
onmicrosoft.commặc định không căn chỉnh cho đến khi bạn bật ký với tên miền tùy chỉnh: xuất bản CNAMEselector1._domainkeyvàselector2._domainkeytrỏ đến khóa của tenant, rồi bật ký trong cổng Defender. Hướng dẫn đầy đủ: cài đặt DKIM trên Microsoft 365. Nếu DKIM hiển thị “pass” nhưng DMARC vẫn lỗi, bạn đang gặp bẫy chữ ký mặc định. - Xuất bản DMARC rồi thực thi. Bắt đầu với
v=DMARC1; p=none; rua=mailto:...để nhận báo cáo, sửa mọi nguồn hợp lệ được phát hiện, rồi nâng dần lênp=quarantinevàp=reject— lộ trình từng bước trong sửa DMARC. Đây là bước hầu hết doanh nghiệp dùng Microsoft bỏ qua: chỉ 21.7% tên miền gửi qua M365 thực thi DMARC. - Kiểm tra lại bằng cách đọc header. Gửi đến hộp thư outlook.com phổ thông, mở nguồn thư, và xác nhận
spf=pass,dkim=pass,dmarc=passvàcompauth=pass. - Người gửi khối lượng lớn: đáp ứng tiêu chuẩn Outlook phổ thông. Hơn 5.000/ngày, bạn cũng cần địa chỉ From/reply-to hợp lệ và được giám sát, liên kết hủy đăng ký hoạt động, và danh sách sạch — xác thực xử lý 5.7.515; tỷ lệ khiếu nại giữ bạn tránh khỏi chặn IP S3140/S3150. Nếu đã bị chặn IP, sửa SPF/DKIM/DMARC không gỡ chặn: hãy yêu cầu xóa tên qua hỗ trợ người gửi của Microsoft, và coi xác thực là lý do bạn sẽ không bị chặn lại.
Tại sao nhiều tên miền Microsoft 365 vẫn thất bại?
Vì thiết lập mặc định làm bước đầu tiên cho bạn nhưng không làm những bước còn lại. Trong số 10,205,070 tên miền cho phép spf.protection.outlook.com, 85.0% có SPF strict — bản ghi M365 cấp cho bạn khi cài đặt — nhưng chỉ 21.7% thực thi DMARC, theo dữ liệu khảo sát 261,086,232 tên miền của Defaults.Exposed. M365 mặc định cho bạn SPF strict, rồi hầu hết tenant dừng ở đó — đúng nhóm đối tượng mà compauth được xây dựng để bắt (dù vẫn tốt hơn 10.59% thực thi DMARC trong tất cả tên miền được chấm điểm). So sánh đầy đủ nhà cung cấp: bảng xếp hạng SPF nhà cung cấp email.
Câu hỏi thường gặp
550 5.7.515 có phải lỗi Microsoft 365 không? Không. Mã này đến từ Outlook.com / Hotmail dành cho người dùng phổ thông và nhắm vào người gửi >5.000 thư/ngày, áp dụng từ tháng 5/2025. Lỗi từ chối Exchange Online doanh nghiệp dùng mã khác — phổ biến nhất là 550 5.7.509 (chính sách DMARC reject của bạn) hoặc 5.7.511 (người gửi bị cấm).
Chúng tôi gặp 550 5.7.509 nhưng thư là hợp lệ — có nên bỏ p=reject không?
Không — chính sách của bạn đã bắt được một nguồn chưa xác thực, đó là điều nó hoạt động đúng. Hãy tìm nguồn đó trong header hoặc báo cáo DMARC và cấp cho nó DKIM căn chỉnh (hoặc SPF căn chỉnh). Giảm xuống p=none sẽ mở lại khả năng giả mạo tên miền chính xác cho tất cả mọi người.
compauth=fail có nghĩa là có người đang giả mạo chúng tôi không?
Không nhất thiết. reason=001 thường có nghĩa là chính thư của bạn không thể chứng minh là của mình — không có DKIM căn chỉnh, không có DMARC. Chỉ 21.7% trong 10,205,070 tên miền gửi qua M365 thực thi DMARC (dữ liệu tính đến 2026-06-29), nên Microsoft áp dụng kiểm tra ngầm định cho tất cả những người còn lại, và thư hợp lệ chưa xác thực cũng bị lỗi.
Tôi gửi ít hơn 5.000 email mỗi ngày — có thể bỏ qua không?
Bạn sẽ tránh được 550 5.7.515, nhưng không tránh được Thư rác: compauth áp dụng ở mọi khối lượng. Gmail cũng làm điều tương tự — xem hướng dẫn Gmail 550 5.7.26. Các bước sửa là miễn phí; rào cản là nhận thức, không phải chi phí.
Gửi báo cáo cho chủ sở hữu
Nếu bạn sửa email cho người khác — một khách hàng, sếp của bạn, công ty đang bị trả lại hóa đơn — hãy hoàn thành công việc với bằng chứng. Chạy lại quét miễn phí sau khi DNS ổn định và chuyển tiếp báo cáo được chấm điểm. Nó cho thấy SPF, DKIM và DMARC chuyển sang màu xanh bằng ngôn ngữ đơn giản mà chủ doanh nghiệp có thể đọc, và đó là tài liệu họ cần lần tới khi bảo hiểm mạng tái tục hoặc bảng câu hỏi bảo mật của khách hàng hỏi xem email có được xác thực không. Đã sửa là tốt; có bằng chứng sửa là điều giúp bạn được trả tiền và họ được bảo vệ.
Kiểm tra tên miền miễn phí
Xem bước nào Microsoft đang phạt bạn — SPF, DKIM, DMARC — một cách riêng tư và chỉ chủ sở hữu mới thấy.
Kiểm tra tên miền → · Sửa DMARC → · DKIM qua nhưng DMARC lỗi → · Cách chúng tôi chấm điểm → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.