已送出不是收件匣：簡訊內容過濾、發送信譽，以及為何重試會更糟

「已送出」「已提交」只是交接：平台接單並交給 live 走廊，並不等於有人在收件匣看到簡訊。OTP 與告警會在產品把綠燈當成收件匣時悄悄失敗，手機仍停在內容過濾或受損信譽後面。

IOSOR 以 white-label 預付費訊息運行：狀態、DLR 與錢包列都在您的帳戶。接近每月 USD 1,000+ 用量時，過濾命中、走廊 p95 與重試借記成為商務複盤材料。先證據，再放量。目錄 live 卻沒有過濾敘事，是凌晨兩點無法辯護的承諾。in setup 市場不能當收件匣證明。沒有預先囤積的「更乾淨發送方」可連夜替換。產品、營運與財務應能指向同一過濾碼與同一借記列。實驗室發送不能當作生產信譽；走廊未標 live 就不要對外承諾收件匣。

已送出與已提交不是收件匣

要求可核驗的 webhook。「已送出」截圖不是營運模型。把詞典與 未送達、拒收與過期狀態 對齊，讓產品與財務停止對同一事件爭吵。相關 ID 必須能從發送追到終態再追到借記。

內容過濾與發送信譽

過濾器看文案、發送身分、走廊歷史與投訴密度——不看意圖。釣魚措辭、短鏈、突然放量、滑向行銷的 OTP 範本會撞同一面牆。信譽按走廊成形：乾淨 OTP 路徑不能為另一市場的受損發送方開脫。交易範本保持短而穩；行銷類與 OTP 分開。目錄仍 in setup 時，實驗室發送不是生產信譽。在您的帳戶讀過濾結果，而不是外來控制台。

按走廊看過濾，而不是全球平均

全球「已送出」率會藏起一條被過濾市場。按目的地類別、發送方類型與範本家族切片。每週：過濾/失敗前列走廊、submitted→delivered 相對轉化 SLA、SLA 後仍非終態份額、目錄標籤 vs 真實發送。產品應在使用者發明變通前知道過濾走廊。參見 簡訊可達性營運指南 與 回執、時延與故障轉移。

不要對著同一過濾器重試

同一文案打進同一過濾器會燒掉預付費，並訓練過濾器把你當成風暴。給自動重試設上限。先改原因——範本、發送類別、名單衛生——再第二次嘗試。使用者重發不是系統重試。死號與過濾循環在錢包上看起來像增長，直到財務問 delivered 為何不動。配對 簡訊低送達率處置手冊。

危險訊號

• 只有「已送出」，無 delivered/filtered
• 同一文案打進同一失敗碼
• 全球平均藏起過濾走廊
• 目錄 live 但過濾無負責人
• 錯誤傾倒外來品牌名
• 模擬走廊當收件匣證明
• 假裝有現貨發送方可連夜替換

從 IOSOR 開始

請開啟 IOSOR 主控台並檢查 DLR Webhook 酬載串流，將已提交（Submitted）狀態與終端送達（Delivered）確認區分開來。針對任何會將相同內容重新注入非終端或電信商過濾錯誤代碼的自動重試機制，請立即設定執行暫停。透過走廊級監控閘道引導流量，以便在內容過濾器降低您的寄件者信譽之前，自動標記流量激增與網址變異。

運維團隊應在系統日誌中記錄 UTC 時間戳記，匯出過濾事件明細，並依據目的地電信商與簡訊範本家族進行交叉分析。請確保所有重試邏輯皆包含內容變異機制，嚴禁直接重試未經修改的原始文字，以維護長期的發送信譽。把這條作業寫進運維清單，並在系統上線前完成最後核對。

IOSOR 要點

已傳送或已提交的 DLR 狀態僅證明流量已離開原始發送平台，並不代表訊息已成功進入收件人的手機或收件匣。在電信走廊層級，內容過濾器會採取靜默丟棄機制，根據網址縮短器的使用、範本內容的微小飄移以及寄件者信譽歷史進行即時評估。若要有效排除故障，操作員必須進入控制台，依據目的地類別、範本家族以及 UTC 時間戳記切片分析傳送指標，以便識別特定電信商的過濾模式。請務必檢查帳本中的扣款紀錄與實際送達率的落差，並匯出詳細日誌以比對錯誤代碼。絕對不要在收到過濾回應後，將未經修改的內容盲目重試發送到相同的路徑，因為這種重複行為會迅速惡化您的發送信譽，並導致電信商系統將您的帳戶標記為垃圾郵件來源。如需深入了解過濾機制，請參閱 /learn/sms-filtering-guide 以優化您的發送策略，並透過 /learn/sender-id-best-practices 確保您的寄件者識別碼符合在地規範。維持健康的流量分布與內容變異，是避免訊息被靜默攔截的唯一途徑。