Email gửi đi bị trả về lỗi 550: đọc NDR thế nào để tìm đúng nguyên nhân?

Email gửi đi bị trả về lỗi 550: đọc NDR thế nào để tìm đúng nguyên nhân? là tình huống khá thường gặp trong Microsoft 365 và hệ thống email doanh nghiệp. Cách xử lý hiệu quả nhất là đi theo thứ tự từ nguyên nhân dễ kiểm tra, ít rủi ro đến các bước can thiệp sâu hơn.

Cách xử lý nhanh

Hãy đọc mã trạng thái mở rộng và phần Diagnostic information trong NDR. 550 có thể là người nhận không tồn tại, policy chặn, authentication/reputation hoặc quyền relay; không nên xử lý chỉ dựa vào ba chữ số 550.

Dấu hiệu và nguyên nhân thường gặp

Trước khi thay đổi cấu hình, hãy xác nhận phạm vi ảnh hưởng: chỉ một người dùng, một thiết bị hay nhiều thiết bị cùng gặp lỗi. Phạm vi ảnh hưởng là dữ kiện quan trọng để biết nên bắt đầu ở endpoint hay hạ tầng dùng chung.

• địa chỉ người nhận sai hoặc mailbox không tồn tại
• server đích chặn theo policy/reputation
• hệ thống gửi sai connector/relay/authentication

Quy trình kiểm tra từng bước

Bước 1: Đọc toàn bộ NDR và ghi lại enhanced status code

Trong thực tế hỗ trợ doanh nghiệp, đọc toàn bộ NDR và ghi lại enhanced status code. Nên ghi lại kết quả trước và sau khi thay đổi để có cơ sở so sánh; nếu nhiều người cùng xử lý, thông tin này cũng giúp tránh lặp lại các bước đã thử.

Bước 2: Kiểm tra message trace phía Microsoft 365

Ở bước này, kiểm tra message trace phía Microsoft 365. Nên ghi lại kết quả trước và sau khi thay đổi để có cơ sở so sánh; nếu nhiều người cùng xử lý, thông tin này cũng giúp tránh lặp lại các bước đã thử.

Bước 3: Xác minh địa chỉ đích và thử một mailbox khác cùng domain

Về mặt kỹ thuật, xác minh địa chỉ đích và thử một mailbox khác cùng domain. Nên ghi lại kết quả trước và sau khi thay đổi để có cơ sở so sánh; nếu nhiều người cùng xử lý, thông tin này cũng giúp tránh lặp lại các bước đã thử.

Bước 4: Nếu bị chặn reputation/policy, làm việc theo thông tin server đích cung cấp thay vì gửi lặp

Khi kiểm tra tại hiện trường, nếu bị chặn reputation/policy, làm việc theo thông tin server đích cung cấp thay vì gửi lặp. Nên ghi lại kết quả trước và sau khi thay đổi để có cơ sở so sánh; nếu nhiều người cùng xử lý, thông tin này cũng giúp tránh lặp lại các bước đã thử.

Cách xác nhận đã xử lý đúng

Không nên kết luận chỉ vì lỗi tạm thời biến mất. Với hệ thống doanh nghiệp, cần có tiêu chí xác nhận để tránh lỗi quay lại sau vài giờ hoặc sau khi người dùng đổi mạng/khởi động lại thiết bị.

• email test được accepted với mã 250
• message trace không còn fail cùng lý do

Những việc không nên làm

• gửi lặp hàng chục lần khi server đích đang block
• thay đổi DNS/connector khi chưa đọc NDR

Khi nào nên chuyển cho IT chuyên trách?

Nếu lỗi ảnh hưởng nhiều người, liên quan quyền quản trị, dữ liệu, bảo mật, firewall, server hoặc cần thay đổi cấu hình production, nên dừng thử nghiệm ngẫu nhiên và chuyển cho người phụ trách IT. Với Microsoft 365 và hệ thống email doanh nghiệp, việc có log, ảnh chụp lỗi, thời điểm xảy ra và các bước đã thử sẽ rút ngắn đáng kể thời gian xử lý.

Gợi ý vận hành lâu dài

Sau khi xử lý xong, nên ghi lại nguyên nhân gốc, cấu hình đã thay đổi và biện pháp phòng ngừa. Những sự cố lặp lại nhiều lần thường là tín hiệu cần chuẩn hóa tài liệu, monitoring, patching hoặc thiết kế hệ thống thay vì tiếp tục xử lý từng lần riêng lẻ.

Xem thêm các bài trong Microsoft 365 & Email.

Bài viết liên quan

• Autodiscover Outlook lỗi: vì sao email vẫn vào web được nhưng desktop không cấu hình được?
• File OST quá lớn làm Outlook chậm: nên giảm cache hay tạo profile mới?