從產品團隊視角偵錯：為什麼使用者顯示「已寄出」但對方「收不到」？

一、先釐清：你說的「已寄出」是哪一種成功？

很多爭論都來自語意不清。產品畫面顯示「已寄出」，可能只是以下其中一種：

• 前端送出成功：HTTP 請求成功送到你的 API（例如 200/202），但後端尚未真的寄出。
• 後端入列成功：信件被放進 queue（或 job 系統），等待寄送；此時仍可能因重試、限流或錯誤被延後甚至丟棄。
• 寄信服務接受成功：你呼叫 ESP/MTA，對方回 2xx 接受；這通常代表「我收到了，我會嘗試投遞」，不代表收件端已接收。
• 收件端 MX 接受成功：對方郵件伺服器回 250 OK，代表已接受；但仍可能進隔離區、被規則移到垃圾信或被企業閘道扣留。
• 落到收件匣：這是使用者真正感受到的「收到」。但這一步最不可控，因為牽涉到收件端策略與使用者端規則。

產品團隊最重要的第一步是：把 UI 上的「已寄出」改成與系統真實狀態一致的語意。若你只能保證「已送出請求」，就不要宣稱「已寄出」。你可以用更準確的文字，例如「已送出，系統處理中」或「已排程寄送」。這不只是文案，而是降低客訴成本與誤會的核心設計。

二、用投遞鏈拆解：問題可能卡在哪一段？

把整個流程想成一條鏈：Client → API → Queue/Worker → MTA/ESP → DNS 驗證 → 收件端 MX/閘道 → 使用者收件匣。每一段都有特定失敗型態與對應證據。

1) Client / 前端層

• 表單重送、網路中斷導致使用者看到成功但其實未送出。
• 前端樂觀 UI（optimistic UI）先顯示成功，後端其實回錯誤。
• 附件過大、內容過長，前端未提示限制，後端拒絕。

前端該提供的最低限度是：一個可追蹤的message_id（或 request_id）回傳給 UI，讓客服能用一個 ID 追完整段證據。

2) API / 後端層

• API 回 202 入列，但 worker 未啟動、佇列卡住、或錯誤重試爆炸。
• 風控或限流直接拒絕寄送（例如同 IP/同帳號短時間寄太多）。
• 模板渲染失敗、變數缺漏、內容被過濾器阻擋（例如含危險連結）。

後端要留痕的關鍵：接收請求時間、入列時間、出列時間、實際呼叫寄信服務時間、重試次數、最終狀態與錯誤碼。

3) MTA / ESP（寄信服務）層

這一段常見「你以為成功」的陷阱：ESP 回 202/200 並不等於投遞成功。你需要依賴 provider 的事件回呼或 log（accepted / delivered / deferred / bounced / complaint）。

• accepted：服務接受你的信件。
• delivered：收件端 MX 接受（通常是 250）。
• deferred：延遲投遞（灰名單、暫時性錯誤、流量控制）。
• bounced：退信（硬退、軟退）。
• complaint：被回報為垃圾信，對送達率影響很大。

產品面需要把「事件流」當成一等公民：如果你沒有拿到 delivered/bounced 的事實，只能說你「嘗試寄出」，不能說「對方收不到就是對方問題」。

4) DNS 驗證（SPF / DKIM / DMARC）層

很多「收不到」其實是被收件端政策擋掉或丟進隔離。常見原因包括：

• SPF 設錯：寄信 IP 不在允許清單，或 include 鏈太深。
• DKIM 簽章失敗：key 不一致、簽章被修改、或 selector 錯誤。
• DMARC policy 太硬：p=reject 但 alignment 沒做好，導致直接拒收。
• 反向 DNS / HELO 不一致：部分企業閘道很在意基本信譽。

產品團隊要做的不是背規格，而是建立一個「驗證狀態面板」：每個寄件網域的 SPF/DKIM/DMARC 狀態、最近失敗率、以及對 deliverability 的影響。這樣遇到事故時才能快速判斷是不是設定問題。

5) 收件端策略（垃圾信、隔離、企業閘道、規則）

即使 delivered 了，使用者仍可能「看不到」。常見情況：

• 進垃圾信匣或促銷分頁（使用者只看主收件匣）。
• 公司郵件閘道隔離（需 IT 放行）。
• 使用者設了規則自動歸檔、轉寄或刪除。
• 收件箱爆滿、或收件端暫時性問題導致延遲。

因此在客服流程上，必須有一套固定問法：請使用者確認垃圾信、促銷分類、全域搜尋、規則/封鎖清單，以及是否使用公司信箱（公司信箱常有閘道與隔離）。

三、事故處理的標準流程：用「三步證據法」快速定性

當使用者回報「沒收到」，不要先猜原因。先用三步把事件定性：

Step 1：確認系統內是否真的生成了信件

• 查 message_id / request_id 是否存在。
• 查 recipient、寄件網域、模板、語系、主旨是否正確。
• 查是否被風控擋下（例如可疑活動、限流、黑名單）。

Step 2：確認寄信服務是否「接受」與「投遞」

• accepted 有沒有？時間點是什麼？
• delivered 有沒有？如果沒有，是 deferred 還是 bounced？
• 若 bounced，記下 SMTP 回應碼與分類（硬退/軟退）。

Step 3：如果 delivered 了，轉向收件端與使用者端排查

• 請使用者全域搜尋信件主旨/寄件者。
• 請使用者檢查垃圾信、促銷分類、隔離/垃圾郵件報告。
• 若是企業信箱，請 IT 查閘道隔離紀錄或政策阻擋。

只要這三步走完，你就能把大部分事件歸類成：系統未產生／系統產生但未投遞／已投遞但未進收件匣。不同類型對應不同的修復與對外說法，避免所有事件都用「可能進垃圾信」草草帶過。

四、產品團隊該看哪些關鍵指標？（可做成儀表板）

如果你每次都靠人工查 log，事故永遠解不完。你需要把寄信系統做成「可觀測產品」。建議至少有以下指標：

• Acceptance rate：寄信服務接受率（accepted / attempted）。
• Delivery rate：投遞成功率（delivered / accepted）。
• Bounce rate：退信率（bounced / accepted），並分硬退與軟退。
• Deferred rate：延遲率（deferred / accepted），觀察是否突然上升。
• Time to deliver：從 accepted 到 delivered 的延遲分佈（P50/P90/P99）。
• Complaint rate：垃圾信回報率（complaint / delivered）。
• Template-level health：按模板或信件類型拆（驗證信/重設密碼/通知/行銷）。
• Domain-level authentication status：SPF/DKIM/DMARC 的通過率與失敗率。
• Provider breakdown：按收件端提供者（Gmail/Outlook/企業域）拆解送達差異。

有了這些指標，產品就能做出「事故警報」：例如某收件域的 deferred 突然飆升、某模板 bounce 突然上升、某網域 DKIM 失敗率異常。這些都比單純看 5xx 錯誤更能提前抓到問題。

五、常見根因與快速處置（產品團隊版）

1) API 成功但信件根本沒出列

特徵：使用者回報沒收到；你查後端只看到入列，沒有呼叫 ESP 的紀錄，或 worker 落後很久。

• 檢查 queue 堆積、worker 健康狀態、重試風暴、依賴服務（模板、DB、KMS）是否變慢。
• 產品處置：把 UI 從「已寄出」改成「處理中」，並提供「重新寄送」按鈕與冷卻時間。
• 客服話術：先確認系統處理狀態，提供明確的重新寄送時機。

2) ESP accepted 但大量 deferred（延遲）

特徵：突然一批使用者說收不到，但過一段時間又收到；或只在特定企業域發生。

• 常見原因：灰名單、收件端限流、寄件 IP 信譽下降、尖峰流量。
• 工程處置：降低速率、分批投遞、調整重試策略（避免同一收件域被打爆）。
• 產品處置：對使用者顯示「可能延遲」的訊息，並提示可先查垃圾信與稍後再試。

3) 硬退（Hard bounce）暴增：地址不存在或被拒收

特徵：bounced 且錯誤多為 550/5.1.1 類型；通常是用戶填錯信箱、或收件端直接拒收。

• 產品改進：信箱輸入提示與驗證（常見拼字、域名補全），降低錯誤率。
• 流程設計：在「寄出」後提供更清楚的提示：收不到可檢查拼字、重新輸入信箱。
• 客服收斂：硬退直接可判定是地址問題，避免無限追 log。

4) 認證問題（SPF/DKIM/DMARC）導致拒收或進隔離

特徵：某些收件服務（尤其企業域）突然大幅收不到；或 delivered 下降，bounced 上升。

• 檢查：近期是否換寄信服務、換 IP、改 DNS、換 DKIM key、修改 From/Return-Path。
• 處置：修正 SPF include、重新部署 DKIM、調整 DMARC policy（先從監控與隔離逐步收緊）。
• 產品策略：建立「寄件網域健康檢查」流程，避免在高峰期改 DNS。

5) 已 delivered 但使用者仍找不到

特徵：ESP 顯示 delivered，但使用者堅持沒收到。

• 先請使用者全域搜尋主旨/寄件者，並檢查垃圾信、促銷分類、封鎖清單、規則。
• 若是企業信箱，請 IT 查閘道隔離與政策（常見：連結被判定風險、附件被阻擋）。
• 產品改進：在信件主旨、寄件者顯示名稱上做一致化，降低「被忽略」機率；同時提供「重寄」與「改用其他信箱」的低摩擦流程。

六、把偵錯變成產品能力：你需要哪些資料欄位？

如果你的系統沒有一份「郵件事件紀錄」，每一次事故都會像第一次。建議產品與工程共同定義最小可行資料模型，至少包含：

• message_id：全鏈路唯一 ID（UI/客服/工程共用）。
• user_id / workspace_id：事件歸屬。
• recipient：收件者（可加密或遮罩保存）。
• template_key：信件類型（驗證、重設密碼、通知等）。
• created_at / queued_at / sent_at：各節點時間戳。
• provider_message_id：ESP 回傳的 ID，方便對帳。
• status：created/queued/accepted/delivered/deferred/bounced/failed。
• smtp_code / reason：退信碼或延遲原因摘要。
• ip_pool / sending_domain：寄件來源，方便定位信譽問題。

產品團隊最常忽略的是「客服可用性」：資料不只要存在，也要能被客服在一個頁面看懂。你可以做一個簡單的內部查詢頁：輸入 email 或 message_id，就能看到狀態時間線與建議話術。

七、對外溝通怎麼說？避免把技術問題講成互相甩鍋

當使用者說「收不到」，你不該只回「請查垃圾信」。更好的做法是把不確定性說清楚，同時提供下一步。以下是一個更產品化的說法：

我們已收到您的寄送請求，目前系統顯示信件已送交郵件服務處理。由於不同信箱服務的過濾規則不同，信件可能會被延遲或分類到垃圾信/促銷分類。建議您先使用全域搜尋查詢信件主旨與寄件者，並檢查垃圾信匣與封鎖/規則設定。若仍未找到，您可以在此重新寄送或改用其他信箱，我們也可以協助您確認寄送狀態。

這段話的關鍵是：你提供「已送交處理」的事實、承認收件端存在變數、給出具體操作、並提供替代方案（重寄/換信箱）。對使用者來說，這比單一句「請看垃圾信」更有安全感。

八、預防勝於救火：產品設計上可以提前做什麼？

• 重新寄送（Resend）：提供按鈕與冷卻時間，避免連點造成限流與信譽下降。
• 改信箱（Change email）：讓使用者能快速換收件信箱，不要卡死在收不到。
• 狀態透明：把「處理中/已送交郵件服務/已投遞/退信」做成狀態時間線。
• 內容最佳化：避免過多縮址、可疑關鍵字、或導向風險頁面；主旨清楚、寄件者一致。
• 可觀測性：把事件、延遲、退信碼全部落地，並做成自動告警。
• 投遞策略：尖峰分批、IP 池管理、分收件域限流，降低 deferred。

對產品團隊來說，郵件不是單純的「功能」，而是一條影響轉換率、留存率、甚至信任感的關鍵通路。越早把它產品化，你越少被「明明寄了怎麼沒收到」拖累整個團隊節奏。

結語：把「收不到」變成可被工程化解決的問題

郵件投遞看似不可控，但只要你把鏈路切清楚、把事件留痕做完整、把 UI 文案與狀態對齊，就能把大量爭吵變成可量化、可迭代的改善。下一次再遇到「已寄出但未收到」，你不需要靠猜；你可以用同一套流程拿到證據、快速定性、快速修復，並把學到的教訓沉澱成儀表板與產品設計。

對使用者而言，他們要的不是你解釋 SMTP 的細節，而是「我現在該怎麼辦」以及「你們有在掌控狀況」。而對產品團隊而言，這正是把信任做成產品的一部分。