事件起因
收到一封看起來來自 noreply@dhl.com 的 DHL 包裹通知信。寄件者地址完全正確，不是那種一眼就能識破的 dhl.xyz 或 dh1.com。公司的 ShareTech 郵件閘道把它判定為垃圾信攔截了下來，但我想搞清楚它到底是怎麼做到冒用正版網域的。
第一個破綻：連結指向俄羅斯伺服器
翻開信件原始碼，所有連結都指向同一個地址：
http://srv222256.hoster-test.ru/we/login.htm#sarah@sarahselections.com
幾個明顯的問題：
- 網域是
.ru：hoster-test.ru，一台俄羅斯的測試伺服器，跟 DHL 毫無關係 - HTTP 而非 HTTPS：正規企業不會用未加密的連結
- FAQ 和 Help Centre 按鈕指向同一個網址：正常網站不會這樣設計
- 網址尾端附帶 email 地址：
#sarah@sarahselections.com是用來追蹤哪個受害者點了連結
核心問題：為什麼能冒用 dhl.com？
電子郵件協定 SMTP 設計於 1980 年代，天生不驗證寄件者身份。就像寄實體信時，你可以在信封上寫任何人的回郵地址一樣。
SMTP 有兩層寄件者：
- Envelope From（信封層）：實際發信伺服器的地址
- Header From（顯示層）：收件者在信箱裡看到的「來自誰」
攻擊者只要在 Header From 填上 noreply@dhl.com，信箱就會顯示這封信來自 DHL。
現代的三道防線
| 機制 | 功能 | 為什麼沒擋住 |
|---|---|---|
| SPF | 檢查發信伺服器 IP 是否被網域授權 | 只驗證 Envelope From，不管 Header From |
| DKIM | 用數位簽章驗證信件完整性 | 偽造者可以不簽，部分收件伺服器不會因此拒收 |
| DMARC | 結合 SPF + DKIM，指示如何處理驗證失敗的信 | 很多伺服器選擇隔離而非直接丟棄 |
發信管道：SendGrid
查看郵件標頭，發現信件實際上是透過 cdn.mc-auto.sendgrid.net 發出的。
SendGrid 是 Twilio 旗下的正規大量郵件發送平台，很多企業拿來發行銷信和通知信。攻擊者利用它的原因很明確：
- 從 SendGrid 發出的信，SPF/DKIM 驗證會通過（信確實是從 SendGrid 的授權伺服器發的）
- 很多郵件伺服器信任 SendGrid 的 IP 信譽，不容易被擋
這讓整封信在技術驗證上更難被攔截。
ShareTech 攔截後的黑名單問題
ShareTech 郵件閘道成功把這封信攔到隔離區，系統提供了「加入黑名單」的選項。但我選擇不加，原因是：
黑名單是基於寄件者地址比對的。 封鎖 noreply@dhl.com 意味著以後真正的 DHL 通知也會被擋。而攻擊者下次只要換成 shipping@dhl.com 就能繞過黑名單。
這不是 ShareTech 的設計缺陷，而是黑名單機制本來就不適合對付寄件者偽造。真正該處理偽造的是伺服器層級的 SPF/DKIM/DMARC 驗證，不是使用者端的黑名單。
我做了什麼
把原始郵件（含完整標頭）轉寄到 abuse@sendgrid.com 進行檢舉。SendGrid 會調查並停用該帳號。雖然攻擊者可以重新註冊，但至少增加了他們的成本，而且 SendGrid 對重複違規者的驗證會越來越嚴格。
判斷釣魚信的檢查清單
| 檢查項目 | 怎麼做 |
|---|---|
| 連結指向 | 懸停看實際網址，是否指向官方網域 |
| 郵件標頭 | 查看 SPF/DKIM/DMARC 驗證結果 |
| 內容語氣 | 催促「立即行動」、要求輸入個資或付款 → 高度可疑 |
| 是否預期 | 你最近有沒有透過該服務寄送或收取東西 |
| 多個連結指向同一網址 | 正常網站的 FAQ 和 Help 不會是同一個頁面 |
寄件者地址正確不代表信件是真的。這是最重要的一點。