# Microsoft trì hoãn thư 451 4.7.500: cẩm nang cho người gửi

URL chính tắc: https://brew.new/vi/blog/microsoft-451-4-7-500-deferrals-playbook
Tác giả: Thomas Park
Ngày đăng: 2026-10-05
Ngày cập nhật: 2026-10-05

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.

## Những điểm chính

- Hãy xem tên host trước tiên. `*.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.
- Mã 4xx nghĩa là xếp hàng đợi và thử lại: theo RFC 5321, mỗi lần thử cách nhau ít nhất 30 phút, trong ít nhất 4 đến 5 ngày. Mã 5xx nghĩa là dừng lại. Chính sách của Microsoft cấm thử lại với mã này.
- Nếu mọi IP đều nhận cùng một mã của Microsoft trong cùng một phút, trong khi Gmail và Yahoo vẫn bình thường, hãy nghi ngờ phía Microsoft và kiểm tra mailop (danh sách thư thảo luận của giới vận hành email) trước khi thay đổi bất cứ điều gì.
- Từ ngày 5/5/2025, Outlook.com đã thực thi yêu cầu SPF, DKIM và DMARC đối với các tên miền gửi hơn 5.000 email mỗi ngày. `550 5.7.515` luôn là lỗi bạn phải tự sửa.
- Hãy đăng ký các IP gửi trong SNDS và JMRP ngay từ bây giờ. Quyền truy cập SNDS hết hạn sau 10 tháng nếu bạn không xác nhận lại.
- Đừng thử lại dồn dập hơn, đừng xoay vòng sang IP mới, và đừng chặn gửi tới các liên hệ bị trì hoãn.

## Trước hết, hãy xác định bạn đang làm việc với Microsoft nào

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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), 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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), 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](https://www.mail-archive.com/mailop@mailop.org/msg27209.html) vào ngày 4/9, host `relay=` là một tenant Microsoft 365:

```text
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))
```

## Giải mã phản hồi

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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), [bài viết về ASxxx](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), bảng mã trên trang Postmaster và [bài viết về 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) của Microsoft; Al Iverson về [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) và [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html); Twilio SendGrid về [các trường hợp bị chặn S3140/S3150](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks).

### Số 4 hay số 5 chính là chỉ dẫn

[Sender Best Common Practices của M3AAWG](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) 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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) 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.

## Sự cố của Microsoft hay vấn đề uy tín của bạ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.

### Ngày 4/9/2026 đã diễn ra như thế nào

Qboxmail [cho biết trên mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html) 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](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) 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](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/) 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](/vi/blog/state-of-email-september-2026) của chúng tôi trình bày chi tiết về mười ngày đó.

### Năm bước kiểm tra trước khi hành động

1. **Phạm vi ảnh hưởng của bạn.** Sự cố nền tảng ảnh hưởng đến mọi IP, tên miền và nhóm email chỉ trong vài phút. Vấn đề uy tín thường chỉ bắt đầu ở một trong số đó.
2. **Các nhà cung cấp khác.** Nếu Gmail, Yahoo và Apple vẫn nhận thư bình thường và những người gửi khác báo cáo cùng mã lỗi của Microsoft, nguyên nhân nhiều khả năng nằm ở Microsoft.
3. **72 giờ vừa qua của bạn.** Một đợt tăng vọt khối lượng gửi, một IP mới, một danh sách vừa nhập, một thay đổi DNS hay một lượt gửi kích hoạt lại liên hệ cũ đều cần được khắc phục trong mọi trường hợp.
4. **Hỏi thăm các bên khác.** Hãy xem kho lưu trữ của mailop và các trang trạng thái. Quản trị viên Microsoft 365 có thể mở **Health > Service health** (tình trạng dịch vụ), nơi mục [Issue history](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) (lịch sử sự cố) liệt kê các sự cố được đăng cho tenant của bạn trong 7 hoặc 30 ngày gần nhất. Poppulo đã tìm thấy EX1467029 ở đó.
5. **SNDS.** Nếu SNDS vẫn xanh lá và không có lệnh chặn nào trong khi thư bị trì hoãn ngày càng nhiều, nguyên nhân nhiều khả năng không nằm ở bạn.

| 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 |

![Sơ đồ ra quyết định cho các phản hồi của Microsoft: mã 5xx dẫn đến việc sửa xác thực, cổng gỡ chặn hoặc một ticket hỗ trợ; mã 4xx dẫn đến bước kiểm tra sự cố, rồi hoặc chờ sự cố qua đi, hoặc giới hạn tốc độ gửi và kiểm tra SNDS.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*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.*

## SNDS và JMRP: thiết lập trước khi cần đến

[Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) (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](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) liệt kê những gì hiển thị cho mỗi IP được cấp quyền:

- **Kết quả lọc** (Filter result). Xanh lá là dưới 10% thư bị đánh giá là spam, vàng là từ 10% đến 90%, đỏ là trên 90%.
- **Tỷ lệ khiếu nại** (Complaint rate), tức số khiếu nại chia cho số người nhận. Hơn 30% IP duy trì dưới 0,3%, “một ngưỡng tốt để nhắm tới”.
- **Số lệnh RCPT so với số người nhận thư** (RCPT commands, Message recipients). Chênh lệch lớn cho thấy danh sách đã cũ.
- **Trạng thái IP** (IP status): Blocked (bị chặn), Bot hoặc Junked (bị đưa vào thư rác).

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](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html) 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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (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ì.

## Hỗ trợ người gửi và gỡ khỏi danh sách đen

**Outlook.com.** Biểu mẫu hỗ trợ trên [trang khắc phục sự cố của Postmaster](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) 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](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) (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, giới hạn tốc độ và tăng dần khối lượng

**Thử lại theo lịch.** [RFC 5321, mục 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-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.

## Những điều không nên làm

- **Thử lại dồn dập hơn.** Đẩy toàn bộ hàng đợi đi sau mỗi vài phút sẽ dồn thêm kết nối vào một IP mà Microsoft đang muốn làm chậm, và khiến bạn nhận thêm mã 4.7.652.
- **Đổi IP để né tránh.** IP mới chưa có uy tín và dễ gặp vấn đề hơn, và việc rải thư qua nhiều IP mới chính là cách làm của những kẻ phát tán spam kiểu snowshoe.
- **Thử lại mã 5xx.** Microsoft cấm việc này, và sau “nhiều phản hồi không gửi được”, bạn phải ngừng gửi tới người nhận đó.
- **Chặn gửi tới các liên hệ bị trì hoãn.** Địa chỉ đó vẫn hợp lệ.
- **Gửi lại cho người nhận bị trì hoãn.** Email của họ vẫn đang nằm trong hàng đợi. Bạn sẽ gửi trùng.
- **Hoảng loạn sửa DNS.** Thay đổi SPF hoặc DKIM giữa lúc đang có sự cố sẽ tạo thêm một vấn đề thứ hai, trừ khi bạn nhận được mã `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](/vi/blog/email-deliverability) 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](/vi/blog/transactional-emails) 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.

## Trong Brew, điều này trông như thế nào

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:

- **Sự kiện Gửi đến bị chậm.** Một lần trì hoãn được ghi nhận thành sự kiện Gửi đến bị chậm (`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.
- **Chi tiết thư bị trả lại.** Phần Siêu dữ liệu của sự kiện Bị trả lại chứa loại thư bị trả lại và thông báo của nhà cung cấp.
- **Số đếm qua API.** [Tổng quan phân tích](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) trả về `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.
- **Chặn gửi có tính đến mã 4xx.** Một lần bị trả lại vĩnh viễn (hard bounce) hoặc một khiếu nại sẽ khiến liên hệ bị chặn gửi ngay lập tức. Với thư bị trả lại tạm thời (soft bounce), liên hệ chỉ bị chặn gửi sau ba lần trong vòng 30 ngày.
- **Tăng dần khối lượng.** Tính năng [Gửi tăng dần](https://docs.brew.new/create-emails/send-options#gradual-send) chia một lượt gửi lớn thành các lô theo tỷ lệ phần trăm, theo giờ hoặc theo ngày, và bạn có thể tạm dừng nếu Outlook.com bắt đầu trì hoãn thư.
- **Sức khỏe tên miền.** Thẻ Khả năng gửi đến của mỗi tên miền chấm điểm từ 0 đến 100 trên các trụ cột vào hộp thư đến, uy tín, xác thực, nội dung và thiết lập gửi; bạn cũng có thể lấy điểm này qua công cụ 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.

## Câu hỏi thường gặp

### Mã 451 4.7.500 Server busy từ Outlook hoặc Microsoft 365 có nghĩa là gì?

Đó 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 sẽ tiếp tục trì hoãn email của tôi trong bao lâu?

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.

### Mã 550 5.7.515 là gì và sửa như thế nào?

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.

### Tôi có nên đổi sang địa chỉ IP mới nếu Microsoft chặn IP hiện tại không?

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ó.

### Thư bị Microsoft trì hoãn có được tính là thư bị trả lại không?

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.