# Email DNS Check > 輸入網域就能在瀏覽器裡檢查 SPF、DKIM、DMARC、MX、BIMI、MTA-STS：SPF 查詢樹和 10 次上限、DMARC 政策、DKIM 金鑰長度，每項都附怎麼改的範例。不打分數。 - URL: https://bytescope.dev/zh-Hant/email-dns-check/ - Locale: zh-Hant · Also: [en](https://bytescope.dev/en/email-dns-check.md) · [ja](https://bytescope.dev/ja/email-dns-check.md) - Runs: 檔案不會離開你的瀏覽器 — 全部在本機處理。 - Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile. - Updated: 2026-09-08 ## What it does 大部分的郵件投遞問題，追到最後都是幾筆很容易設錯的 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 以外的任何東西。結果是每張卡一顆燈加一顆整體燈號：綠色代表記錄都設對了，黃色代表信寄得出去但有風險，紅色代表信很可能被擋、或網域對偽冒不設防。 ### SPF 的 10 次查詢上限，用一棵樹講清楚 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：從 p=none 走到真的能保護你的政策 頁面查 `_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、MX、BIMI、MTA-STS、TLS-RPT 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，直接貼進工單。 ## Limits Does not send test mail, flatten SPF or fetch MTA-STS policy files and BIMI logos; it checks the DNS records only. ## FAQ ### SPF 超過 10 次 DNS 查詢，要怎麼修？ 看 SPF 樹：每個 `include`、`a`、`mx`、`ptr`、`exists`、`redirect` 都算一次，巢狀的 include 也算，上限十次。先把已經不再使用的寄信服務的 include 刪掉——舊的電子報工具和 CRM 是最常見的元兇。還是超過的話，把其中一個寄信服務搬到自己的子網域、給它自己的 SPF 記錄，例如電子報平台用 `news.example.com`。不要把記錄攤平成 IP：服務商的 IP 區段說換就換，攤平後的記錄會在那一天悄悄壞掉。 ### DMARC 設 p=none 夠嗎？ 當起點夠，當終點不夠。`p=none` 只會讓收件端寄報告給你——驗證失敗的信照樣投遞，所以任何人都能冒你的網域寄信，大多數收件端還是會收。`p=none` 這個階段拿來讀 `rua=` 報告、找出還沒對齊的合法寄件來源，然後改成 `p=quarantine`，最後 `p=reject`。BIMI 的品牌圖示也要 `quarantine` 或 `reject` 才會顯示。頁面把 `p=none` 標成「只監看」就是這個原因。 ### DKIM 檢查說「沒找到」，代表沒設 DKIM 嗎？ 不是。DKIM 記錄住在 `._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 查詢都是這樣。網域本身是公開資訊；沒有信件、沒有通訊錄、沒有其他東西會送出。分析事件只記錄「有人跑了一次檢查」，不記錄網域。 ### 從來不收信的網域也需要 MX 記錄嗎？ 應該設一筆 Null MX：唯一一筆 MX，優先序 0、目標是 `.`（RFC 7505）。這等於告訴寄件端「這個網域不收信」，對方會立刻放棄，而不是對著 A 記錄重試好幾天。頁面會把 Null MX 當成正確設定，不會報成缺 MX。這種網域還是該設 `v=spf1 -all` 和 `p=reject` 的 DMARC，才沒有人能冒用它寄信。 ## Related tools - [Email Header Analyzer](https://bytescope.dev/zh-Hant/email-header-analyzer.md) — 貼上信件標頭，看傳遞路徑、驗證 DKIM → - [EML Viewer](https://bytescope.dev/zh-Hant/eml-viewer.md) — 安全地打開 .eml 檔來看 → - [MSG Viewer](https://bytescope.dev/zh-Hant/msg-viewer.md) — 沒有 Outlook 也能打開 .msg 檔 → - [Certificate Decoder](https://bytescope.dev/zh-Hant/certificate-decoder.md) — 解讀 TLS 憑證、檢查有效期限 →