在產品上線或功能改版時，最容易踩雷的其中一個環節，就是郵件送達率（Email Deliverability）。你在後台看到「寄送成功」，但使用者回報「收不到驗證碼、OTP、重設密碼信、通知信」，甚至連垃圾郵件匣都沒有，這種狀況往往會直接打斷註冊與登入流程，導致轉換率掉一大截。
送達率的麻煩在於：它不是單一問題，而是一條鏈。從你的系統呼叫寄信服務開始，到 MTA（Mail Transfer Agent）投遞、對方收件伺服器接收，再到收件匣分類，每一段都可能出錯。更現實的是：錯的時候常常沒有明顯錯誤訊息，你只能從退信、log、header、DNS、收件端行為慢慢拼出真相。
這篇文章會用「常見失敗模式」的方式整理送達率測試時最常遇到的問題，並給你一套從外到內、可落地的排查流程。你不需要一次把所有郵件學術理論讀完，只要照著步驟做，通常就能快速縮小範圍，找到真正的卡點。
送達率測試的核心概念：你要分清「送出、送達、進收件匣」
很多團隊把「API 回傳 200」當成寄信成功，這其實只是你的系統把信交給寄信端而已。真正的送達率要拆成三層：
- 送出（Sent / Accepted）：你的寄信服務或 SMTP 接受了郵件。
- 送達（Delivered）：對方收件伺服器接收並回覆成功碼。
- 進收件匣（Inbox Placement）：信件沒有被丟到垃圾郵件、促銷分類、或被靜默丟棄。
測試時你必須同時觀察這三層，不然很容易「以為修好了」，但其實只是從 A 問題變成 B 問題。
常見失敗模式 1：DNS 設定缺漏或錯誤（SPF / DKIM / DMARC）
如果你的網域是新網域、或剛換寄信服務，最常見的第一個地雷就是 DNS。這類錯誤通常會導致：
- 信件被直接拒收（hard fail）
- 信件被放進垃圾郵件匣（soft fail）
- 收件端不明原因延遲或靜默丟棄
SPF 常見錯法
- 沒把實際寄信來源加入：你以為用 A 平台寄，其實你同時有 B、C 來源（例如 app、CRM、客服系統）。
- 多筆 SPF TXT：同一個網域放了兩筆以上 SPF，很多收件端會判定為 permerror。
- include 太多導致查詢超限：SPF 解析有 DNS lookup 次數限制，超過就可能 fail。
- ~all 與 -all 用錯：政策太嚴會導致合法信源也被擋；太鬆則影響信譽與風險控管。
DKIM 常見錯法
- selector 打錯：平台要求的 selector 與 DNS 設定不一致。
- key 沒更新或被覆蓋：輪替（rotate）後舊 key 還在用，或 DNS 沒同步。
- 簽名對不上 From 網域：寄信網域、簽名網域、回覆網域不一致，導致驗證失敗。
DMARC 常見錯法
- p=reject 太早上線：在 SPF/DKIM 還沒穩定對齊前就拒收，會大量掉信。
- alignment 沒對齊：SPF/DKIM pass 了，但與 From 網域不對齊，DMARC 仍可能 fail。
- rua 報表沒看：DMARC 報表本來就是用來抓漏信源與偽冒行為，不看等於失去雷達。
排查建議：送達率測試第一步先把 DNS 的 SPF、DKIM、DMARC 釐清，並確認你每一個實際寄信來源都被涵蓋。很多「收不到」其實在這一步就能解掉一半。
常見失敗模式 2：新網域 / 新 IP 信譽不足（Domain/IP Reputation）
你什麼都設定對了，仍然會收不到，尤其在剛上線、剛換網域、剛換寄信供應商時特別常見。原因是：收件端（尤其大型信箱服務）會用信譽來判斷你值不值得信任。
典型症狀
- 小量測試時能收到，大量一寄就開始掉
- 某些信箱收得到，某些信箱完全收不到
- 同樣內容，換一個 From 網域就差很多
- 信件偶爾進收件匣、偶爾進垃圾匣，波動很大
常見原因
- 新網域沒有歷史：收件端對你沒有足夠信任資料。
- 共享 IP 被連坐：你用的寄信平台是 shared IP，同網段有人濫寄會拖累你。
- 突然爆量：從 0 變成一天寄幾萬封，像突然冒出的濫寄者。
實務建議：新網域需要「漸進式放量」與「穩定的寄送模式」。先把交易型郵件（驗證、重設密碼）與行銷型郵件分開，用不同子網域或不同寄信設定，避免互相拖累。
常見失敗模式 3：灰名單（Greylisting）造成延遲，看起來像「沒收到」
灰名單不是拒收，而是一種「先暫時拒絕，看看你會不會重試」的策略。對方收件伺服器可能回覆暫時性錯誤碼，要求你的寄信端稍後再投遞。
這會造成一個很尷尬的現象：你在產品裡期待 OTP 立刻抵達，但收件端把你延遲 2～15 分鐘，使用者就會覺得整個系統壞了。
典型症狀
- 同一封信晚到，但最終會到
- 某些公司信箱（自建郵件伺服器）特別常發生
- 低頻率時沒事，遇到尖峰時延遲明顯
排查建議：查看寄信端的重試策略與投遞 log，確認是否出現暫時性拒收（例如 4xx）。產品上也建議加入「重新寄送」與「提示可能延遲」的 UX，避免使用者在等待期間反覆點擊造成更多寄送壓力。
常見失敗模式 4：速率限制與短時間大量寄送（Rate Limiting / Throttling）
OTP、驗證碼、登入通知這類信件非常容易遇到速率限制，因為它們通常集中在短時間爆發。收件端或寄信平台可能會做節流，導致：
- 部分信件被延遲投遞
- 部分信件被暫時拒收（4xx）
- 嚴重時被判定為異常行為而封鎖一段時間
常見觸發原因
- 同一收件網域短時間大量 OTP（例如某企業內部員工同時登入）
- 被機器人攻擊，反覆觸發「寄驗證碼」
- 前端重送機制做得太積極，變相 DDoS 自己的寄信能力
實務建議：在產品層加上防濫用措施（冷卻時間、行為風控、captcha 或風險評分），同時在寄信端做佇列與節流，讓尖峰變得平滑。對 OTP 類郵件，穩定比瞬間爆量更重要。
常見失敗模式 5：內容觸發垃圾信規則（Content-Based Filtering）
你可能完全沒想到：同樣是交易型郵件，只因為文字、連結、格式或語氣不同，就會被判為垃圾信。尤其是「驗證碼」這種看起來很制式的內容，反而容易被大量濫用者模仿，導致過濾規則更敏感。
典型踩雷點
- 過多的感嘆號、全大寫、促銷語氣：即便你不是行銷信，也容易被誤判。
- 短網址或可疑跳轉：某些短網址域名信譽不好，會拉低整封信評分。
- 圖片比例過高：幾乎只有一張大圖、文字很少，容易進垃圾匣。
- HTML 結構破碎：標籤不完整、內嵌樣式怪異、或使用不合規的追蹤碼。
- 缺少清楚的品牌識別：From 名稱、簽名、公司資訊太模糊，可信度下降。
排查建議：測試時準備兩版內容：一版極簡（純文字或簡單 HTML）、一版正式模板。若極簡版送達正常、正式版容易進垃圾匣，就代表你的模板或內容元素觸發了過濾規則。交易信的設計重點是清楚、克制、可辨識，而不是華麗。
常見失敗模式 6：收件匣分類問題（Inbox vs Junk vs Promotions）
很多「我沒收到」其實是使用者沒有在正確地方找。大型信箱服務會把信分到主收件匣、促銷、社交、更新，或直接丟到垃圾郵件。對你來說都是「有投遞」，但對使用者來說就是「找不到」。
典型症狀
- 使用者說沒收到，但你從投遞報告看是 delivered
- 某些帳號會進促銷分類，某些會進主收件匣
- 同一個使用者第一次能收到，第二次就進垃圾匣
實務建議：在產品提示中引導使用者檢查垃圾郵件與其他分類，同時在信件內容保持一致的品牌識別（From 名稱、主旨語氣、域名一致），讓收件端更容易建立穩定分類。對 OTP 類信件，主旨與內容要清楚、避免行銷感，並盡量減少多餘外部連結。
常見失敗模式 7：退信碼被忽略（Bounce Codes）
送達率排查最怕的是「只看有沒有收到」，卻不看退信原因。退信碼與回覆訊息通常能直接告訴你問題在哪一層：是網域不存在、信箱滿了、被封鎖、被策略拒收、還是暫時性延遲。
如果你有寄信平台或 SMTP log，請把退信分類成兩大類：
- 硬退（Hard bounce）：地址不存在、網域無效、永久拒收。這類地址應該停止再寄，否則會傷信譽。
- 軟退（Soft bounce）：暫時性問題，例如信箱滿、灰名單、臨時策略限制。這類可以重試，但要注意頻率與總次數。
實務上，很多送達率掉下來都是因為你把硬退當成可重試，反覆撞牆，讓收件端判定你在濫寄。
常見失敗模式 8：寄信身分不一致（From / Return-Path / Reply-To 不對齊）
有些系統會把寄信拆成多個元件：顯示給使用者的 From、實際回彈用的 Return-Path、以及回覆用的 Reply-To。如果這三者的網域與設定不一致，常見結果是：
- SPF pass 但不對齊，DMARC fail
- DKIM 簽名存在但與 From 不一致
- 收件端評分下降，進垃圾匣或延遲
排查建議：用原始郵件 header 檢查 Authentication-Results，看 SPF/DKIM/DMARC 的結果與 alignment 狀態。很多「看似都有設」但仍掉信的案例，最後都卡在對齊。
常見失敗模式 9：測試方法不完整（只測某一家信箱，或只看單一指標）
送達率測試如果只用某一個信箱（例如只用 Gmail）或只看「有沒有收到」，很容易得出錯誤結論。不同收件端的策略差異很大，你需要更像「系統測試」而不是「個人收信測試」。
建議的測試矩陣
- 至少準備多種收件端：大型免費信箱、企業信箱、自建網域信箱
- 同時測交易信與通知信：不同內容類型的過濾規則不同
- 測不同寄送節奏：低頻、正常、尖峰（模擬 OTP 暴增）
- 同時觀察投遞結果與收件匣位置，而不是只看 delivered
如果你要找「最常掉的那一段」，就要把測試設計得像排障：每次只改一個變因，否則你會不知道到底是內容、DNS、信譽、還是速率造成差異。
一套可落地的排查流程（從最快到最關鍵）
- 確認是否真的投遞到收件端：看寄信平台投遞狀態與回覆碼，避免把「送出」誤當「送達」。
- 抓一封問題信的原始 header：看 Authentication-Results、SPF/DKIM/DMARC 結果與對齊。
- 檢查 DNS 設定：SPF 是否單一、DKIM selector 是否正確、DMARC 是否過嚴。
- 判斷是延遲還是丟棄：是否出現 4xx 暫時拒收、灰名單、或節流。
- 對照內容差異：用極簡版與正式模板交叉測，定位是否內容觸發。
- 檢查信譽因素：是否新網域、是否共享 IP、是否突然爆量，並調整寄送節奏。
- 建立監控與回報：把 bounce、delay、spam placement 做成可追蹤的指標，避免每次都靠猜。
這套流程的精神是：先把「必定會造成失敗」的基礎錯誤排掉，再處理「機率性波動」的信譽與內容問題。很多團隊反過來做，先改模板、先猜文案，結果繞一大圈才發現是 SPF 有兩筆。
實務建議：把交易型郵件當成產品的一部分來設計
送達率不是純後端問題，它也跟你的產品流程有關。尤其 OTP／驗證信這類「每一秒都重要」的信件，建議你從系統與 UX 兩端同時下手：
- 提供重新寄送但要有節制：加入冷卻時間，避免使用者狂點造成寄送風暴。
- 提示檢查垃圾郵件與分類：讓使用者知道可能出現在促銷或垃圾匣。
- 避免同時寄多封：例如多步驟驗證時把通知合併，減少短時間密集寄送。
- 維持一致品牌識別：From 名稱、網域、主旨格式穩定，收件端更容易建立信任。
- 把送達率當成監控指標：至少要能看投遞成功率、延遲率、退信率、垃圾匣率的變化。
當你把這些做起來，送達率問題就不再是「某一天突然爆炸」，而是可預期、可觀測、可迭代的系統品質。
結語：不要只問「為什麼收不到」，要問「卡在哪一段」
郵件送達率最容易讓人焦躁，是因為你看不到整條鏈。但只要你掌握「送出、送達、進收件匣」的分層概念，並用 DNS 驗證、投遞回覆碼、原始 header、內容交叉測試、信譽與節流策略逐段排查，絕大多數問題都能被定位。
你不需要一次變成郵件專家；你只需要建立一套穩定的測試與排障方式。當這套流程跑順了，寄信就會從不確定的黑盒子，變成可管理、可優化的產品能力。