# Email Header Analyzer > 貼上郵件標頭或拖入 .eml、.msg，逐站列出傳遞路徑和延遲，解讀 SPF、DKIM、DMARC 結果，再於瀏覽器裡重新驗證 DKIM 簽章。信件內容不上傳，免費免註冊。 - URL: https://bytescope.dev/zh-Hant/email-header-analyzer/ - Locale: zh-Hant · Also: [en](https://bytescope.dev/en/email-header-analyzer.md) · [ja](https://bytescope.dev/ja/email-header-analyzer.md) - Runs: 檔案不會離開你的瀏覽器 — 全部在本機處理。 - Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile. - Updated: 2026-09-08 ## What it does 大家看郵件標頭通常是為了三件事：這封信為什麼晚了兩個小時才到、這封說是銀行寄的信到底是不是真的、我的信為什麼被丟進垃圾信匣。用肉眼讀很累——十幾行倒著排的 `Received`、各自不同時區的時間、再加一條塞滿縮寫的 `Authentication-Results`。這個郵件標頭分析工具在瀏覽器裡把標頭拆開排好：信走過哪些站、每一站停了多久、收件伺服器當時對 SPF、DKIM、DMARC 下了什麼判斷，以及 DKIM 簽章現在重新驗還過不過。什麼都不上傳。整頁唯一會發出的網路請求是 DKIM 公鑰查詢，而且要等你按下「驗證 DKIM」才會發：它把 `selector._domainkey.網域` 這個名稱送到公開的 DNS-over-HTTPS 服務（Cloudflare，失敗時改用 Google），該服務看得到你的 IP，這是 DNS 查詢的本質。信件內容、收件者、標頭本身都不會送到任何地方。 ### 追蹤傳遞路徑，找出卡在哪一站 每一條 `Received` 就是一個跳站。頁面依時間順序從最早的一站排起，把每一站拆成：宣稱的寄出主機、括號裡的反查名稱和 IP、收下這封信的主機、使用的協定（`SMTP`、`ESMTPS`、`ESMTPSA`、`LMTP`……）和時間。協定字母依 RFC 3848 解讀——有 `S` 代表這段連線有 TLS、有 `A` 代表寄件端有驗證身分——所以你看得出信在路上有沒有加密。每一站的延遲是這站的時間減掉前一站，畫成橫條，最長的那一條標紅，被延遲的信通常就是在那裡等。延遲是負值會標「時鐘不同步」而不是當成錯誤，因為郵件伺服器的時鐘本來就常常對不齊；沒有時間或時間解析不了的站標「無法計算」，不會把後面的站一起吃掉。私有位址（RFC 1918、`127.*`、`::1`）標成「內部轉送」。IP 只以文字顯示，不做地理位置查詢——那得把 IP 送到第三方 API。 ### 讀 Authentication-Results，但只信該信的那一條 `Authentication-Results`（RFC 8601）是收件伺服器把判斷寫下來的地方：`spf=pass`、`dkim=fail`、`dmarc=none`，有的還有 `arc`、`iprev`、`bimi`。頁面把每一條拆成 authserv-id 和各個方法，每個結果配一句白話——`softfail`、`temperror`、`permerror`、`neutral` 到底是什麼意思、常見原因是什麼。整張清單上面放了一個警告：路上任何一台伺服器、包括寄件者自己，都可以加一條 `Authentication-Results`。只有你自己的收件伺服器寫的那一條可以信；中間站寫的、寄件者自己塞的，什麼都證明不了。ARC 標頭（RFC 8617）依 `i=` 分組列出來給你參考，這一版只顯示、不驗證 ARC。 ### 在瀏覽器裡驗 DKIM，用的是現在的金鑰 這一頁的招牌是真的做一次 DKIM 驗證（RFC 6376），而不是照抄別人的結論。每一條 `DKIM-Signature` 都會解析 tag、依 `s=` 和 `d=` 查公鑰、照 `c=` 指定的方式把簽過的標頭正規化，再用 WebCrypto 驗簽章。`h=` 列了但信裡沒有的標頭一律當成空字串，這正是標準的規定，事後補上去的標頭不可能過。`rsa-sha256` 用 RSASSA-PKCS1-v1_5 驗；`ed25519-sha256`（RFC 8463）在瀏覽器的 WebCrypto 有 Ed25519 時驗，沒有的話結果是「無法驗證」而不是失敗；`rsa-sha1` 照驗但標示 RFC 8301 已淘汰，RSA 金鑰短於 1024 位元則依該 RFC 直接拒絕。結論只有四種：通過、失敗（附原因：找不到金鑰、`p=` 空代表金鑰已撤銷、`x=` 已過期、簽章不符、body hash 不符、金鑰太短）、無法驗證（DNS 查詢失敗、演算法不支援、沒有內文）、格式錯誤。簽章有 `l=` 時會警告：簽章只涵蓋內文前 N 個位元組，後面接上去的東西沒有簽。要記得查到的是現在公布的金鑰：寄件者換過金鑰之後，舊信會驗證失敗，但那不代表信是假的。 ### 只有標頭、.eml、.msg 各驗得到什麼 只有完整的 `.eml` 才驗得了內文雜湊 `bh=`，因為需要內文的原始位元組。只貼標頭的話，頁面仍然會驗標頭簽章——它涵蓋了 `bh=` 這個值——結論寫「標頭未被竄改，內文無法驗證」。`.msg` 永遠是這種情況：收到的信存成 `.msg` 時，Outlook 把傳輸標頭存成一個屬性，但沒有保留原始的 MIME 內文（寄出前存的 `.msg` 則根本沒有傳輸標頭），所以 `.msg` 一律只能驗到標頭這一層。從 EML 檢視器和 MSG 檢視器都有一個連結可以直接把信帶過來，走的是 sessionStorage，不經過網址。概要卡把寄件者的三個身分並排：`From` 的網域、`Return-Path` 的網域、DKIM `d=` 的網域，DMARC 對齊依 RFC 7489 的 relaxed 模式用組織網域來判斷，旁邊有一顆按鈕可以把 `From` 網域帶去郵件 DNS 檢查頁查 SPF、DKIM、DMARC 設定——只有那個網域會進網址，它本來就是公開資訊。 ### 這一頁不會替你說的話 它絕不會說「這封信是安全的」或「是真的」，只說哪些檢查通過、哪些失敗。DKIM 通過只證明 `d=` 那個網域簽過這封信，不證明那個網域就是你以為的那家公司。SPF 不重驗：SPF 看的是把信交給你伺服器的那個 IP 能不能替 `Return-Path` 網域寄信，要用當時的 DNS 判斷，事後從你的瀏覽器再跑一次沒有意義，所以頁面只顯示收件伺服器記下來的結果。被轉寄、經過郵件列表、被公司郵件閘道改寫過的信，DKIM 失敗很常見也很正常，失敗說明裡會直接寫出來。`X-Spam-Status`、`X-Microsoft-Antispam` 這類垃圾信評分標頭只列原文、不解讀，因為格式沒有公開。Markdown 報告和 JSON 匯出預設會遮掉收件者地址，方便你拿去分享。 ## Limits Does not re-check SPF, look up IP locations or say whether a message is safe; it reads the headers and verifies DKIM signatures locally. ## FAQ ### 我的信為什麼被丟進垃圾信匣？ 標頭能回答一部分。先看你的收件伺服器寫的、最上面那條 `Authentication-Results`：裡面有 `dkim=fail`、`spf=softfail` 或 `dmarc=fail`，或是 `From` 網域跟 DKIM `d=`、`Return-Path` 網域對不齊，都是進垃圾信匣的強烈理由。`X-Spam-Status` 之類的評分標頭也會照原文列出來。標頭看不出來的是寄件者信譽、信件內容和寄信量，而這些偏偏是過濾器最看重的。如果你就是寄件者，到郵件 DNS 檢查頁查一下網域的 SPF、DKIM、DMARC 設定——概要卡上有直達的連結。 ### 這封說是銀行寄的信，怎麼判斷是不是假冒郵件？ 先比對概要卡上的三個身分：收件人看到的 `From` 網域、`Return-Path` 網域、DKIM 的 `d=` 網域，然後按「驗證 DKIM」。簽章有效，代表控制 `d=` 那個網域的人簽過這封信，而且簽過的標頭之後沒被改過——所以要確認 `d=` 真的是銀行的網域，而不是長得很像的假網域。另外只看你自己收件伺服器寫的那條 `Authentication-Results`，不要看路上被加進去的。這一頁刻意不說「這封信是安全的」，只報告哪些檢查過了。有疑慮就用你原本就信得過的管道聯絡銀行。 ### 明明是真的信，為什麼 DKIM 驗證失敗？ 最常見三個原因。第一，信被轉寄過、經過郵件列表、或是被公司的郵件閘道改寫——只要簽過的標頭或內文被動到（加個主旨前綴、加個頁尾），簽章就會壞，這很正常。第二，寄件者在這封信寄出之後換過 DKIM 金鑰——驗證用的是今天 DNS 上的金鑰，舊信會失敗但不是假的。第三，複製的時候信被弄壞了：貼上的文字如果掉了換行或行尾空白，就對不起來。失敗的意思是「現在驗不過」，單憑這一點不能說它是偽造的。 ### 這封信為什麼延遲？卡在哪一站？ 往下捲到傳遞路徑。每一個 `Received` 跳站都用橫條畫出和前一站相隔多久，最長的那一條標紅——信就是在那一站等的，通常是在 `by` 那台主機的佇列裡排隊。延遲是負值代表兩台伺服器的時鐘對不齊，不是時間倒流；沒有可用時間的站會標「無法計算」，後面的站照常算。 ### 這一頁會把什麼送上網路？ 在你按「驗證 DKIM」之前，什麼都不送。按了之後，每一條簽章會發一個 DNS 查詢，查 `selector._domainkey.網域`，送到 Cloudflare 的 DNS-over-HTTPS 服務，失敗時改送 Google 的。這兩家看得到被查的名稱和你的 IP，任何 DNS 解析服務都是這樣。信件、標頭、收件者和驗證結果都不會送給任何人，包括這個網站。沒有網路時傳遞路徑和 Authentication-Results 照常顯示，DKIM 會顯示 DNS 錯誤。 ### 只有標頭、或是 .msg 檔，驗得了 DKIM 嗎？ 驗得了一部分。DKIM 簽章涵蓋兩樣東西：指定的那些標頭，以及存在 `bh=` 裡的內文雜湊。只有標頭的時候，標頭簽章還是驗得了，所以你會知道標頭——包括 `bh=` 這個值——沒被動過；內文本身因為不在手上，沒辦法驗。Outlook 的 `.msg` 只保留傳輸標頭、沒有原始的 MIME 內文，所以 `.msg` 一律是這種「只驗標頭」的結論。要連內文一起驗，請拖入原始的 `.eml`。 ### 為什麼不重新驗 SPF？ 因為 SPF 事後驗不了。SPF 問的是：把信交給你伺服器的那個 IP，當時能不能替 `Return-Path` 網域寄信，而且要用當時的 DNS 記錄判斷。之後從你的瀏覽器再查一次，IP 不一樣、記錄也可能變了，答案沒有意義。所以頁面只顯示你的收件伺服器記在 `Authentication-Results` 裡的 SPF 結果。DKIM 不一樣：簽章跟著信走，任何人拿到公鑰都能驗，所以頁面自己驗。 ### 好幾條 Authentication-Results，該信哪一條？ 只信你自己的收件伺服器寫的那一條，通常在最上面，authserv-id 是你郵件服務商的主機名稱。路上任何一台伺服器、以及寄件者本人，都可以塞一條寫著 `dkim=pass` 的 `Authentication-Results`，偽造的人更有動機這麼做。頁面會把每一條的 authserv-id 顯示出來讓你分辨，並且在清單上方再提醒一次。ARC 標頭只列出來參考，這一版不驗證。 ## Related tools - [Email DNS Check](https://bytescope.dev/zh-Hant/email-dns-check.md) — 檢查網域的 SPF、DKIM、DMARC、MX 和 MTA-STS 記錄 → - [EML Viewer](https://bytescope.dev/zh-Hant/eml-viewer.md) — 打開 .eml 信件：標頭、內文和附件 → - [MSG Viewer](https://bytescope.dev/zh-Hant/msg-viewer.md) — 不用 Outlook 也能打開 .msg 檔 →