只有一家客戶收不到信，怎麼和對方 IT 查同一筆投遞？
只有一家客戶收不到信，應先固定特定帳號與投遞事件，確認信件停在寄件端、收件閘道，還是使用者信箱，再由既有業務窗口協助聯絡對方 IT。別家信箱收到，不足以證明客戶系統有錯；寄件驗證通過，也不能代替收件端紀錄。本文要完成一份雙方可對照的排查單，而不是教你要求全面放行。
- 先寫清楚是哪個帳號、哪次投遞，避免把單一事件擴大成整家公司故障。
- 寄件紀錄、驗證結果與收件端處置各有來源，分欄保留。
- 透過既有客戶窗口取得正式支援管道，不猜測個人 IT 信箱。
- 對方尚未查到事件時，先核對時間、出口與收件地址，不直接要求加白。
- 結案只涵蓋已核對的路徑與帳號，其他範圍保留待確認。
把「客戶沒收到」改寫成可以查核的事件
先請業務確認原話：對方沒有在主要收件匣看到、垃圾郵件匣也找不到，還是公司系統明確發出隔離通知？這些現象不是同一件事。若對方只說沒看到，就如實記錄，不替他補成「閘道已擋信」。也不要把沒有回覆當成沒有收到的證據。
再核對收件地址是否仍是雙方確認的窗口，是否有別名或轉寄，以及本次寄件時間和時區。台灣業務常以本地時間描述事件，供應商日誌可能使用另一個基準；兩邊要能換算到同一時段。名稱拼字、地址別名與時間窗口都先確認，再交給管理者搜尋。
把影響範圍寫成可證實的句子，例如「帳號 A 在這次投遞後未找到信件」。同家公司另一位同事成功收到，不代表帳號 A 的設定一致；反過來，一位同事沒收到，也不代表整個企業網域拒收。先保留範圍，之後有新事件再擴充。
- 事件編號、寄出時間、時區和內容版本。
- 雙方確認的收件帳號，以外部分享代號表示。
- 對方實際觀察：未找到、隔離通知或明確退信。
- 已知影響範圍，以及尚未查核的帳號或時段。
先從寄件端確認是否真的交到對方系統
請寄件管理者找出本次平台事件或伺服器紀錄，確認工作是否只是排入佇列，或已經嘗試對外投遞。若尚未對外投遞，就先在寄件端查原因，沒有必要請客戶搜尋不存在的收件事件。畫面上的已送出，需要和實際投遞紀錄對照。
若取得回覆，保留回覆的主機、時間、原始文字與事件索引。拒收和接受後找不到信，下一步不同。不要只把一個狀態碼翻譯成「對方封鎖」，也不要因為傳輸階段曾被接受，就替客戶填上已進主要收件匣。
Microsoft 的 NDR 官方文件區分產生通知的系統與相關診斷資訊。通知由寄件端產生，不代表拒收一定由寄件端決定。因此附件要保留能讓管理者判讀角色的資訊，不能只截通知上方的寄件者名稱，再把責任分派給那一方。
虛構紀錄：事件 A 的平台工作已執行，但管理者尚未找到對外回覆。此時對方未收到的原因仍待查，工單先交寄件服務商補足投遞紀錄，不要求客戶 IT 解除任何規則。
將驗證結果和收件閘道處置分成兩組證據
寄件端可以提供驗證設定或測試結果，收件端則掌握自己當次如何處理。兩者都值得保存，但不能互相取代。某個自有測試帳號顯示通過驗證，只能說明該次路徑與觀察，不能證明客戶的另一個閘道必須接受。
請管理者說明驗證結果來自哪個系統、哪封信與哪個時間點。若使用 Authentication-Results，還要確認由誰加入、是否在可信任範圍內。RFC 8601 提醒，出現這個標頭不代表內容自然有效；業務不應只搜尋到一個 pass，就把整封信填成驗證無誤。
收件端若提供隔離、規則或拒收資訊，把它另列為對方的觀察。沒有取得規則名稱，也不需要逼對方揭露整套防護設定；能確認事件是否出現、採取什麼處置，以及下一步由誰處理，就可以往前走。
- 寄件證據：路徑、出口、投遞事件與回覆。
- 驗證證據：測試信、評估系統、結果與時間。
- 收件證據：對方查得的事件、處置與可分享原因。
- 待確認：尚未取得的欄位，明確指定補件窗口。
透過既有客戶窗口，把問題送到正式支援管道
先向熟悉的業務聯絡人說明需要查核哪一筆郵件，詢問對方慣用的 IT 報修方式。不要到處搜尋員工地址、猜測管理者帳號，或把同樣的附件寄給多位不相干的人。對方可能需要由內部員工建立工單，就讓既有窗口代為提出。
報修摘要保持中性：什麼時間寄出、哪個帳號未找到、寄件端已確認什麼，以及希望對方查什麼。附件用遮罩版本，不附客戶往來全文、報價或公司完整名單。若對方管理者需要精確地址或 Message-ID，透過正式管道按必要性補件。
不要把聯絡目標寫成「請停用防護」或「請永久加白我方所有信件」。合理的請求是確認當次事件與處置，讓對方按自身政策評估。即使雙方有商業往來，仍不能把業務需求等同於修改安全規則的權限。
虛構聯絡文：您好，我們想確認事件 A 的投遞情況。郵件於台灣時間 10:15 寄出，您方窗口表示尚未找到；我方已保存投遞回覆與遮罩摘要。請問可否依貴公司的正式流程，協助 IT 查核該時段是否有此事件、是否隔離或拒收，以及需要我方補充哪些欄位？此文面不含實際客戶或真實事件。
依對方回覆選擇分支，不把未知寫成根因
若對方查到隔離事件，先確認它是否與本次郵件相符，再記錄對方可分享的處置與要求。若它查到接受，但使用者仍找不到，請對方確認後續路徑、帳號或資料夾；不要立刻回頭重複黑名單查詢，因為兩種證據回答的問題不同。
若對方完全查不到，先核對時間範圍、時區、地址與本次出口。沒有事件可能表示條件不一致，也可能還需要查其他中繼系統，不能直接結論為「對方日誌壞了」。把各自查過的位置列出，請管理者決定下一個查核點。
虛構停止情境：客戶不願提供內部紀錄，也沒有同意新的測試。這時保留已知範圍，透過雙方原已使用的聯絡方式處理必要業務，不持續寄送相同內容施壓。沒有合作查核條件的項目應維持未確認，而不是為了關單假設已恢復。
- 查到拒收：記錄原文及對方確認的處理窗口。
- 查到隔離：按對方正式流程處理，不代替對方操作。
- 查到接受：續查後段路徑與使用者觀察。
- 查不到：先核對查詢條件，再安排下一步。
用雙方約定的事件驗收，留下有限結論
若需要重測，先取得對方同意，固定寄件路徑、內容版本及測試帳號，並約好管理者可以查看紀錄的窗口。不要把整批客戶名單當成驗收工具。每次新投遞都有新的事件索引，結果能和對方查得的時間對上，才值得比較。
紀錄結論時寫出範圍，例如「事件 B 已由對方確認進入測試帳號 A 的指定資料夾」。沒有觀察到的其他帳號、其他出口或未來寄件，仍不在這個結論內。若只得到接受回覆，就只記傳輸接受，不擴大成全面送達。
需要補充不同收件系統的落點，可另由獲准帳號安排 Inbox Check 觀察。它不能讀取客戶的內部閘道日誌，也不能替客戶解除隔離。這份雙方排查單的價值，是讓每一項觀察都找得到來源、時間與下一個負責人。
官方資料查閱於 2026-10-18：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；RFC Editor「RFC 8601」，https://www.rfc-editor.org/rfc/rfc8601.html。本文的雙方工單與分支流程為編輯整理，不是任何服務商保證的處理時程。
實際上可以用免費的收件匣到達率測試（check.live-direct-marketing.online）來驗證。
常見問題
其他客戶收得到，能確定是這家公司的閘道有問題嗎？
不能。先核對這次路徑、帳號與投遞事件，再由收件管理者確認處置；不同收件系統的結果不能直接互相代替。
沒有退信，是不是代表對方已收信？
不能僅據此判定主要收件匣落點。請管理者核對投遞回覆，並由獲准的收件帳號確認實際情況。
可以要求客戶把我方網域全面加白嗎？
先請對方查核當次事件，讓其依安全政策決定。商業聯絡需求不等於修改對方安全設定的權限。
客戶 IT 查不到事件時，第一步做什麼？
先核對時區、時間範圍、收件地址、出口及事件索引，再由雙方管理者判斷是否需要查中繼系統。
Inbox Check 可以代替客戶 IT 查隔離紀錄嗎？
不能。受控落點測試可以補充觀察，客戶內部事件和隔離仍由其有權限的管理者查核。