郵件標頭分析工具（メールヘッダー解析ツール）
貼上收到郵件的原始標頭（Received:、Authentication-Results: 等），即可逐跳解析投遞路徑，並列出 SPF/DKIM/DMARC 認證結果。全部解析在瀏覽器內完成。
Received: 標頭各欄位的含義
| 欄位 | 含義 |
|---|---|
| from | 將此郵件交過來的上一臺伺服器的主機名/IP位址，由寫入這一行的接收端伺服器記錄。寄件者可以隨意加入偽造的 Received 行，因此越早的行越容易被偽造。判斷真實發件IP時，請使用由您自己管理的接收伺服器寫入的行中最早的一行（在本工具的列表中，即 by 第一次出現您自己伺服器的那一跳）的 from。 |
| by | 在這一跳接收郵件的伺服器（例如你自己的郵件伺服器）的主機名。 |
| with | 本次投遞所使用的協議（如 ESMTP、ESMTPS、SMTP）。ESMTPS 表示該連線使用 TLS 加密。 |
| for | 本次投遞的目標收件人地址。郵件列表或多個收件人時通常會省略。 |
| timestamp | 此跳接收郵件的日期和時間。時間和時區由寫入這一行的接收端伺服器記錄（RFC 5321 §4.4）。各跳之間的時間差可粗略估算投遞延遲。 |
Authentication-Results: 各欄位的含義
| 欄位 | 含義 |
|---|---|
| SPF | SPF（發件人策略框架）認證結果：驗證發件IP是否包含在發件域名DNS記錄所允許的地址列表中。 |
| DKIM | DKIM（域名金鑰識別郵件）認證結果：驗證郵件正文及主要標頭的數字簽名，能否用發件域名的公鑰成功校驗。 |
| DMARC | DMARC（基於域名的郵件認證、報告與一致性）認證結果：綜合校驗 SPF、DKIM 結果與 From 標頭域名是否一致（對齊）的最終判定。 |
由郵件標頭追蹤投遞的路徑
把所收郵件的原始標頭貼進來，本工具便將 Received: 逐跳拆開，把投遞的路徑攤出來，並把 Authentication-Results: 中所記的 SPF、DKIM、DMARC 判定一併列出。整套解析都在瀏覽器內完成，貼入的東西不會被送往任何地方。
讀它時頭一件要明白的，是 Received: 須由下往上讀。 每台伺服器收到郵件，便把自己那一行添在最頂上，故而最早的一程在最底下，最後收下它的伺服器在最頂上。 更要緊的是：這些標頭人人都偽造得來。 發信方盡可捏造任意多條 Received: 擺在開頭。可信的只有您自家管轄的伺服器所寫的那一行，以及其上的一切；其下的種種，不過是「某人如此宣稱」罷了。Authentication-Results: 亦然——不看清那判定出自哪台伺服器，判定本身便可能是假的。
使用方法
- 貼入原始標頭 可自郵件軟體的「顯示原始郵件」「檢視原始碼」處取得。
- 由下往上讀 Received 最底下是最初的發信方，最頂上是最後收下它的伺服器。
- 查看認證的結果 SPF、DKIM、DMARC 的判定一併擺出。
- 弄清信任自何處起 您自家管轄的伺服器所寫那一行之下的種種，皆可能是偽造的。
用好本工具的小技巧
- 在 Gmail 中，開啟郵件後點擊右上角的豎三點選單，選擇"顯示原始郵件"即可獲取原始標頭。在 Outlook 中可通過"檔案"→"屬性"→"Internet 標頭"檢視。
- Received: 標頭在郵件正文中是按照最新在前（接收方在最上方）的順序追加的，本工具會自動將其重新排序為從發件方到收件方的時間順序。
- 如果鏈路中的郵件伺服器時鐘存在細微偏差，"相對上一跳的延遲"可能顯示為負數。幾秒級別的負值通常只是時鐘不同步造成的，並非真正的投遞異常。
- 即使 SPF、DKIM、DMARC 全部通過，也不能保證該郵件不是詐騙郵件。這些認證只能驗證發件域名所有者自身配置的流程被正確執行，無法檢測出攻擊者合法擁有的仿冒域名。
- 如果發現某兩跳之間延遲驟增，說明該段路徑上的郵件伺服器很可能發生了投遞阻塞或被垃圾郵件過濾器攔截。
這些情境會用到
查究垃圾郵件的出處
真正的發信位址，現於您信得過的最底下那條 Received: 之中。
識破冒名
顯示名與 From 一行偽造起來易如反掌，故當憑認證結果來判斷。
追查投遞的遲滯
讀一讀各跳的時刻，便知郵件在何處停滯。
確認自家郵件是否通過認證
給自己發一封測試信，看 SPF、DKIM、DMARC 是否盡皆通過。
郵件標頭的術語
- Received
- 每台收信伺服器把自己那一行添在最頂上的標頭。 路徑須由下往上讀。
- Authentication-Results
- 記錄收信一方所作 SPF、DKIM、DMARC 判定的標頭。要緊的是它出自哪台伺服器。
- Return-Path
- 投遞失敗時退回之處。SPF 正是針對這個網域來查的。
- From
- 所顯示的寄件人。此處任人書寫，故不足以證明是誰寄的。
- Message-ID
- 唯一標識一封郵件的字串，用以分辨同一封郵件的重複。
- 跳
- 郵件所經的一台伺服器。每一跳留下一條
Received:。
常見問題
閒話 ― 郵件標頭是一疊"數字郵戳"
正如信件上的郵戳記錄了哪個郵局在何時處理了它，電子郵件的 Received: 標頭也是一疊"數字郵戳"——每一臺轉發過這封郵件的伺服器都會在其上蓋上自己的時間戳。SMTP 協議（RFC 5321）要求每一臺中繼伺服器都必須把自己的資訊新增到標頭的最前面，於是每封郵件都會自然而然地積累起一份完整的投遞路徑記錄。
這套機制在追查垃圾郵件來源時最為實用。但需要注意的是，Received: 標頭和寄件者欄（From 標頭）一樣，寄件者可以隨意偽造。寄件者可以在送出郵件之前加入任意多條偽造的 Received: 行，因此越早（越靠下）的行越有可能是偽造的。真正可以信任的，只有由您自己管理的接收伺服器寫入的行。其中最早的一行，是您的伺服器接受外部連線時記錄的，其 from 中的連線來源IP位址是寄件者無法偽造的。反垃圾郵件專家首先查看的，正是這個「由自己的伺服器記錄的第一個連線來源」。
SPF、DKIM、DMARC 這三項認證技術，正是為了彌補僅靠"郵戳"無法阻止的仿冒行為而後來加入的。SPF 核對發件IP是否在該域名的許可列表中，DKIM 通過數字簽名驗證郵件內容未被篡改，DMARC 則綜合以上兩者與 From 標頭域名的一致性做出最終判定。2024年 Google 和 Yahoo 事實上要求大批次發件方必須配置 DMARC 之後，Authentication-Results: 標頭也開始頻繁出現在普通使用者的收件箱中。
平時幾乎沒人會去開啟郵件標頭，但一旦開啟，你會發現其中精確記錄著這封郵件曾經過地球上的哪些伺服器、每一步各花費了多少秒——這是一段肉眼看不見的網際網路旅程日誌。