Giải mã các phản hồi 451 4.7.500, 4.7.650, RP-001 và 550 5.7.515 của Microsoft, phân biệt sự cố của Outlook với vấn đề uy tín, và biết những gì không nên làm.
Một lần trì hoãn thư (deferral) của Microsoft là một lần từ chối SMTP tạm thời, tức một phản hồi bắt đầu bằng số 4, mà máy chủ Outlook.com hoặc Microsoft 365 gửi về khi chưa chịu nhận email của bạn ngay lúc đó. Máy chủ của bạn nên giữ email lại và thử lại. Phản hồi quen thuộc nhất là 451 4.7.500 Server busy. Please try again later, và cùng một mã này có thể có nghĩa là “hoạt động gửi của bạn trông đáng ngờ” hoặc “Microsoft đang có một ngày tồi tệ”.
Vào ngày 4/9/2026, mã này mang nghĩa thứ hai, và ít nhất một đơn vị vận hành email giàu kinh nghiệm đã mất cả buổi sáng để truy tìm nghĩa thứ nhất. Dưới đây là cách phân biệt hai trường hợp.
*.olc.protection.outlook.com là hộp thư cá nhân Outlook.com, *.mail.protection.outlook.com là một tenant Microsoft 365. Mỗi bên có tài liệu riêng và kênh hỗ trợ riêng.550 5.7.515 luôn là lỗi bạn phải tự sửa.Microsoft vận hành hai hệ thống nhận thư.
Outlook.com là dịch vụ thư cá nhân: outlook.com, hotmail.com, live.com và msn.com, với các host MX như hotmail-com.olc.protection.outlook.com. Outlook.com có trang Outlook.com Postmaster, SNDS để theo dõi uy tín và biểu mẫu hỗ trợ người gửi riêng.
Microsoft 365 (Exchange Online) lưu trữ hộp thư công việc. Thư gửi tới acme.com sẽ đến acme-com.mail.protection.outlook.com. Các lỗi được mô tả trên Microsoft Learn, việc gỡ chặn được xử lý qua sender.office.com, và quản trị viên phía người nhận quyết định tenant của họ đối xử với bạn ra sao.
Tên miền không cho bạn biết mình đang gửi tới hệ thống nào. Phản hồi thì có. Trong dòng nhật ký dưới đây, được đăng lên mailop vào ngày 4/9, host relay= là một tenant Microsoft 365:
relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))Hãy đọc mã cơ bản (451), mã trạng thái mở rộng (4.7.500) và mã phụ trong ngoặc đơn, như (S77714). Microsoft không công bố các mã phụ S, nhưng việc nhiều người gửi cùng báo cáo một mã phụ vào cùng một lúc là một tín hiệu.
| Phản hồi | Hệ thống | Tài liệu của Microsoft nói gì | Việc làm đầu tiên |
|---|---|---|---|
451 4.7.500 Server busy. Please try again later from [IP]. (S77714) |
Microsoft 365 | Learn liệt kê 4.7.500-699 là “Access denied, please try again later”: hoạt động đáng ngờ, việc gửi tạm thời bị hạn chế. | Để hàng đợi tự thử lại. Kiểm tra phạm vi ảnh hưởng trước. |
451 4.7.500-699 (ASxxx) |
Microsoft 365 | Giới hạn tốc độ theo IP khi IP kết nối “đã thay đổi kiểu gửi email trước đây bằng cách gửi khối lượng lớn hơn nhiều”. | Làm chậm lộ trình tăng khối lượng. Lỗi sẽ tự hết “trong vòng vài ngày”. |
451 4.7.650 ... temporarily rate limited due to IP reputation (S775) |
Outlook.com | Không có trong bảng mà Microsoft công bố. | Giảm khối lượng gửi và số kết nối đồng thời, rồi kiểm tra SNDS. |
451 4.7.652 ... exceeded the maximum number of connections (S3115) |
Outlook.com | Không có trong bảng. Nội dung phản hồi đã nêu rõ nguyên nhân. | Mở ít kết nối hơn. |
421 RP-001, RP-002, RP-003 |
Outlook.com | Vượt giới hạn tốc độ, tốc độ trên mỗi kết nối và số kết nối, “liên quan đến uy tín IP/tên miền”. | Giới hạn tốc độ gửi, rồi kiểm tra SNDS. |
550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level. |
Outlook.com | Tên miền gửi hơn 5.000 email mỗi ngày và không đạt yêu cầu SPF, DKIM và DMARC. | Sửa xác thực và căn chỉnh. |
550 5.7.1 ... part of their network is on our block list (S3150) |
Outlook.com | IP hoặc dải IP của bạn bị chặn. | Ngừng gửi từ IP đó và mở một ticket hỗ trợ. |
550 SC-001, SC-004, OU-002 và các mã tương tự |
Outlook.com | Từ chối theo chính sách vì nội dung, uy tín hoặc khiếu nại. SC-004 trỏ tới JMRP. | Tìm ra nguyên nhân trước khi gửi lại. |
550 5.7.606-649 Access denied, banned sending IP [IP] |
Microsoft 365 | IP nằm trong danh sách người gửi bị chặn. | Yêu cầu gỡ khỏi danh sách tại sender.office.com. |
550 5.7.511 Access denied, banned sender |
Microsoft 365 | Cần điều tra thủ công. | Chuyển tiếp thư báo không gửi được (NDR) tới delist@microsoft.com. |
Nguồn: tài liệu tham khảo về NDR của Exchange Online, bài viết về ASxxx, bảng mã trên trang Postmaster và bài viết về 550 5.7.515 của Microsoft; Al Iverson về S775 và S3115; Twilio SendGrid về các trường hợp bị chặn S3140/S3150.
Sender Best Common Practices của M3AAWG nêu rằng sau một lỗi tạm thời, “bên gửi nên đóng kết nối và mở một kết nối mới sau đó”, và bên gửi không bao giờ được coi lỗi tạm thời (tempfail) là lỗi vĩnh viễn. Chính sách dành cho người gửi của Microsoft về mã 5xx: “bên gửi không được cố gắng truyền lại email đó tới người nhận đó”.
Mã 451 không phải là thư bị trả lại. Nếu nền tảng hoặc một script của bạn coi nó là thư bị trả lại, hãy sửa điều đó trước tiên.
Hướng dẫn của Microsoft về 4.7.500 hướng bạn xem lại hoạt động gửi của chính mình. Thường thì điều đó đúng, nhưng không phải lúc nào cũng vậy.
Qboxmail cho biết trên mailop rằng sự cố “bắt đầu lúc 9:47 CEST trên tất cả IP của chúng tôi cùng một lúc”, với các mã phụ S77714, S77717 và S77719. Trang trạng thái của Poppulo dẫn mã sự cố của Microsoft là EX1467029, bắt đầu lúc 11:19 BST.
Theo bài tổng hợp ngày 10/9 của emailexpert, một đơn vị vận hành email đã đổ lỗi cho sự cố đứt cáp quang, cho đến khi One.com, Qboxmail, Mailjet và Poppulo báo cáo cùng các mã đó trên mọi IP gửi và mọi khu vực. Microsoft quy nguyên nhân cho một mô hình chống spam, rồi cho một quy tắc giới hạn tốc độ vẫn tiếp tục kích hoạt trong quá trình khôi phục. emailexpert không tìm thấy báo cáo công khai nào sau sự cố. Một lỗi xác thực riêng biệt, MO1465074, kéo dài khoảng 67 giờ, từ ngày 31/8 đến ngày 3/9. Báo cáo tháng 9 của chúng tôi trình bày chi tiết về mười ngày đó.
| Tín hiệu | Nghiêng về phía Microsoft | Nghiêng về phía bạn |
|---|---|---|
| Thời điểm | Mọi IP cùng bắt đầu trong một phút | Một IP hoặc một tên miền, hoặc tăng dần theo thời gian |
| Các nhà cung cấp khác | Bình thường | Cũng đang xấu đi, hoặc khiếu nại tăng |
| Những người gửi khác | Cùng mã lỗi trên mailop và các trang trạng thái | Không ai khác nhắc đến |
| Thay đổi gần đây của bạn | Không có | Khối lượng tăng vọt, IP mới, danh sách mới |
| SNDS | Xanh lá, không bị chặn | Vàng hoặc đỏ, có khiếu nại, “Blocked” |
| Mã | 4.7.500 kèm mã phụ mà người khác cũng báo cáo | RP-00x, 4.7.650, 5.7.515, S3150 |
Cách xử lý từng phản hồi của Microsoft, dựa trên tài liệu của Microsoft và các báo cáo sự cố tháng 9/2026.
Smart Network Data Services (SNDS) là cổng thông tin miễn phí của Microsoft về uy tín theo từng IP trên Outlook.com. Trang câu hỏi thường gặp về SNDS liệt kê những gì hiển thị cho mỗi IP được cấp quyền:
Dữ liệu “có thể không có đối với những IP gửi ít hơn 100 email trong ngày đó”. Để được cấp quyền truy cập, hãy yêu cầu một IP, dải IP hoặc ASN; SNDS sẽ gửi liên kết qua email tới các địa chỉ mà nó tìm thấy qua DNS ngược (postmaster@, abuse@) hoặc RDAP. Không có cách yêu cầu thủ công.
SNDS được ra mắt lại vào tháng 6/2026. Al Iverson ghi nhận vào ngày 19/6 rằng return-path trong JMRP không còn xác định được chiến dịch và người nhận một cách đáng tin cậy, nên hãy ghi những thông tin đó ở chỗ khác. Theo trang chủ SNDS (cập nhật ngày 22/9), quyền truy cập hết hạn 10 tháng sau khi được phê duyệt hoặc chuyển đổi, kèm ba lần nhắc nhở. Hãy ghi vào lịch.
Junk Mail Reporting Program (JMRP), được đăng ký ngay trong SNDS, gửi lại cho bạn từng email mà người dùng Outlook.com đánh dấu là thư rác, thường “chỉ trong vòng 72 giờ” sau khi đăng ký. Hãy loại bỏ những người khiếu nại khỏi mọi danh sách và đăng ký các IP mới ngay khi bạn bổ sung chúng. Với IP chung mà bạn không thể đăng ký, hãy hỏi nhà cung cấp xem họ theo dõi những gì.
Outlook.com. Biểu mẫu hỗ trợ trên trang khắc phục sự cố của Postmaster yêu cầu tài khoản Microsoft, chỉ áp dụng cho bốn tên miền thư cá nhân, và “không đảm bảo” email sẽ được gửi đến. Twilio SendGrid (lời khuyên từ một nhà cung cấp) đề nghị gửi kèm tên miền, các IP, mô tả nhóm email, nội dung thư bị trả lại và ảnh chụp màn hình SNDS, trả lời thư phản hồi tự động đầu tiên để đề nghị chuyển yêu cầu lên cấp cao hơn, đồng thời hỏi về hạn mức khối lượng gửi của bạn và đề nghị xem xét lại Volume-Based Limit.
Microsoft 365. Với 5.7.606-649, hãy dùng cổng gỡ chặn (delist portal) tại sender.office.com: mỗi lần truy cập chỉ gửi được một địa chỉ và một IP, và được xác nhận qua email. Việc gỡ chặn “có thể mất đến 24 giờ hoặc lâu hơn”. Với 5.7.511, hãy gửi NDR qua email tới delist@microsoft.com và chờ phản hồi trong vòng 48 giờ.
Giới hạn tốc độ ASxxx không có cơ chế gỡ chặn. Nếu công ty người nhận lọc thư đến qua một bên thứ ba trước khi vào Microsoft 365, bài viết trên Learn cho biết một trình kết nối (connector) do quản trị viên của họ thiết lập sẽ gỡ bỏ việc giới hạn tốc độ. Nếu không, lỗi sẽ tự hết khi bạn tích lũy được lịch sử gửi.
Thử lại theo lịch. RFC 5321, mục 4.5.4.1 nêu rằng “khoảng thời gian giữa các lần thử lại NÊN là ít nhất 30 phút” và thời điểm bỏ cuộc “thường cần ít nhất 4-5 ngày”, với hai lần thử trong giờ đầu tiên, sau đó cứ hai hoặc ba giờ thử một lần. Đừng rút ngắn lịch này cho một lượt gửi gấp.
Giới hạn tốc độ theo từng nơi nhận. Theo M3AAWG, bên nhận kỳ vọng việc điều chỉnh diễn ra “như một quy trình áp dụng đồng loạt cho mọi email mà cùng một địa chỉ IP gửi đến họ”. Khi Microsoft trì hoãn thư, hãy làm chậm mọi lượt gửi tới nhóm MX đó (Outlook.com hoặc Microsoft 365).
Theo dõi số kết nối. Chính sách của Outlook.com quy định bên gửi “không được mở quá 500 kết nối đồng thời” nếu chưa có thỏa thuận trước. Đó là ngưỡng trần, và mã 4.7.652 (S3115) nghĩa là bạn đã vượt ngưỡng dành cho mình.
Tăng dần khối lượng cho IP và tên miền mới. Microsoft cho biết một IP mới “có thể đạt mức gửi đầy đủ trong vòng vài tuần hoặc sớm hơn”, tùy vào khối lượng gửi, độ chính xác của danh sách và lượng khiếu nại. IP mới nằm trong một bản ghi SPF sẵn có sẽ thừa hưởng một phần uy tín của tên miền. Hãy bắt đầu với những người tương tác gần đây.
5.7.515.Về căn chỉnh DMARC và việc chuyển từ p=none sang chế độ thực thi, hãy xem hướng dẫn về khả năng gửi đến của chúng tôi. Để email đặt lại mật khẩu và biên lai vẫn được gửi đi đều đặn, hướng dẫn về email giao dịch của chúng tôi trình bày cách đặt chúng trên một tên miền riêng.
Brew vận hành hạ tầng gửi và tự thử lại khi gặp lỗi tạm thời, nên bạn không bao giờ phải tinh chỉnh hàng đợi hay giới hạn kết nối. Những gì bạn thấy:
delivery_delayed), và trạng thái của người nhận chuyển từ đã tiếp nhận sang bị chậm, rồi sang đã gửi đến hoặc bị trả lại. Trong trang Sự kiện, hãy tìm “gửi đến bị chậm”, rồi nhập @hotmail.com hoặc @outlook.com để thu hẹp về Outlook.com (các bộ lọc tên miền được kết hợp theo điều kiện HOẶC; người nhận dùng Microsoft 365 có tên miền riêng của họ). Sự kiện chỉ cho biết email đang chờ, không cho biết vì sao.deliveryDelayed và pending bên cạnh số đã gửi đến và bị trả lại. get_email_analytics làm điều tương tự qua MCP.get_domain_health. Một lượt kiểm tra vào hộp thư đến (10 tín dụng) gửi tới các hộp thư thử nghiệm ở Gmail, Outlook, Yahoo, Apple và các nhà cung cấp khác.Brew hiện chưa có webhook về trạng thái gửi hay dữ liệu SNDS hoặc JMRP (số liệu theo từng nhà cung cấp lấy từ API sự kiện với groupBy=recipientDomain), nên hãy dùng các cổng thông tin của Microsoft để theo dõi uy tín. Khi nghi ngờ Microsoft đang gặp sự cố, chúng tôi sẽ để nguyên lượt gửi và theo dõi các sự kiện Gửi đến bị chậm chuyển thành Đã gửi đến.
Đó là một lần từ chối tạm thời từ Microsoft 365 (Exchange Online), được liệt kê là “Access denied, please try again later” sau khi phát hiện hoạt động đáng ngờ. Thường thì nguyên nhân là hành vi gửi của bạn đã thay đổi, nhưng vào ngày 4/9/2026, đó là một sự cố của Microsoft (EX1467029). Hãy để máy chủ của bạn thử lại và kiểm tra xem những người gửi khác có gặp tình trạng tương tự không.
Microsoft cho biết việc giới hạn tốc độ dựa trên hành vi gửi sẽ tự hết “trong vòng vài ngày” khi bạn tích lũy được lịch sử gửi, còn việc gỡ khỏi danh sách đen có thể mất đến 24 giờ hoặc lâu hơn. Hãy tiếp tục thử lại trong ít nhất 4 đến 5 ngày như RFC 5321 khuyến nghị, và phần lớn email bị trì hoãn vẫn sẽ được gửi đến.
Outlook.com từ chối thư từ những tên miền gửi hơn 5.000 email mỗi ngày nhưng không đáp ứng quy tắc xác thực của Outlook.com, được thực thi từ ngày 5/5/2025. SPF và DKIM phải đạt, tên miền phải công bố DMARC (p=none là đủ), và SPF hoặc DKIM phải căn chỉnh với tên miền From.
Không. Microsoft cho biết IP mới chưa có uy tín và dễ gặp vấn đề hơn. Hãy khắc phục nguyên nhân, yêu cầu gỡ khỏi danh sách đen và tăng dần khối lượng gửi trở lại trên chính IP bạn đang có.
Không. M3AAWG nêu rằng bên gửi không được coi mã 4xx là lỗi vĩnh viễn. Thư chỉ trở thành thư bị trả lại khi đã hết lượt thử lại hoặc máy chủ trả về mã 5xx. Trong Brew, một lần trì hoãn hiển thị dưới dạng sự kiện Gửi đến bị chậm, và liên hệ chỉ bị chặn gửi sau nhiều lần bị trả lại tạm thời.
