輸入一個網域，每種記錄一張卡——MX、SPF、DMARC、DKIM、BIMI、MTA-STS、TLS-RPT——每張都分成現況、為什麼重要、怎麼改三段，附可以直接貼進 DNS 的範例記錄。SPF 樹把每一層 include 展開，查詢次數對照 10 次的上限。不打分數、不用註冊。
檔案不會離開你的瀏覽器 — 全部在本機處理。
大部分的郵件投遞問題，追到最後都是幾筆很容易設錯的 DNS 記錄：SPF 不知不覺超過查詢上限、DMARC 放在 p=none 放了好幾年、DKIM 金鑰已經撤銷或太短。這個 DMARC 檢查、SPF 記錄檢查、DKIM 記錄查詢工具直接在瀏覽器裡把這些記錄讀出來。輸入一個網域（貼整個網址或 email 地址也可以，頁面會自己抽出網域，國際化網域會轉成 punycode 並同時顯示兩種寫法），要的話再填你用的 DKIM selector。頁面把記錄名稱——example.com、_dmarc.example.com、selector._domainkey.example.com 等等——送到 Cloudflare 的公開 DNS-over-HTTPS 服務查詢，失敗時改用 Google。該服務看得到這些名稱和你的 IP，任何 DNS 解析都是這樣；不會送出任何信件，也不會送出你 IP 以外的任何東西。結果是每張卡一顆燈加一顆整體燈號：綠色代表記錄都設對了，黃色代表信寄得出去但有風險，紅色代表信很可能被擋、或網域對偽冒不設防。
RFC 7208 規定一次 SPF 評估最多只能有十個會查 DNS 的機制——include、a、mx、ptr、exists、redirect 都算，巢狀的 include 也算。超過就是 permerror，很多收件端把它當成根本沒設 SPF。頁面把 include: 和 redirect= 遞迴展開成一棵樹，每個節點都標出查詢次數，你一眼就看得出哪個 include 最花。a、mx、ptr、exists 只計入上限、不實際查詢，因為它們的目標不影響次數。include 指向的網域沒有記錄會算成 void lookup，上限兩次。頁面也會標出：不只一筆 v=spf1（permerror）、+all 和 ?all（等於誰都能寄）、已不建議使用的 ptr、語法錯誤、include 迴圈——迴圈只看祖先路徑，同一個 include 從兩個分支各引用一次是合法的，會跟收件端一樣計兩次。超過上限時給的建議是：把不再使用的寄信服務的 include 拿掉，或是把某個寄信服務搬到它自己的子網域。頁面刻意不提供 SPF flattening——把 include 換成它今天解析出來的 IP——因為那些 IP 說變就變，寄信服務一換 IP 區段，攤平後的記錄當天就壞。
頁面查 _dmarc.<網域>，子網域自己沒有記錄時依 RFC 7489 退回組織網域去查，組織網域用 Public Suffix List 判斷。報告的內容有政策（p=）、子網域政策（sp=）、pct=、對齊模式 adkim= 和 aspf=、以及回報地址 rua= 和 ruf=。p=none 會標成「只監看」：收件端只回報、不動作，網域照樣可以被冒用；pct 低於 100 代表只對一部分失敗的信動作。rua= 指向別的網域的信箱時，頁面會去找授權記錄 <網域>._report._dmarc.<回報網域>，找不到就警告「報告不會被送出」。建議的路線是不會弄壞寄信的那一條：先從 p=none; rua=mailto:… 開始，讀報告直到所有合法的寄件來源都對齊了，再改成 quarantine，最後 reject。
DKIM selector 從外面沒辦法列舉——DNS 沒有任何方法可以列出 *._domainkey 底下有哪些名稱——所以頁面只能試你填的 selector 加上一份常見名稱清單（google、selector1、selector2、k1、s1、s2、default、dkim、mail 等等）。「沒找到」的意思是這些名稱底下沒找到，絕不等於沒設 DKIM。找到的金鑰會檢查長度（RSA 短於 1024 位元標紅、剛好 1024 標黃）、p= 是否為空（代表已撤銷）、有沒有 t=y 測試模式、語法對不對。MX 依優先序列出並附上位址；沒有 MX 會標出來、MX 指向 CNAME 會標出來，而 Null MX（0 .，RFC 7505）會被當成「這個網域不收信」的正確寫法，不是錯誤。BIMI（default._bimi）檢查格式並列出 l= 的圖檔網址和 a= 的憑證網址；圖檔本身不抓，卡片上也會提醒 BIMI 只在 DMARC 是 quarantine 或 reject 時才會生效。MTA-STS（RFC 8461）和 TLS-RPT（RFC 8460）只檢查 DNS 這一層：瀏覽器因為 CORS 抓不到 https://mta-sts.<網域>/.well-known/mta-sts.txt，所以 policy 網址只顯示成連結讓你自己點開。
顯示的記錄是 Cloudflare 或 Google 的解析服務此刻看到的。幾分鐘前剛改的記錄可能還在快取裡，要等 TTL 過了才會更新，再查一次之前先別以為改失敗了。綠燈代表記錄設對了，不代表信一定進收件匣：寄件者信譽、信件內容、寄信量才是決定因素，而這些從 DNS 完全看不出來。同樣的理由，這一頁不給分數——「87 分」看起來很精確，其實什麼都沒說。如果是某一封特定的信被退或進了垃圾信匣，把它的標頭丟到郵件標頭分析頁，那邊會追蹤傳遞路徑、驗證 DKIM，概要卡還會帶著寄件網域連回這裡。兩頁都能產出 Markdown 報告和 JSON，直接貼進工單。
看 SPF 樹：每個 include、a、mx、ptr、exists、redirect 都算一次，巢狀的 include 也算，上限十次。先把已經不再使用的寄信服務的 include 刪掉——舊的電子報工具和 CRM 是最常見的元兇。還是超過的話，把其中一個寄信服務搬到自己的子網域、給它自己的 SPF 記錄，例如電子報平台用 news.example.com。不要把記錄攤平成 IP：服務商的 IP 區段說換就換，攤平後的記錄會在那一天悄悄壞掉。
當起點夠，當終點不夠。p=none 只會讓收件端寄報告給你——驗證失敗的信照樣投遞，所以任何人都能冒你的網域寄信，大多數收件端還是會收。p=none 這個階段拿來讀 rua= 報告、找出還沒對齊的合法寄件來源，然後改成 p=quarantine，最後 p=reject。BIMI 的品牌圖示也要 quarantine 或 reject 才會顯示。頁面把 p=none 標成「只監看」就是這個原因。
不是。DKIM 記錄住在 <selector>._domainkey.<網域>，而 DNS 沒有辦法列出有哪些 selector，所以頁面只能試你填的名稱加一份常見清單。你的服務商用的 selector 如果不在清單上，自己填進來——它寫在服務商的 DKIM 設定頁，或是你寄出的任何一封信 DKIM-Signature 標頭裡的 s=，郵件標頭分析頁會把它顯示出來。「沒找到」只代表試過的名稱底下沒找到，沒有別的意思。
DNS 回應會依記錄的 TTL 被快取，而頁面讀到的是 Cloudflare 的解析服務（備援是 Google）現在手上的版本。幾分鐘前改的記錄在 TTL 過完之前都可能還是舊的——常常是一小時，有時候一整天。等 TTL 過了再查一次。
因為記錄設對只是必要條件，不是充分條件。收件端還會看你網域和寄信 IP 的信譽、信的內容、收件人的反應、寄信量有沒有突然暴增——這些從 DNS 完全看不到，這也是這一頁不給投遞分數的原因。從一封確實進了垃圾信匣的信下手：把它的標頭丟到郵件標頭分析頁，看收件伺服器實際跑了哪些檢查、DKIM 有沒有跟 From 網域對齊、垃圾信過濾器的標頭寫了什麼。
因為數字會假裝精確。每項檢查對不同網域的重要性完全不同——缺 MX 對收信的網域是致命的，對不收信的網域卻是正確的；p=none 對剛開始建置 DMARC 的網域是合理的第一步，對已經寄了好幾年信的網域卻是漏洞。頁面改用每張卡一顆燈加一顆整體燈號：綠、黃（寄得出去但有風險）、紅（很可能被擋或對偽冒不設防），每張卡再告訴你該改什麼。
只有你輸入那個網域的記錄名稱的 DNS 查詢——網域本身、_dmarc.、_domainkey.、_bimi.、_mta-sts.、_smtp._tls. 這些名稱——送到 Cloudflare 的 DNS-over-HTTPS 服務，Cloudflare 失敗時改送 Google。這兩家看得到名稱和你的 IP，每一次 DNS 查詢都是這樣。網域本身是公開資訊；沒有信件、沒有通訊錄、沒有其他東西會送出。分析事件只記錄「有人跑了一次檢查」，不記錄網域。
應該設一筆 Null MX：唯一一筆 MX，優先序 0、目標是 .（RFC 7505）。這等於告訴寄件端「這個網域不收信」，對方會立刻放棄，而不是對著 A 記錄重試好幾天。頁面會把 Null MX 當成正確設定，不會報成缺 MX。這種網域還是該設 v=spf1 -all 和 p=reject 的 DMARC，才沒有人能冒用它寄信。
貼上信件標頭，看傳遞路徑、驗證 DKIM →
安全地打開 .eml 檔來看 →
沒有 Outlook 也能打開 .msg 檔 →
解讀 TLS 憑證、檢查有效期限 →