安全連結解碼器
解碼 Outlook SafeLinks、Proofpoint URLDefense、Google 跳轉連結等被郵件閘道器重寫的 URL，在點選之前看清它真正指向哪裡。
還原 Outlook SafeLinks、Proofpoint URLDefense 等被重寫的連結。 企業郵件閘道器會重寫郵件裡的每一個連結，讓點選先經過它們的掃描器。把重寫後的連結貼上到這裡，在開啟之前先看清真實目的地。
請貼上完整連結，包含查詢字串。所有處理都在瀏覽器內完成。
連結為什麼會被重寫，以及如何讀懂它
連結包裝做了什麼
當企業部署了 Microsoft Defender for Office 365、Proofpoint、Mimecast 之類的郵件閘道器，入站郵件裡的每一個 URL 都會在送達郵箱之前被改寫。example.com/report 會變成類似 eur01.safelinks.protection.outlook.com/?url=htt... 的形式。
目的在於點選時刻的防護。一條連結在郵件被掃描時可能完全無害，一小時後才被掛上惡意載荷，因此閘道器強制每次點選都回到自己的掃描器，在那一刻重新核對目標信譽。
包裝的代價
包裝打破了最古老的一條安全建議：把滑鼠懸停在連結上、看看它指向哪裡。狀態列現在顯示的是閘道器域名，而不是真實域名。它還會破壞連結預覽、讓 URL 無法寫進文件、無法直接貼上到終端，並把點選行為洩露給閘道器運營方。
解碼就是把原始 URL 拿回來，讓你自己判斷。
各種格式
Outlook SafeLinks 把目的地放在 url 查詢引數裡，做了一次百分號編碼。後面的 data、sdata、reserved 都是跟蹤後設資料，可以丟棄。
Proofpoint URLDefense 有三代。v1、v2 使用 u 引數並做了自定義替換：- 代表 %，_ 代表 /。v3 改用路徑形式 __example.com__;!!...。本工具會先還原替換再做百分號解碼。
Google 使用 /url?q=（搜尋結果）或 /url?url=（其他產品），Facebook、LinkedIn、Twitter 也各有對應形式。
通用包裝把目的地放在名為 url、u、target、redirect、dest、link 的引數裡。識別不出具體廠商時，解碼器會掃描這些引數名。
安全地閱讀解碼結果
拿回 URL 只完成了一半。要看可註冊域名而不是整串字元——paypal.com.secure-login.ru 屬於 secure-login.ru。留意形近字元、意料之外的頂級域，或者一個正規主機配上奇怪路徑（例如 /wp-content/uploads/）。另外記住：解碼後看起來正常，並不能證明連結背後的檔案是安全的。
常見問題
在這裡解碼可疑連結安全嗎？
安全。解碼只是瀏覽器內的字串處理，不會向該連結發起任何請求，也不會把內容傳送到伺服器。你是在讀這個 URL，而不是訪問它。
為什麼解碼後仍帶著奇怪的引數？
utm_source、gclid、fbclid 之類的營銷引數本來就屬於原始 URL，解包之後依然存在。如果想要乾淨的連結，可以手動刪掉。
提示“未被包裝”，但連結確實來自郵件。
並非所有閘道器都會包裝所有連結。內部發件人、白名單域名和純文本郵件常常原樣保留，因此沒有可解開的外層。
可以關閉 SafeLinks 嗎？
只有租戶管理員能在 Defender for Office 365 策略裡關閉，而關閉意味著所有人都失去點選時刻防護。更穩妥的做法是逐條解碼。
多層包裝怎麼辦？
在組織之間轉發的郵件可能被包裝兩次。把解碼結果再解一次，第二層同樣能剝掉。