黑名單解除後仍退信：用固定條件重測，而不是不停重寄

黑名單解除後仍退信，應先固定寄件路徑、測試帳號與內容版本，再比對新的退信是否仍指向原來的問題。不要只憑解除通知就反覆重寄，也不要把舊退信當成新失敗。本文從已取得解除或未見列示的觀察開始，建立前後對照與停止條件；不重複移除申請教學，也不提供恢復天數保證。

先確認「已解除」的依據和適用對象

把供應商通知拆成可核對的事實：它說已提出申請、申請已核准，還是重新查詢後未見列示？通知是否指明 IP 或網域？如果只有「已解決」一行字，先請對方補上對象、確認時間與紀錄參照，否則你連要保持哪個測試條件都不知道。

保留原退信事件與處理通知，不要用新的截圖覆蓋舊檔案。建立三個時間點：原失敗、處理確認、重測。時間都附時區；若供應商使用 UTC，另加台灣時間對照，避免把處理之前的失敗排進處理之後。

Spamhaus 的 DBL 官方說明提到，解除後仍可能因相關活動再次被偵測而重新列示。因此，本次重測要保存當時的查詢觀察，而不是假設一張較早的解除截圖永久有效。至於不同系統何時更新，應依實際紀錄確認，不能從另一家服務的時程推算。

• 處理對象與資料集名稱。
• 通知的原始文字與發出單位。
• 申請、核准或查詢的實際狀態。
• 確認時間、時區及可回查的案件編號。

固定內容版本，但讓每次測試都有自己的事件紀錄

先決定這次要驗證的範圍。如果問題是相同出口是否還被同一個收件系統拒收，就固定寄件帳號、平台路徑與一個獲准使用的測試收件帳號。不要一邊換寄信工具，一邊刪附件、改主旨，又把收件人換成別家信箱；即使成功，也無法知道是哪個變動造成差別。

「同一封測試信」應理解為同一個內容版本及可比條件，不是強行重用 Message-ID。每次新投遞都有自己的事件索引，前後以版本編號串起來。若平台自動更新追蹤連結、日期或簽名，這些差異也要註記，不宜把它們藏在「內容完全相同」的描述裡。

測試收件者必須是公司可控制或明確同意配合的帳號。不要拿正在洽談的客戶信箱反覆試，也不要重新寄給已表示不希望收到郵件的人。先約定測試目的與停止條件，確認收件端有需要時能協助查看閘道或資料夾，而不是只問「有沒有收到」。

每次記錄接受、退信與落點，別只填成功或失敗

投遞紀錄應拆成幾個欄位：發信系統是否接到工作、是否有對外投遞、對方回覆什麼、後續是否收到退信，以及測試收件者在哪個資料夾看到信。某個階段沒有資料，就填未知。平台顯示已送出，還不能直接填入「收件匣成功」。

SMTP 對特定傳輸階段的接受回覆，也不等於使用者看見信件。RFC 5321 描述了郵件傳輸的回覆流程；這份重測表則把傳輸紀錄與收件端觀察分開，避免讓前者代替後者。收到端仍需由獲准的測試帳號確認，不能用開信率圖表反推每一封的落點。

若收到新退信，保存發信時間、退信時間、回覆來源、SMTP 回覆和增強狀態碼。不要只抄「5.7.1」就下結論，更不要直接把所有安全性拒絕都歸給同一個黑名單。讀取完整說明後，再確認它是否仍提到原來的對象或資料集。

• 投遞事件：T1／T2，對應內容版本與寄件路徑。
• 回覆：接受／拒絕／暫時無法判讀，附原文。
• 退信：有／無／尚未觀察到，附觀察截止時間。
• 落點：主要收件匣／其他資料夾／未找到／尚未查核。

用前後對照找差異，不急著替原因命名

先比對來源是否相同。如果供應商把 T2 改走另一個出口，即使它成功，也只能證明新路徑當次可用，不能證明舊 IP 的問題已消失。請管理者提供兩次實際出口的核對結果，並在表格中把路徑改變獨立標示，避免結案時誤報成原路徑修復。

再比對退信是否相同。原先訊息提到列示，新的訊息卻指向收件限制，應建立新的待查項目，而不是把它說成「解除沒生效」。如果仍提到同一個對象，也只代表需要追查目前的判斷依據；是否使用快取、內部規則或其他資料，必須由相關管理者證實。

最後對照查詢時間。官方查詢、第三方工具與收件端事件若不是同一時段，差異可能只是觀察條件不同。把時間並列，再交由支援窗口回答。沒有查核紀錄時，「可能是快取」只能放在待確認欄，不能放在根因欄。

根據問題選擇下一個窗口，並設定停止條件

若兩次出口不同、平台沒有留下對外事件，或供應商無法確認寄件路徑，先回到寄件服務商。請它補足路徑與紀錄，而不是要求收件端猜測。若已確認同一路徑，且拒絕文字由特定收件系統回傳，則透過既有聯絡管道請對方管理者依事件時間查核。

如果官方與收件端資訊不一致，交付的是兩邊的原始觀察與時間，不是要求對方停用防護。支援工單可以問「此時間點是否仍採用這筆列示，以及可否提供規則識別」，避免寫成「請把我們全部加白」。收件端有權依自身政策判斷，測試不是施壓放行的理由。

停止條件至少包括：沒有可查的投遞紀錄、收件者未同意繼續測試、出現新的安全性警訊，或多次操作沒有新增任何資訊。這時應補件、等待回覆，或改由管理者調查，不要讓自動重試持續製造同樣的退信。具體等待窗口由案件雙方約定，不在本文給統一天數。

• 寄件服務商：路徑、出口、佇列與平台事件。
• 收件管理者：當次拒絕依據與閘道紀錄。
• 內部負責人：決定是否有足夠證據安排下一次測試。
• 業務窗口：告知受影響範圍，不承諾未經證實的恢復時間。

寫出有限結論，再決定是否增加落點觀察

結案摘要應包含實際測試範圍，例如「同一寄件路徑對測試帳號 A 的一次投遞已被接受」。若只測了一家收件服務，就不要擴大成「所有客戶都恢復」。若對方只確認收到，沒有查資料夾，也不要補寫成「主要收件匣正常」。

對照表可留四個結論欄：已確認、未確認、下一步、負責人。這讓業務知道現在能對客戶說什麼，IT 也不用為了得到一個綠燈而忽略剩餘問題。原始資料留在受控位置，對外版本只保留所需的事件資訊與遮罩後附件。

需要觀察不同收件系統的落點時，可以另外安排獲准的 Inbox Check 測試，把它視為新的測試範圍，保留日期與結果。不把測試工具當成黑名單移除窗口，也不把一次工具結果當成未來投遞的保證。

官方資料查閱於 2026-10-18：Spamhaus「Domain Blocklist」解除與重新列示說明，https://www.spamhaus.org/blocklists/domain-blocklist/；RFC Editor「RFC 5321」，https://www.rfc-editor.org/rfc/rfc5321.html。本文的版本表、事件欄位與停止條件為編輯整理的排查方法。

實際上可以用免費的收件匣到達率測試（check.live-direct-marketing.online）來驗證。

常見問題