Bounce email: cách đọc, và từng mã nghĩa là gì

Bounce là gì, và hai thời điểm nó xảy ra

Từ này được mượn từ thư giấy, và đó là hình ảnh sai. Không có gì thực sự đi ngược trở lại. Một thư được chuyển từ máy chủ này sang máy chủ khác, và máy chủ cuối cùng còn giữ nó mà không thể tống khứ nó đi sẽ viết ra một thư mới — gửi cho bạn, nói về thư cũ — và gửi thư đó thay vào đó. Mọi thứ bạn có thể biết đều nằm trong báo cáo ấy, và báo cáo đó chỉ tốt bằng đúng cái máy đã viết ra nó.

Nó có thể được tạo ra ở hai thời điểm rất khác nhau, và phân biệt được hai thời điểm ấy chính là phần lớn công việc chẩn đoán. Hai kết quả khác trông giống thất bại từ chỗ đứng của bạn nhưng thực ra không phải:

Vậy nên cụm “nó bị bounce” đang gọi tên cho hai thứ khác nhau. Một là lỗi do chính phần mềm của bạn hiển thị cho bạn, còn một là một lá thư do máy của người lạ viết cho bạn — và chỉ thứ hai mới có một báo cáo bên trong để đọc. Phần còn lại của hướng dẫn này nói về báo cáo đó.

Lý do thực sự nằm ở đâu

Một báo cáo giao nhận là một thư gồm ba phần, và hình dạng đó đã được cố định kể từ RFC 3464. Phần đầu tiên là lời xin lỗi, được cái máy gần bạn nhất viết ra cho một con người đọc. Phần thứ hai là khối mà máy có thể đọc được, và đây là phần duy nhất chứa sự thật. Phần thứ ba là thư gốc của bạn, hoặc chỉ tiêu đề của nó, để bạn biết được thư nào đã thất bại.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

Hãy đọc phần giữa theo thứ tự sau:

Final-Recipient:

Địa chỉ nào đã thất bại. Một báo cáo có thể mang một khối cho mỗi người nhận, nên với một thư gửi cho nhiều người, đây là cách để biết báo cáo đang nói về ai — và những người còn lại rất có thể đã nhận được thư.

Action:

failed là một bounce. delayed là một cảnh báo rằng máy chủ vẫn đang thử lại và chưa từ bỏ điều gì cả; bạn vẫn có thể nhận được một báo cáo thứ hai nói rằng nó đã thành công. relayed và delivered hoàn toàn không phải thất bại, và rất dễ bị đọc nhầm thành một thất bại.

Status:

Mã trạng thái mở rộng — ba con số, vốn dùng để phần mềm đọc chứ không phải để bạn đọc. Đây là phần có thể so sánh được giữa nhà cung cấp này với nhà cung cấp khác, điều mà các câu văn thì không bao giờ làm được.

Diagnostic-Code:

Dòng thực sự quan trọng. Đây là câu trả lời của chính máy chủ ở đầu bên kia, được trích dẫn nguyên văn, mang theo mã phản hồi của nó và bất kỳ câu nào người quản trị của nó đã viết. Mọi thứ phía trên nó chỉ là một cách kể lại; còn đây mới là bản gốc.

Remote-MTA:

Máy chủ nào đã nói điều đó. Đáng để liếc qua bất cứ khi nào thất bại liên quan đến định tuyến: một tên máy chủ bạn không nhận ra thường có nghĩa là thư của tên miền đó đang đi đến một nơi bạn không ngờ tới, hoặc một nơi mà trước đây nó từng đi đến nhưng giờ không còn nữa.

Câu văn ở ngay đầu báo cáo không phải là bằng chứng. Máy chủ gửi đi của chính bạn viết ra nó, bằng bất cứ cách diễn đạt nào phần mềm của nó vốn có sẵn, nói về một lỗi mà nó chỉ đang chuyển tiếp lại. Hai lời xin lỗi giống hệt nhau hoàn toàn có thể nằm phía trên hai dòng Diagnostic-Code: chẳng liên quan gì đến nhau, đó là lý do vì sao đọc một bounce từ trên xuống lại thường bị hiểu sai.

Hai con số, và chữ số quyết định tất cả

Một lời từ chối được viết như thế này, và đó là ba thứ tách biệt được nối với nhau bằng dấu cách:

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

550 là mã phản hồi: ba chữ số, được chính SMTP định nghĩa trong RFC 5321, và là phần mà giao thức cần để quyết định bước tiếp theo. 5.1.1 là mã trạng thái mở rộng từ RFC 3463, được thêm vào vì ba chữ số không diễn đạt đủ. Mọi thứ sau đó là văn bản tự do, do bất kỳ ai vận hành máy chủ đó viết ra, và không được chuẩn hóa bởi bất cứ điều gì cả.

Cả hai con số đều bắt đầu bằng cùng một chữ số, và chữ số đó chính là phán quyết:

Con số thứ hai là chủ đề — loại chuyện gì đã sai. Đây là cách nhanh nhất để xác định một mã bạn chưa từng thấy trước đây:

Bounce vĩnh viễn (hard bounce)

Một 5. Địa chỉ sai, không còn tồn tại, hoặc bị từ chối theo chính sách, và gửi lại đúng thư đó chẳng thay đổi được gì. Những người gửi thư hàng loạt loại bỏ một địa chỉ khỏi danh sách ngay từ lần đầu tiên, vì cứ tiếp tục gửi chính là điều khiến một tên miền gửi thư bị hạn chế ở khắp mọi nơi cùng một lúc.

Bounce tạm thời (soft bounce)

Một 4. Một hộp thư đầy, một máy chủ đang bận, một lần từ chối tạm thời theo chính sách. Nó được thử lại mà không cần ai can thiệp và thường sẽ đến nơi; bạn chỉ biết về nó nếu các lần thử lại hết hạn trước.

Không thuật ngữ nào trong hai thuật ngữ đó nằm trong bất kỳ đặc tả kỹ thuật nào. Chúng là cách nói tắt của ngành gửi thư cho chữ số đầu tiên đó, thứ thực sự quyết định tất cả — và cách nói tắt này đáng để biết, vì mọi công cụ đo khả năng gửi thư mà bạn từng được trao đều báo cáo bằng thuật ngữ đó.

Những mã bạn thực sự sẽ gặp

Có hàng chục mã trong sổ đăng ký mà IANA duy trì, và khoảng một chục mã trong đời sống thường ngày. Những mã dưới đây bao trùm gần như mọi bounce mà bất kỳ ai từng đọc:

Vẫn còn những mã nằm ngoài danh sách này, và tất cả chúng đều có ý nghĩa riêng, nhưng một mã bạn chưa từng thấy trước đây gần như luôn luôn là một mã .7. — chính sách của ai đó, được mô tả bằng lời của chính họ trên dòng bên cạnh.

Điều gì có thể và không thể bounce tại một địa chỉ tạm thời

Gần như không có gì — và điều đó đáng để nói rõ ra, vì ba thứ mà người ta thường mô tả là một bounce ở đây thực ra không phải vậy:

“User unknown” không thể xảy ra

Máy chủ chấp nhận mọi cái tên trên các tên miền công khai của nó. anything@grabmail.io là một địa chỉ hợp lệ trước cả khi có ai gõ ra nó, vì không có danh sách hộp thư nào để đối chiếu — nên một 5.1.1 từ GrabMail là thứ không hề tồn tại. Cách email tạm thời vận hành bên dưới có đầy đủ cơ chế đó.

Hết hạn không phải là một bounce

Một thư bị xóa 5 ngày sau khi đến nơi, và đến lúc đó máy chủ gửi đã được báo 250 từ lâu và đã quên hẳn toàn bộ cuộc trao đổi. Không ai được thông báo cả, vì không có gì thất bại: thư đã được gửi thành công, rồi sau đó bị xóa. Hộp thư tồn tại bao lâu là hướng dẫn cho nửa còn lại của câu chuyện.

Một biểu mẫu từ chối địa chỉ không phải là một bounce

Không có thư nào được gửi đi cả. Trang web đó đã đối chiếu tên miền với một danh sách và từ chối biểu mẫu; không có gì từng chạm tới một máy chủ thư, và không có gì để đọc. Vì sao biểu mẫu đăng ký chặn email dùng một lần là một vấn đề khác, với một tập câu trả lời khác.

Im lặng cũng không phải là một bounce

Nếu có thứ gì đó bạn đang chờ mà không bao giờ đến, và không ai gửi cho bạn một báo cáo, thì thất bại — nếu có — đã xảy ra ở phía gửi, nơi bạn không thể nhìn thấy. Thư không đến nơi đi qua các nguyên nhân theo đúng thứ tự đáng kiểm tra.

Điều đó chỉ để lại đúng một lời từ chối thật sự, và đó là ngưỡng dung lượng. Một máy chủ gửi báo trước kích thước ngay từ đầu sẽ bị từ chối ngay lập tức, trước khi một byte nào được lưu lại:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Một bên gửi không báo trước kích thước sẽ nhận được câu trả lời tương tự ở cuối thư thay vào đó, một khi số byte đã được đếm xong. Dù theo cách nào thì mã cũng là 5.3.4, không có gì được lưu lại, và một con người thật sự sẽ được chính hệ thống thư của họ báo cho biết — đó chính là toàn bộ lý do để từ chối ngay tại cổng thay vì chấp nhận rồi vứt đi.

Không có gói dịch vụ nào và không có tiêu đề nào có thể nâng ngưỡng đó lên, và không có bounce nào khác ở đây: không có hạn ngạch thư đến, không có giới hạn tốc độ, không có từ chối vì ai đó đã dùng cái tên này rồi. Trên một tên miền dùng chung, hai người gõ cùng một cái tên đơn giản là sẽ dùng chung một hộp thư, đây là một đặc tính về quyền riêng tư chứ không phải về việc gửi nhận thư.

Bounce trên một tên miền bạn vừa mới trỏ về đây

Trỏ một tên miền vào một hộp thư catch-all chỉ là một bản ghi DNS, và gần như mọi bounce mà việc đó tạo ra thuộc về khoảng thời gian quanh lúc thay đổi, chứ không phải do bản thân việc thiết lập. Có năm trường hợp, và chúng trông khác hẳn nhau:

1. Trước khi bản ghi tồn tại. Một tên miền không có MX và không có bản ghi địa chỉ nào để dự phòng sẽ trả cho bên gửi 5.4.4 hoặc 5.1.2: không có nơi nào để gửi đến và không có gì đáng để thử lại.
2. Trong lúc thay đổi đang lan ra. Những bên gửi đã tra cứu bản ghi từ trước sẽ giữ câu trả lời cũ cho đến khi TTL của nó hết hạn. Một bounce trong khoảng thời gian này nêu tên máy chủ cũ trên dòng Remote-MTA:, và đó chính xác là cách để phân biệt nó với một bản ghi bạn đã cấu hình sai.
3. Khi nó đã lan xong. Mọi cái tên trên tên miền đều được chấp nhận, nên “user unknown” cũng không còn có thể xảy ra ở đó nữa. Một bản ghi, độ ưu tiên 10, trỏ tới smtp.grabmail.io, và không cần công bố gì thêm để thư có thể đến nơi.
4. Nếu tên miền từng công bố một null MX. Các tên miền chưa dùng đến thường mang bản ghi có nghĩa là “tên miền này không bao giờ nhận thư”. Những bên gửi đã lưu bản ghi đó vào bộ nhớ đệm sẽ trả về 5.1.10 cho đến khi nó hết hạn, bất kể sau đó bạn đã công bố gì.
5. Nếu tên miền cũng gửi thư đi. Một 5.7.26 trên thư gửi đi không liên quan gì đến những điều trên cả — đó là do SPF hoặc DMARC của chính bạn không bao trùm được bất cứ thứ gì đã gửi ra thư đó. Hướng dẫn dành cho tên miền chỉ nhận thư là trường hợp nghiêm ngặt; một tên miền vừa gửi vừa nhận cần một lộ trình triển khai theo từng giai đoạn thông thường hơn.

Đọc bản ghi đó trả lời được phần lớn câu hỏi trên trước khi ai phải đọc một bounce nào cả:

$ dig +short MX yourdomain.com

Câu trả lời phải là một dòng duy nhất: độ ưu tiên, rồi đến máy chủ, rồi một dấu chấm ở cuối. Bất cứ điều gì khác — hai dòng, một máy chủ lạ, hoặc không có gì cả — chính là bounce mà bạn sắp nhận được, chỉ sớm hơn ba phút. Trỏ tên miền của riêng bạn về đây là toàn bộ phần thiết lập, và ba bản ghi ngăn chặn giả mạo là những gì cần công bố một khi thư đã bắt đầu đến nơi.

Một bounce cho một thư bạn chưa từng gửi

Nó đến trông y hệt như một báo cáo thất bại bình thường, trích dẫn một thư bạn chưa từng thấy, gửi cho một người nhận bạn chưa từng nghe tên. Không có gì bị xâm nhập cả. Ai đó đã gửi thư với địa chỉ của bạn được ghi vào envelope làm người gửi, một máy chủ nhận đã nhận thư đó trước khi phát hiện ra nó không thể gửi tiếp, rồi làm đúng việc cần làm với một thư thất bại: viết một báo cáo và gửi nó cho người gửi đã được ghi trong thư. Mà người đó chính là bạn.

Tên gọi cho hiện tượng này là backscatter, và điều nó chứng minh đáng để nói thẳng ra: chẳng chứng minh được gì về hộp thư của bạn cả. Giả mạo một người gửi trong envelope không cần quyền truy cập vào bất cứ thứ gì — đó chỉ là một dòng được gõ vào trong một phiên trao đổi. Bất kỳ ai làm việc đó chỉ cần địa chỉ của bạn và không cần gì khác, và rất có thể họ chỉ đoán ra nó.

Ba điều sau đây phân biệt nó với một bounce thật chỉ trong khoảng mười giây:

• Thư được trả lại không phải của bạn. Phần thứ ba của báo cáo mang theo bản gốc, hoặc ít nhất là tiêu đề của nó. Nếu bạn chưa từng viết nó, bạn đã không gửi nó, và mọi thứ còn lại trong báo cáo là chuyện của người khác.
• Chuỗi Received: bắt đầu từ một nơi bạn chưa từng dùng. Hãy đọc nó từ dưới lên trên: dòng thấp nhất là cái máy thực sự đã bơm thư vào hệ thống, và đó sẽ không phải là nhà cung cấp của bạn. Đọc tiêu đề email nói về chiều đọc này và vì sao phần dưới cùng mới là phần trung thực.
• Ngày tháng không khớp nhau. Backscatter thường báo cáo về một thư đã được gửi từ hàng giờ hoặc hàng ngày trước khi báo cáo đến được với bạn, từ một hàng đợi vẫn đang thử lại chiến dịch của người khác kể từ đó.

Không có gì để sửa và không có gì để trả lời cả. Nếu địa chỉ đó thuộc về một tên miền bạn sở hữu, việc công bố SPF và DMARC sẽ giảm bớt nó theo cách duy nhất thực sự có tác dụng: một máy chủ nhận kiểm tra chính sách của người gửi trước khi chấp nhận sẽ từ chối thư giả mạo ngay trong phiên trao đổi và không bao giờ tạo ra báo cáo cho bất kỳ ai. Ba bản ghi trên một tên miền chỉ nhận thư là phiên bản nghiêm ngặt nhất của cách đó, và bỏ xa các cách khác về độ dễ công bố.

Một cái tên ngắn trên một tên miền công khai dùng chung sẽ hứng chịu nhiều thứ này hơn một địa chỉ riêng tư, vì cùng một lý do khiến nó hứng chịu nhiều thư rác hơn: nó dễ đoán, và một kẻ giả mạo chọn người gửi trong envelope không nhắm riêng vào bạn. Đây là tiếng ồn về chuyện của người khác, và không như thư rác, không có nút bấm nào huấn luyện được điều gì ở đây cả — các công cụ chống spam thực sự làm được gì là hướng dẫn nói về những nút bấm thực sự có tác dụng.

Thứ tự để đọc một bounce

1. Hãy xác định bạn đang cầm loại nào. Một lỗi ngay trong ứng dụng thư của bạn tại khoảnh khắc bạn bấm gửi là một lời từ chối. Một thư từ MAILER-DAEMON đến sau đó là một báo cáo, và chỉ báo cáo mới có gì đó bên trong để đọc.
2. Kiểm tra xem nó có đúng là về một thư bạn thực sự đã gửi hay không. Bản sao được trả lại nằm ở phần thứ ba. Nếu nó không phải của bạn, đó là backscatter, và bạn xong việc rồi.
3. Hãy mở nguồn thư dạng thô. Lời xin lỗi ở đầu chỉ là cách diễn đạt có sẵn của máy chủ chính bạn, không phải là lý do thật, và khối mà máy có thể đọc được không được hiện ra mặc định ở bất cứ đâu.
4. Hãy tìm Status: và đọc chữ số đầu tiên. Một 4 vẫn đang được thử lại và có thể tự thành công; một 5 là cuối cùng và sẽ không có gì xảy ra thêm nữa.
5. Hãy đọc Diagnostic-Code:. Đây là câu văn của chính đầu bên kia, và là nơi duy nhất nêu tên thật sự quy tắc đã từ chối bạn.
6. Hãy xác định vị trí của chữ số thứ hai. .1. là địa chỉ, .2. là hộp thư, .4. là tuyến đường, .7. là chính sách của ai đó. Thường như vậy là đủ để biết đây là vấn đề của ai.
7. Hãy hành động theo đúng vấn đề của ai. Một thất bại về địa chỉ được sửa bằng cách có đúng địa chỉ; một thất bại về định tuyến bằng cách sửa DNS; một thất bại về chính sách bằng cách đáp ứng chính sách đó, hoặc bằng cách nhờ người ở phía bên kia xem lại nhật ký của chính họ — nơi cùng một lời từ chối đó được ghi lại dài hơn nhiều so với những gì họ đã gửi cho bạn.

Có hai điều không bao giờ là câu trả lời. Gửi lại nguyên văn thư đó sau một 5 chỉ lặp lại đúng lời từ chối đó, và nếu làm đủ nhiều lần, sẽ làm hại uy tín của tên miền gửi ở khắp mọi nơi cùng một lúc. Và trả lời báo cáo đó sẽ không đến được với ai cả: nó đến từ một người gửi trong envelope trống rỗng, và chính đó là lý do duy nhất khiến nó có thể được gửi đến bạn ngay từ đầu.

Câu hỏi