把 Gmail「顯示原始郵件」或 Outlook「郵件標頭」裡那一段貼進來，或是直接拖入 .eml、.msg 檔。頁面會把每一個 Received 跳站和它的延遲列出來、解釋每一條 Authentication-Results，並且用寄件網域公開的金鑰重新驗證 DKIM 簽章。整封信都留在你的瀏覽器裡。
檔案不會離開你的瀏覽器 — 全部在本機處理。
Gmail：⋮ →「顯示原始郵件」。Outlook：檔案 → 內容 →「網際網路標頭」。從頭到尾整段貼上。
或把 .eml、.msg 檔拖進來
檔案只在這個分頁裡讀，不會上傳。
<selector>._domainkey.<domain> 送到公開的 DNS 服務（Cloudflare，Google 備援）查公鑰。信件內容、收件者和標頭本身都不會送出去。大家看郵件標頭通常是為了三件事：這封信為什麼晚了兩個小時才到、這封說是銀行寄的信到底是不是真的、我的信為什麼被丟進垃圾信匣。用肉眼讀很累——十幾行倒著排的 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（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 驗證（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 才驗得了內文雜湊 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 匯出預設會遮掉收件者地址，方便你拿去分享。
標頭能回答一部分。先看你的收件伺服器寫的、最上面那條 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 金鑰——驗證用的是今天 DNS 上的金鑰，舊信會失敗但不是假的。第三，複製的時候信被弄壞了：貼上的文字如果掉了換行或行尾空白，就對不起來。失敗的意思是「現在驗不過」，單憑這一點不能說它是偽造的。
往下捲到傳遞路徑。每一個 Received 跳站都用橫條畫出和前一站相隔多久，最長的那一條標紅——信就是在那一站等的，通常是在 by 那台主機的佇列裡排隊。延遲是負值代表兩台伺服器的時鐘對不齊，不是時間倒流；沒有可用時間的站會標「無法計算」，後面的站照常算。
在你按「驗證 DKIM」之前，什麼都不送。按了之後，每一條簽章會發一個 DNS 查詢，查 selector._domainkey.網域，送到 Cloudflare 的 DNS-over-HTTPS 服務，失敗時改送 Google 的。這兩家看得到被查的名稱和你的 IP，任何 DNS 解析服務都是這樣。信件、標頭、收件者和驗證結果都不會送給任何人，包括這個網站。沒有網路時傳遞路徑和 Authentication-Results 照常顯示，DKIM 會顯示 DNS 錯誤。
驗得了一部分。DKIM 簽章涵蓋兩樣東西：指定的那些標頭，以及存在 bh= 裡的內文雜湊。只有標頭的時候，標頭簽章還是驗得了，所以你會知道標頭——包括 bh= 這個值——沒被動過；內文本身因為不在手上，沒辦法驗。Outlook 的 .msg 只保留傳輸標頭、沒有原始的 MIME 內文，所以 .msg 一律是這種「只驗標頭」的結論。要連內文一起驗，請拖入原始的 .eml。
因為 SPF 事後驗不了。SPF 問的是：把信交給你伺服器的那個 IP，當時能不能替 Return-Path 網域寄信，而且要用當時的 DNS 記錄判斷。之後從你的瀏覽器再查一次，IP 不一樣、記錄也可能變了，答案沒有意義。所以頁面只顯示你的收件伺服器記在 Authentication-Results 裡的 SPF 結果。DKIM 不一樣：簽章跟著信走，任何人拿到公鑰都能驗，所以頁面自己驗。
只信你自己的收件伺服器寫的那一條，通常在最上面，authserv-id 是你郵件服務商的主機名稱。路上任何一台伺服器、以及寄件者本人，都可以塞一條寫著 dkim=pass 的 Authentication-Results，偽造的人更有動機這麼做。頁面會把每一條的 authserv-id 顯示出來讓你分辨，並且在清單上方再提醒一次。ARC 標頭只列出來參考，這一版不驗證。
檢查網域的 SPF、DKIM、DMARC、MX 和 MTA-STS 記錄 →
打開 .eml 信件：標頭、內文和附件 →
不用 Outlook 也能打開 .msg 檔 →