Thư bị trả lại: đọc thông báo lỗi và xử lý thế nào
Thư gửi đi bị trả lại kèm dòng thông báo lỗi khó hiểu. Bài viết chỉ cách đọc mã lỗi SMTP, phân biệt lỗi vĩnh viễn với lỗi tạm thời, khi nào nên gửi lại.
Thư bị trả lại là gì và vì sao nó xảy ra
Thư bị trả lại (bounce) là email quay ngược về hộp thư người gửi kèm một thông báo lỗi, thay vì tới được người nhận. Thông báo đó không phải dòng chữ vô nghĩa: nó ghi rõ mã trạng thái và lý do cụ thể, đủ để biết nên sửa gì trước khi gửi lại.
Phản xạ thường gặp là hoảng, xoá thư trả về rồi bấm gửi lại ngay. Cách này bỏ qua đúng phần quan trọng nhất của thông báo: dòng mã lỗi. Với email theo tên miền doanh nghiệp, đọc đúng dòng này còn quan trọng hơn, vì một địa chỉ gửi sai lặp lại nhiều lần ảnh hưởng tới cả tên miền, không riêng một thư.
Hai nhóm lỗi cần phân biệt trước tiên: lỗi vĩnh viễn, thư không bao giờ tới được dù thử lại bao nhiêu lần, và lỗi tạm thời, hệ thống tự thử lại và thường tới nơi sau đó. Nhầm hai nhóm này là nguyên nhân phổ biến nhất khiến người dùng xử lý sai cách.
Mã lỗi email SMTP 4xx và 5xx nói lên điều gì
Mã lỗi email theo giao thức SMTP luôn bắt đầu bằng một chữ số: số 4 là lỗi tạm thời, số 5 là lỗi vĩnh viễn. Đi kèm là mã trạng thái mở rộng dạng ba số x.y.z, ví dụ 550 5.1.1 nghĩa là máy chủ từ chối vĩnh viễn vì địa chỉ người nhận không tồn tại.
Theo RFC 5321, tài liệu định nghĩa giao thức SMTP, mã trả lời ba chữ số là bắt buộc trong mọi phiên gửi thư. RFC 3463 bổ sung bộ mã trạng thái mở rộng để nêu chi tiết lý do, còn RFC 3464 quy định định dạng của bản thông báo trả về mà người dùng nhìn thấy trong hộp thư.
Đọc đúng hai phần này, chữ số đầu và cụm x.y.z đi sau, là đủ để biết nên sửa địa chỉ hay chỉ cần chờ.
Lỗi vĩnh viễn: địa chỉ không tồn tại, tên miền sai, bị từ chối nhận
Lỗi vĩnh viễn luôn mang mã 5xx. Ba trường hợp phổ biến nhất: 550 5.1.1 khi địa chỉ không tồn tại, 550 5.1.2 khi tên miền sau dấu @ gõ sai hoặc đã ngừng hoạt động, và 550 5.7.1 khi người nhận hoặc máy chủ của họ chủ động từ chối thư.
Máy chủ gửi không thử lại các lỗi này. Với 5.1.1 và 5.1.2, kết quả lần thử nào cũng giống lần trước vì địa chỉ đích không đổi. Việc cần làm là kiểm tra lại chính tả địa chỉ, hỏi người nhận địa chỉ mới nếu công ty họ đổi tên miền, hoặc gỡ hẳn địa chỉ đó khỏi danh sách gửi nếu không xác minh được.
Gửi lại nguyên văn một thư báo lỗi vĩnh viễn nhiều lần không đưa thư tới đích, mà còn kéo uy tín gửi email của cả tên miền xuống, vì hệ thống nhận thấy tên miền liên tục gửi tới địa chỉ không hợp lệ.
Lỗi tạm thời: hộp thư đầy, máy chủ bận, bị làm chậm có chủ đích
Lỗi tạm thời mang mã 4xx. Ba nguyên nhân thường gặp: 452 4.2.2 khi hộp thư người nhận đã đầy dung lượng, 421 4.7.0 khi máy chủ nhận đang quá tải, và trường hợp máy chủ cố tình trì hoãn một khoảng thời gian ngắn để lọc bớt thư rác tự động.
Với lỗi tạm thời, hệ thống gửi tự thử lại theo chu kỳ mà không cần người dùng làm gì. RFC 5321 khuyến nghị máy chủ gửi tiếp tục thử trong ít nhất 4 – 5 ngày trước khi chuyển một lỗi tạm thời thành báo lỗi vĩnh viễn và trả hẳn về cho người gửi.
Trường hợp hộp thư người nhận đầy dung lượng, cách nhanh hơn chờ hệ thống thử lại là báo cho người nhận qua kênh khác để họ dọn bớt hộp thư hoặc nâng gói dịch vụ.
Thông báo trả về nói mình đang bị chặn vì uy tín gửi email
Một số thư bị chặn hẳn không do lỗi địa chỉ mà do uy tín gửi email của tên miền hoặc địa chỉ IP đã thấp. Dấu hiệu nhận biết: dòng thông báo nhắc tới các cụm như "reputation", "policy", "blocked" hoặc mã 550 5.7.1 kèm lời giải thích về chính sách chống spam, thay vì về địa chỉ người nhận.
Khác gì với việc email vào spam
Email vào spam là thư đã tới nơi nhưng bị máy chủ nhận xếp vào mục rác, người nhận vẫn tìm thấy được nếu mở đúng thư mục. Trường hợp trả lại là thư chưa tới được, máy chủ nhận từ chối ngay từ đầu. Hai tình huống khác nhau nhưng cùng gốc: nguyên nhân email vào hộp thư spam và nguyên nhân thư bị chặn hẳn thường trùng nhau, đều liên quan tới cách máy chủ nhận đánh giá độ tin cậy của bên gửi.
Dấu hiệu IP bị blacklist trong thông báo lỗi
Khi địa chỉ IP gửi bị đưa vào danh sách đen, thông báo lỗi thường ghi thẳng tên danh sách chặn hoặc một dòng hướng dẫn gỡ khỏi danh sách đó. Nguyên nhân phổ biến: thiếu hoặc cấu hình sai SPF, DKIM, DMARC, hoặc địa chỉ IP từng bị dùng để gửi thư rác trước khi công ty thuê lại. Cấu hình đúng ba bản ghi xác thực này là bước đầu để tránh bị đưa vào danh sách chặn.
Gửi lại thư bị trả lại: khi nào nên, khi nào không
Câu trả lời phụ thuộc hoàn toàn vào nhóm lỗi. Lỗi tạm thời (4xx): không cần gửi lại tay, hệ thống tự làm. Lỗi vĩnh viễn (5xx): gửi lại tay vô ích cho tới khi địa chỉ hoặc nguyên nhân gốc được sửa. Lỗi do uy tín gửi thấp: gửi lại càng nhiều càng khiến uy tín gửi email giảm sâu hơn.
| Nhóm lỗi | Ý nghĩa | Việc phải làm | Có nên gửi lại thư |
|---|---|---|---|
| Địa chỉ không tồn tại (5xx, 5.1.1) | Hộp thư người nhận không có thật hoặc đã đóng | Sửa lại địa chỉ hoặc gỡ khỏi danh sách gửi | Không, gửi lại y nguyên vẫn báo lỗi |
| Tên miền người nhận sai (5xx, 5.1.2) | Tên miền sau dấu @ gõ sai hoặc không còn hoạt động | Kiểm tra chính tả tên miền trước khi gửi lại | Không, phải sửa địa chỉ trước |
| Người nhận từ chối (5xx, 5.7.1) | Máy chủ nhận chặn theo chính sách hoặc nội dung thư | Xem lại nội dung, liên hệ người nhận qua kênh khác | Không nên gửi lại nguyên văn |
| Hộp thư đầy (4xx, 4.2.2) | Người nhận đã hết dung lượng lưu trữ | Chờ hệ thống tự thử lại, báo người nhận nếu cần gấp | Có, hệ thống tự làm, không cần gửi tay |
| Máy chủ bận hoặc bị làm chậm có chủ đích (4xx, 4.7.0) | Máy chủ nhận quá tải hoặc đang lọc chống spam | Chờ hệ thống thử lại theo chu kỳ | Có, tự động, không cần can thiệp |
| Uy tín gửi email thấp (blacklist, reputation) | Tên miền hoặc IP gửi bị đánh giá thấp | Kiểm tra SPF, DKIM, DMARC, xem lại cách gửi thư | Không, gửi lại không giải quyết nguyên nhân gốc |
Email doanh nghiệp và bounce: vì sao ảnh hưởng cả tên miền
Với email cá nhân, một địa chỉ bị lỗi chỉ ảnh hưởng đúng người gửi đó. Với email doanh nghiệp dùng chung một tên miền cho nhiều nhân sự, uy tín gửi được tính theo tên miền và địa chỉ IP dùng chung. Một vài hộp thư gửi sai cách, lặp lại nhiều lần, có thể kéo tỉ lệ vào inbox của cả công ty xuống, kể cả những hộp thư chưa từng gửi thư lỗi nào.
Thư công ty bị trả lại thường xuyên?
SPF, DKIM, DMARC cấu hình đúng chuẩn cùng địa chỉ IP gửi ổn định giúp giảm bounce do uy tín gửi thấp. Gói mailBus từ BizMaC có sẵn ba bản ghi xác thực này, đội kỹ thuật hỗ trợ đọc thông báo lỗi khi thư không tới nơi.
Câu hỏi thường gặp về thư bị trả lại
Thư bị trả lại có mất nội dung đã soạn không?
Không mất. Bounce chỉ báo thư chưa gửi được, bản thư vẫn còn trong mục Đã gửi hoặc bản nháp tuỳ ứng dụng, sao chép lại để sửa và gửi tiếp là đủ.
Mã lỗi 550 5.1.1 luôn có nghĩa là gõ sai địa chỉ?
Không hẳn. Có thể do gõ sai, nhưng cũng có thể do tài khoản người nhận đã bị đóng hoặc công ty họ đổi hẳn hệ thống email, nên địa chỉ cũ không còn tồn tại dù trước đó đúng.
Hệ thống thử lại một lỗi tạm thời trong bao lâu thì ngừng?
Theo khuyến nghị của RFC 5321, phần lớn hệ thống gửi thử lại trong khoảng 4 – 5 ngày. Hết thời hạn này mà vẫn lỗi, hệ thống chuyển thành báo lỗi vĩnh viễn và trả về cho người gửi.
Làm sao phân biệt bị chặn vì uy tín gửi email với lỗi địa chỉ thông thường?
Đọc kỹ dòng mô tả sau mã lỗi. Lỗi địa chỉ nhắc tới "user unknown" hoặc "no such user", còn lỗi uy tín gửi nhắc tới "reputation", "policy" hoặc nêu thẳng tên một danh sách chặn cụ thể.
Gửi thư số lượng lớn bị trả lại nhiều có ảnh hưởng tới cả tên miền không?
Có. Tỉ lệ bounce cao trong một đợt gửi khiến các nhà cung cấp lớn hạ điểm uy tín của tên miền và IP gửi, ảnh hưởng tới cả thư giao dịch bình thường gửi sau đó.
Tóm tắt
Thư bị trả lại không phải lỗi mơ hồ: mã số đầu tiên, 4 hoặc 5, cùng cụm x.y.z đi kèm nói rõ nên sửa địa chỉ hay chỉ cần chờ. Lỗi vĩnh viễn (5xx) cần sửa hoặc gỡ địa chỉ khỏi danh sách, gửi lại nguyên văn không giúp ích gì. Lỗi tạm thời (4xx) hệ thống tự xử lý, không cần can thiệp tay. Khi thông báo nhắc tới uy tín gửi hoặc danh sách chặn, việc cần làm là kiểm tra lại SPF, DKIM, DMARC của tên miền, chứ không phải gửi lại thư.
Muốn giảm tỉ lệ bounce ngay từ đầu, nền tảng gửi ổn định và cấu hình xác thực đúng chuẩn là điều kiện gốc. Xem chi tiết các gói dịch vụ email doanh nghiệp BizMaC để biết cấu hình nào đang có sẵn trên mỗi gói mailBus.
Lưu ý: Bài viết chia kinh nghiệm chung, còn mỗi doanh nghiệp một quy mô và một cách vận hành. Muốn biết cách nào hợp với trường hợp của bạn — chọn gói nào, làm theo thứ tự nào, chi phí ra sao — chuyên viên BizMaC tư vấn và làm giúp bạn phần kỹ thuật.
Để BizMaC dựng website cho doanh nghiệp bạn
Giao diện chuẩn UX, cấu trúc chuẩn SEO, chạy mượt trên di động và dễ tự quản trị sau khi bàn giao. BizMaC làm website cho doanh nghiệp Việt từ năm 2007, đi kèm hướng dẫn vận hành chứ không bàn giao xong là hết.
