記錄必須位於 DMARC 擁有者名稱
以 example.com 為例，接收方會查詢 _dmarc.example.com。發布在根網域或其他任意主機上的 v=DMARC1 字串，並不會成為該網域的 DMARC 政策。
應只回傳一筆適用的 DMARC 記錄。重複或格式錯誤的政策會造成不確定性，而非多層保護。
免費工具
DMARC 記錄檢查器
輸入任何網域即可擷取並分析其 DMARC 記錄。查看執行政策、對齊設定、回報地址與設定狀態。
什麼是 DMARC 記錄？
DMARC（Domain-based Message Authentication, Reporting and Conformance）是發布於 DNS 的電子郵件驗證政策。它告訴接收郵件伺服器，當 SPF 與 DKIM 檢查失敗時該如何處理，並指示它們將網域上的驗證活動回報給你。DMARC 是電子郵件驗證的最後一塊拼圖——它把 SPF 與 DKIM 整合成一套連貫的政策。
DMARC 記錄以 TXT 記錄發布在子網域 _dmarc.yourdomain.com。最重要的標籤是設定政策的 p=：none 表示不採取行動（監控模式），quarantine 表示將失敗郵件送入垃圾郵件，reject 表示完全阻擋。多數網域先從 none 開始，確認所有合法寄件者都已正確驗證後，再逐步升級到 reject。
DMARC 的回報功能特別有價值。當你加入 rua（彙總報告的回報 URI）地址後，Gmail、Outlook 與 Yahoo 等主要 ISP 會每天向你發送 XML 報告，列出所有聲稱來自你網域的寄信 IP。這些報告可協助你找出未授權寄件者、發現設定錯誤的服務，並持續監控驗證健康狀況。
DMARC 記錄標籤說明
p=（政策）
核心執行政策：none、quarantine 或 reject。
sp=（子網域政策）
子網域政策。未設定時繼承 p=。
pct=（百分比）
政策套用的郵件百分比。預設為 100。
rua=（彙總報告）
用於接收每日彙總報告的電子郵件地址或 URI。
ruf=（鑑識報告）
用於接收含郵件樣本的失敗報告之電子郵件地址。
adkim=（DKIM 對齊）
r=relaxed（預設）、s=strict。嚴格模式要求網域完全相符。
aspf=（SPF 對齊）
r=relaxed（預設）、s=strict。嚴格模式要求 envelope-from 完全相符。
fo=（失敗選項）
何時發送鑑識報告：0=兩者皆失敗（預設）、1=任一失敗、d=DKIM 失敗、s=SPF 失敗。
已發布政策證據
DMARC 檢查器從 _dmarc.yourdomain.com 讀取的內容
檢查器會擷取公開的 TXT 政策、解析標籤，並顯示接收方應對未通過對齊驗證的郵件採取的處置。
政策只有在具備對齊證據時才有意義
當已驗證的 SPF 或 DKIM 識別碼與可見 From 網域對齊時，DMARC 即通過。檢查器可以讀取 p=、adkim 與 aspf，但無法看到從未提供之郵件的 Authentication-Results。
將已發布的記錄視為網域的指示，再以實際郵件測試各寄件來源是否能滿足該政策。
政策解讀
如何解讀 DMARC 檢查結果，避免高估保護程度
每項結果描述的是設定。實際執行與回報取決於接收方，以及真實郵件的驗證結果。
沒有記錄代表未發現 DMARC 政策
SPF 與 DKIM 仍可能存在，但接收方沒有來自此擁有者名稱的 DMARC 指示，也沒有此政策要求的彙總報告目的地。
p=none 是監控，不是執行
在盤點合法寄件來源期間，它能產出有價值的彙總報告，但不會要求對未通過對齊驗證的郵件進行隔離或拒收。
p=quarantine 或 reject 需要涵蓋合法來源
在判定較嚴格政策為健康之前，請確認重要的交易、辦公套件、行銷、客服與供應商寄信來源，都能通過對齊的 SPF 或 DKIM。
子網域行為可能來自 sp 或繼承
sp 標籤可為子網域指定政策。若未設定，則由 DMARC 的政策探索規則決定組織網域政策如何套用，因此請核對郵件實際使用的 From 網域。
稽核步驟
將 DMARC 記錄檢查器作為驗證稽核的其中一步
在變更執行強度前，先把 DNS 政策與報告、郵件標頭對上。
- 1
檢查可見的 From 網域
輸入 From 標頭中 @ 之後顯示的網域。若為子網域，請檢查確切名稱，並釐清套用的是直接政策還是繼承政策。
- 2
檢視政策、對齊、百分比與報告目的地
確認每個標籤都符合預期的上線節奏，且 rua 或 ruf 地址由你控管、在需要時已獲授權，並能安全處理報告。
- 3
檢查每個寄件來源的 SPF 與 DKIM
- 4
以受控的產生器流程變更政策
當設定需要調整時，使用 DMARC 記錄產生器，發布一筆更新後的 TXT 記錄，等待 TTL，再重新檢查。
查詢無法證明的事項
DMARC 記錄可能有效，但郵件方案仍未受保護
DNS 政策是必要證據，但不等於營運層面的合規。
檢查器看不到彙總報告
它無法識別活躍來源 IP、失敗量、未知供應商或偽造模式。這些事實存在於參與接收方送來的 rua 報告中。
檢查器無法證明接收方會執行該要求
DMARC 發布的是網域擁有者政策。各接收方仍會套用本地投遞與過濾決策，且未必會發送每一份被要求的報告。
檢查器無法診斷單封失敗郵件
郵件層級的調查需要 From 網域、return path、DKIM 簽章、Authentication-Results，以及相關的 Received 標頭。
檢查器無法驗證收件者
DMARC 驗證的是寄件網域。請使用電子郵件驗證器評估目的地信箱是否可投遞。
協定參考
RFC 7489 定義了此 DMARC 檢查器所解析的政策
當儀表板標籤掩蓋了對齊、探索或回報細節時，請查閱規範。
DMARC 將 RFC5322.From 與 SPF、DKIM 串連
IETF 的 RFC 7489 定義了政策探索、對齊識別碼、組織網域、接收方處置與回饋報告。
完整檢視需涵蓋整條驗證鏈
檢查 SPF 授權、DKIM 金鑰發布、DMARC 政策、實際郵件標頭與彙總報告。單一 DNS 結果無法取代其他層級。
相關電子郵件工具
依證據類型選擇下一個工具：收件者、探索、DNS 與基礎架構，或寄件工作流程。
免費工具
DMARC 產生器
建立含政策、對齊與報告選項的 DMARC DNS TXT 記錄。免費網域電子郵件驗證產生器。
網域或基礎架構證據——非信箱存在證明。
免費工具
SPF 檢查器
檢查並驗證任何網域的 SPF 記錄。查看完整 SPF 記錄、機制拆解，以及設定是否正確。免費、無需註冊。
網域或基礎架構證據——非信箱存在證明。
免費工具
DKIM 檢查器
檢查任何網域與選擇器的 DKIM 記錄。查看完整公鑰記錄，並確認 DKIM 簽署是否正確設定。免費使用，無需註冊。
網域或基礎架構證據——非信箱存在證明。
免費工具
DNS 檢查器
查詢任何網域的 A、AAAA、MX、TXT、NS 或 CNAME 記錄。即時 DNS 查詢，立即出結果。免費，無需註冊。
網域或基礎架構證據——非信箱存在證明。
郵件工具
郵件頭分析器
粘貼原始郵件頭，獲得結構化分析：SPF、DKIM、DMARC 結果、投遞路徑、垃圾郵件評分與關鍵元資料。免費，無需註冊。
寄件者或訊息診斷——非地址探索。
郵件工具
郵件送達率測試
對真實郵件樣本執行送達率測試。檢視 SPF、DKIM、DMARC、DNS、黑名單、垃圾郵件過濾、郵件頭與內容證據。
寄件者或訊息診斷——非地址探索。
常見問題
1. 網域沒有 DMARC 記錄代表什麼？
沒有 DMARC 記錄就沒有 DMARC 政策——接收伺服器不會依 DMARC 執行任何處置。這表示偽稱為你網域寄出的郵件，除了 SPF 與 DKIM 之外，沒有額外屏障。Google 與 Yahoo 現已要求大量寄件者必須有 DMARC 記錄（即使是 p=none）。凡寄送電子郵件的網域，至少應發布一筆監控用的 DMARC 記錄。
2. p=none、p=quarantine 與 p=reject 有何不同？
p=none 表示 DMARC 處於監控模式——收集報告，但不對失敗郵件採取行動。p=quarantine 指示接收伺服器將失敗郵件送入垃圾郵件匣。p=reject 表示失敗郵件應在進入收件匣前被完全阻擋。先從 none 開始，檢視報告 2 到 4 週，再逐步改為 quarantine 與 reject。
3. 什麼是 DMARC 對齊？
對齊是指通過 SPF 或 DKIM 的網域，必須與可見 From 標頭中的網域相符。寬鬆對齊允許子網域相符——mail.example.com 可與 example.com 對齊。嚴格對齊則要求完全一致。多數環境建議使用寬鬆對齊，以免轉寄與 ESP 寄出的郵件失效。
4. DMARC 彙總報告如何運作？
當你在 DMARC 記錄中加入 rua 電子郵件地址後，主要 ISP 會每天向你發送 XML 報告。每份報告包含：哪些 IP 以你的網域寄信、各 IP 寄出多少封郵件，以及 SPF 與 DKIM 通過或失敗。利用這些報告找出尚未正確設定驗證的合法寄件來源，並偵測偽造嘗試。
5. DMARC 會保護子網域嗎？
除非你設定了 sp= 標籤，否則主網域的 DMARC 政策會套用到子網域。若要保護子網域，請在 DMARC 記錄中加入 sp=reject 或 sp=quarantine。未設定 sp= 時，在寬鬆對齊下，子網域會繼承你的 p= 政策。
6. 可以將 pct 設為低於 100 嗎？
可以。設定 pct=25 表示 DMARC 政策只套用到 25% 的失敗郵件。這對逐步上線很有用——首次啟用 quarantine 或 reject 時，先從 10% 或 25% 開始，以降低合法郵件設定錯誤時的影響。確認沒有合法郵件失敗後，再提高到 100。