英文退信通知看不懂：先留下哪些原文，才能交給 IT 判讀？
看不懂英文退信通知時，先保留完整原檔，再摘錄時間、Action、Status、SMTP 回覆與伺服器說明，將原文、中文暫譯和你的推測分開。不要只把 rejected 翻成「上黑名單」，也不要刪掉看不懂的英文。這篇要完成一份 IT 可核對的雙語摘要，不是教業務靠一個代碼自行修設定。
- 使用者摘要與管理者診斷分開讀，通知寄出者不一定是拒收決定者。
- Status 是狀態分類，Action 是對該收件者採取的動作，不能互相代填。
- 原始 SMTP 文字完整保留；中文可以暫譯，但不取代原文。
- 4.x.x 與 5.x.x 是分類線索，不是重寄排程或永久刪除地址的命令。
- 不知道原因就寫待確認，交由管理者查紀錄，不把工具翻譯當成已證實根因。
先找到原信和退信的關係，不只看英文標題
退信標題可能寫 Delivery failed、Undeliverable 或其他字樣，但它們不足以定位公司哪次投遞。先找出原寄件時間、收件者、內容版本和退信收到時間，建立內部事件編號。若同一段時間寄了多封，不要把其中一封的錯誤複製到其他事件。
通知的寄出來源也需要保留。有些 NDR 由寄件端系統產生，內容卻描述另一個系統的拒絕回覆；只看通知來自哪個網域，容易把責任分錯。Microsoft 的官方文件把產生通知的系統與診斷資訊分開說明，整理時也應保留這種區別。
原始檔另存到公司核准位置，外部分享先做最小摘要。若通知同時包含多個失敗收件人，各人可能有不同狀態，先按收件者或事件分組。遮罩帳號後使用一致代號，避免因代號不同而以為有兩個人，也不要把客戶往來全文當成翻譯素材。
- 原信：事件編號、寄件時間、收件者代號與版本。
- 退信：收到時間、通知產生系統與檔案位置。
- 對應：哪些診斷文字屬於哪個收件者。
- 限制：原信尚未找到或關係未核對，直接註記。
保留五類英文欄位，用中文說明它在回答什麼
先找 Action、Status 與 Diagnostic-Code；如果格式不同，就保留畫面原有標題及附近上下文，不自行補造不存在的欄位。再找產生通知和相關遠端系統的資訊，讓 IT 知道哪一行是摘要、哪一行是原始回覆。不同服務的排版未必相同，不能把找不到欄位當成它一定沒有錯誤。
Action 說明該通知對特定收件者報告的動作，例如 failed 或 delayed；Status 是另一個狀態欄位。兩者不應只留其中一個，也不把其中一個翻成另一個。原通知若有時間、重試或其他資訊，也一併保留，讓管理者判斷事件是否仍在處理。
Diagnostic-Code 可能含 SMTP 回覆與文字說明。Generating server 或 Reporting-MTA 有助於辨認通知來源；Remote server 或 Remote-MTA 則需要按實際格式和內容判讀。這些名稱可以加中文註解，但不要把它們統一改成「出問題的伺服器」。
- Action：報告的動作，保留原值。
- Status：狀態碼，保留完整點分格式。
- Diagnostic-Code／SMTP response：原始回覆文字。
- Generating server／Reporting-MTA：通知或報告來源資訊。
- Remote server／Remote-MTA 與時間欄：保留原有上下文，不猜角色。
用狀態碼分類問題，但不把分類當成處理指令
RFC 3463 將增強狀態碼分成多個類別，其中 4.x.x 表示持續的暫時性失敗，5.x.x 表示永久性失敗類別。它們能幫助你提出問題，但還需要實際說明和事件紀錄。不要把「暫時」直接改寫為「明天一定成功」，也不把「永久」一律改寫成「收件地址不存在」。
同一個 5.x.x 類別可能有不同主題，像地址、安全性或政策等。讀到 5.7.1 時，不能只因為它是永久性類別就立刻刪除客戶帳號，也不能自動判定是 Spamhaus。先保留完整回覆，請管理者確認到底是哪個系統、哪項條件需要處理。
SMTP 回覆與增強狀態碼有時會並列，例如三位數回覆之後接點分格式。不要只保留前面或後面一半，更不要把兩者拆開後拼成另一個訊息。原信若沒有增強狀態碼，就如實保留可用文字，不靠翻譯工具猜出一個數字填進表格。
虛構片段：SMTP response＝550 5.7.1 Message refused by policy。可暫譯為「依政策拒收」，但這段示例沒有指出是哪項政策，更沒有提到某個黑名單。它不是實際服務商錯誤，也不能拿來推定所有 5.7.1 的原因。
把原文、暫譯與推測排成三欄，避免翻譯偷偷加結論
第一欄放原文，保留英文、代碼、必要主機與時間。第二欄用中文暫譯字面意思。第三欄寫待確認的問題，不寫尚未證實的原因。這個結構能讓懂技術的人校對，也能讓業務在不改動原始訊息的情況下理解目前進度。
常見詞彙要按上下文處理。rejected 只說有拒絕，不能單獨證明封鎖來源；policy 指某種規則或政策，不能自行補成公司或法規名稱；temporarily 也沒有承諾固定恢復時間。工具翻譯可以協助理解，但輸入內容應先處理敏感資料，而且原文不能因此被刪除。
若訊息含引號、方括號或一段網址，先保留原有形式並交管理者判斷用途。不要因為看不懂就去點擊，也不要把含收件帳號或識別參數的完整文字貼到公開工具。需要補查時，讓負責人確認哪些值必須保持精確，以及適合的交付方式。
虛構三欄摘要：原文＝Message refused by policy；暫譯＝依政策拒收；待確認＝哪個系統回覆、涉及哪項條件、需要哪一方查紀錄。不可改成「客戶把我們列入黑名單，請立即解除」，因為原文沒有這些資訊。
依動作與紀錄決定下一步，不用人工重寄填補未知
如果通知包含 delayed 等動作，先讓管理者確認平台是否仍有待處理工作，不要在不知道佇列狀態時人工寄出多份相同內容。若 Action 是 failed，也要配合狀態碼和說明理解這次事件，不能只看某個字就指定無限重試或永久停止所有聯絡。
摘要交給 IT 時，問題可以很具體：「請確認這段回覆由哪個系統產生、是否仍有待處理投遞，以及我方需補哪個欄位。」如果涉及收件端，再透過既有客戶窗口協助。資料不完整時，先補事件，不要求對方修改安全規則來配合你的翻譯。
虛構停止案例：業務只有「temporary error」兩個字的截圖，沒有日期、Action 或投遞索引。正確的下一步是取得完整通知和原信關係，暫停無目的重寄；不能把英文暫時性字眼當成明天自動恢復的承諾，更不能在 CRM 寫成已查明根因。
- 可以確認：通知中的原始動作、狀態與時間。
- 需要查核：平台佇列、實際回覆來源和對象。
- 交接窗口：寄件服務、收件服務或內部管理者。
- 停止條件：缺原文、缺事件對應或沒有新增資訊。
交付一段不超出證據的中文摘要
最後用幾句話整理：哪次投遞、收到什麼原始回覆、目前理解到哪裡、下一步問誰。對客戶的說明可以更短，但不要把未確認的原因講得像已完成診斷。若需要更正先前翻譯，保留版本與更正理由，讓其他同事知道哪一段仍可採用。
結案前核對 IT 回覆是否真的回答原問題。若只得到「已處理」，仍需知道處理對象、範圍與可驗證結果。本文不替各狀態碼指定固定等待時間，也不承諾重寄一定成功；必要的新測試要在雙方獲准、條件清楚的情況下進行。
Inbox Check 的受控落點觀察可補充郵件投遞結果，但它不會把英文錯誤翻譯成官方根因，也不能代替服務商日誌。先完成可追查的摘要，再決定需要哪種觀察，避免把工具評分、翻譯文字和真正的系統回覆混成一個結論。
官方資料查閱於 2026-10-18：RFC Editor「RFC 3463」，https://www.rfc-editor.org/rfc/rfc3463.html；「RFC 3464」，https://www.rfc-editor.org/rfc/rfc3464；Microsoft Learn「Email nondelivery reports and SMTP errors in Exchange Online」，https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online。本文引用狀態分類與通知欄位；三欄摘要、翻譯提醒與分派流程為編輯整理。
實際上可以用免費的收件匣到達率測試（check.live-direct-marketing.online）來驗證。
常見問題
5.x.x 就代表客戶信箱不存在嗎？
不是。這是失敗類別，還要讀完整細節；安全性、政策或其他問題也不能只靠開頭數字判定。
4.x.x 是否代表過一段時間一定能寄成功？
沒有這種保證。先核對動作、說明與平台狀態，由管理者決定是否和如何重試。
翻譯工具說是黑名單，能直接這樣回覆客戶嗎？
先對照原文有沒有指明資料集或對象。工具增加的判斷不能當成原始系統回覆。
只留下中文翻譯可以嗎？
不建議。保留原文、代碼和必要上下文，中文作輔助，讓 IT 能校對和回查。
英文通知缺某個欄位時，需要自行補上嗎？
不需要。記錄未見或未取得，保留現有文字，讓管理者判斷是否需要補件。