寄件網域沒上黑名單，信內連結卻被標記：如何分開蒐證與交接？

寄件網域查詢未見列示，不能排除信內另一個網域被標記；應把寄件身分、連結主機與轉址目的地分開蒐證。這篇要完成一份連結責任清單，讓業務找得到文字、簽名與追蹤中的網址，也讓 IT 能核對結果與管理者。目的在確認問題範圍，不是把被標記的連結換個外觀繼續寄，也不把所有連結問題都歸因於寄件網域。

先保存實際寄出版本，避免只看編輯畫面

業務在編輯器看到的內容，可能不是實際寄出版本。系統可能加上簽名、預設頁尾或追蹤連結，因此先請管理者取得本次投遞的內容版本及相關紀錄。若只有草稿，清單要註明「尚未與寄出版本核對」，不能據此宣稱信內只有公司官網。

把寄件地址使用的網域另放一欄，再逐項盤點郵件中的網址。不要看到公司名稱就認定所有連結都由公司管理，也不要看到兩個相近的子網域就合併。收件人畫面上的連結文字、實際 href 和轉址後的目的地，是需要分別記錄的三種資訊。

檢查內文、簽名、按鈕、頁尾與自動加入的追蹤。圖片載入來源可以另外記錄，避免和可點擊的連結混成一項。這份清單不是要求業務執行完整安全掃描，而是先讓 IT 看得出有哪些對象需要查核，以及每個對象從哪裡來。

• 郵件版本與事件編號：能回到本次投遞紀錄。
• 寄件身分：實際寄件地址中的網域，另列待確認的技術身分。
• 可見文字：收件者看到的名稱或網址。
• 實際連結：保存在受控原檔，外部分享時處理敏感參數。

把 URL 拆成主機與用途，不把整段網址當成同一種查詢值

網址包含協定、主機名稱，並可能帶有路徑、查詢參數與片段。先保留原始版本，再由有權限的人整理查核所需的主機名稱。例如連結外觀是文件下載，主機卻屬於外部平台；這時需要確認的是該主機與服務，而不是直接把寄件網域的查詢結果複製過來。

Spamhaus 的 DBL 官方說明把網域資料與 IP 資料區分開來，並說明列示不包含完整 URL 的目錄路徑。這不表示路徑在所有安全產品中都沒有意義，而是提醒你記錄「用了哪一種工具、查了哪一個值」。不能把某一網域資料集的結果擴大解讀為整段網址在所有收件端的安全評價。

連結若含客戶代號、一次性存取碼或信箱參數，不要直接貼進公開查詢工具或外部工單。先確認工具要的是網域、主機還是完整網址。若只需網域，就提供所需範圍；完整原始值由內部保管。不可把遮罩後的假網址拿去測試，再把結果當成原網址的證據。

對追蹤與轉址建立路徑紀錄，由管理者確認目的地

有些連結先到追蹤服務，再轉到文件或公司網站。這種情況下，最前面的主機和最後的主機可能由不同單位管理。清單應保留起點、已確認的中間步驟、目的地與確認方法；尚未確認的部分填未知，不用肉眼猜一條看起來合理的路徑。

不要為了盤點而隨意打開不明網址，尤其是帶有登入、取消訂閱、一次性下載或個人識別的連結。交由有權限的管理者依既有安全程序查看平台設定或必要紀錄。若需要在隔離環境檢查，也先確認這個操作不會觸發客戶資料或執行其他動作。

轉址目的地可能依時間、使用者狀態或服務設定而不同，所以記錄確認時間與條件。若供應商只能提供一般架構圖，無法確認本次連結，清單就寫「平台一般路徑，未與本次事件核對」。這樣的限制比一條沒有依據的完整路徑更能幫助調查。

• 起點：寄出版本中的連結主機。
• 中間步驟：已確認的追蹤或轉址服務。
• 目的地：由何種紀錄確認、何時確認。
• 管理者：公司網站、郵件平台、文件平台或其他供應商。

分別保存查詢結果，再對照退信或警示文字

每個被查核的對象各有一列結果：查詢值、工具名稱、資料集、時間、回傳訊息。寄件網域未見列示，就只寫在寄件網域那一列。若連結主機有警示，另存該列證據；如果工具載入失敗或結果不完整，狀態寫查詢未完成，而不是自動填正常。

同時保留收件端警示的原文和出現位置。郵件被拒收、使用者點擊後看到瀏覽器警告、或企業閘道隔離連結，是不同事件。沒有相關紀錄時，不要把任何一種畫面直接命名為「Spamhaus 擋信」。先確認警示是否真的提到資料集、網域或網址。

若退信沒有指出是哪個連結，也不要靠刪一半內容後成功一次就宣布找出根因。可以把連結視為待查假設，請管理者依事件核對。原始觀察、測試結果與原因判斷分開，才能在供應商提供新資料時修正結論，不必推翻整份紀錄。

安排有邊界的對照，不用改網域掩蓋警示

如果管理者認為需要比較內容版本，可以在獲准的測試帳號與環境中，保留寄件路徑，建立只改一個因素的版本。每次投遞各有事件索引，寫清楚版本差異與觀察範圍。這種測試只用來縮小問題，不能直接把成功版本投入客戶寄送。

若含某連結的版本失敗、不含連結的版本被接受，結果可支持「內容差異值得追查」，仍不足以單獨確認是哪個網域、哪條規則或哪個資料集造成。把兩次事件交給管理者核對，再決定是否需要補充其他資訊，避免把一組簡單對照說成完整因果證明。

停止案例也要寫進程序。虛構情境：第三方追蹤主機出現警示，供應商建議先套短網址繼續寄。此時不應把它當成修復；先停止使用待查連結，要求說明警示範圍與處理方式。換短網址、換新子網域或多串一層轉址，都不能取代釐清並修正原問題。

• 測試前：目的明確、帳號獲准、版本差異可回查。
• 測試中：不使用客戶敏感參數，不觸發退訂或其他操作。
• 測試後：記錄接受、拒絕及落點，分開保存結果。
• 停止時：出現安全警示、未知行為或無法控制的目的地，就交回管理者。

把修復責任交到正確的人，保留重新檢查的條件

公司自有網站的連結，由網站管理者核對內容與安全狀況；第三方追蹤主機，則請平台供應商確認管理範圍。若起點正常、目的地有問題，或反過來，應各自建立待辦。不要把整份清單都丟給 DNS 管理者，要求修改 SPF 或 DMARC 就能處理所有信內網址。

工單可以這樣整理：事件編號、連結用途、主機與已確認路徑、警示來源、受影響版本、目前停止使用的範圍、需要對方回答的問題。對方回覆後記錄實際處理了什麼，再依固定條件安排新的查核。未得到證據前，狀態維持待查，不承諾客戶何時恢復。

需要觀察郵件落點時，可以安排受控的 Inbox Check 測試，將它作為投遞結果的補充。它不替連結擁有者處理安全問題，也不是保證解除列示的服務。真正的結案條件是管理責任、處理措施與限定範圍的新證據都能對上。

官方資料查閱於 2026-10-18：Spamhaus「Domain Blocklist」，https://www.spamhaus.org/blocklists/domain-blocklist/。本文僅引用其資料對象與使用範圍說明；連結盤點、責任清單及受控對照方法為編輯整理，沒有對任何實際網址執行查詢或宣稱列示。

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

常見問題