DMARC 記錄的組成結構與運作原理
DMARC（基於網域的郵件驗證、報告和一致性）是建基於 SPF（寄件者策略框架）和 DKIM（網域金鑰識別郵件）之上的電子郵件安全協定。一條完整的 DMARC TXT 記錄由多個以分號分隔的「鍵值對」（Tags）組成，並必須以區分大小寫的 v=DMARC1 作為開頭。
本工具專為郵件網域管理員設計，用於在發佈或排查 DMARC TXT 記錄前，分析其結構、政策選擇、對齊設定及報告地址語法。
核心宣告與順序規則
- 版本宣告：DMARC 記錄必須以
v=DMARC1開頭，且此標記必須是整條記錄的第一個項目。若順序錯誤或缺失，收件方伺服器將無法正確識別該記錄。 - 政策繼承與回退機制：DMARC 允許針對主網域（
p）、子網域（sp）及不存在的子網域（np）設定不同的處置政策。當缺乏具體標記時，子網域政策會依據np→sp→p的順序向後回退。若整條記錄未包含p標記，網域政策將預設回退至none。
DMARC 政策標記的影響
DMARC 政策決定了收件方郵件伺服器如何處理未通過 SPF 或 DKIM 驗證的郵件。
| 政策標記 | 說明與影響 |
|---|---|
p=none |
僅監控郵件傳送狀態並收集報告，不會要求收件方隔離或拒絕失敗的郵件。 |
t=y |
測試模式。在此模式下，安全政策會被降級：原本的 reject（拒絕）會降級為 quarantine（隔離），而 quarantine 則會降級為 none。 |
pct |
歷史遺留的百分比標記。此設定僅對仍遵循舊版 DMARC 規範的收件系統起作用，用以限制政策的覆蓋範圍。 |
報告機制與對齊設定
DMARC 的核心功能之一是向網域擁有者發送反饋報告，幫助管理員監控偽冒郵件。
報告類型與限制
- 總合報告（
rua）：若記錄中沒有提供有效的rua地址，收件方將不會發送總合報告。 - 失敗報告（
ruf）：用於傳送單封郵件驗證失敗的詳細資訊。 - 報告大小限制：在報告 URI 後方加上
!size後綴的語法在當前標準中已經過時，現代收件系統會直接忽略此限制。 - 失敗報告選項（
fo）：若記錄中沒有配置有效的ruf失敗報告地址，則fo標記將會被直接忽略。
瀏覽器端解析與隱私保護
本工具採用完全本地化的處理機制。你的 DMARC 記錄只會保留在瀏覽器內。BroBroGo 不會上載或儲存記錄。輸入的文字不會寫入瀏覽器儲存空間，解析過程中亦不會向外發送任何與記錄相關的網絡請求。
本工具的輸入限制為 20,000 個字元以內。如果貼上的 DNS TXT 記錄中包含多個加上引號的分段，工具會在分析前自動將這些分段合併。
常見 DMARC 語法錯誤與提示
在配置 DMARC 記錄時，常見的語法與政策風險包括：
- 格式不規範：未採用分號分隔的
name=value鍵值對。 - 重複標記：在同一條記錄中多次宣告同一個標記。
- 無效值或空值：標記後方缺少具體數值，或填寫了不符合規範的參數。
- 未知或歷史標記：使用了未註冊的標記，或使用了在最新標準中已被視為歷史遺留的標記。
常見問題解答
語法和政策提示: p / sp / np?
p 代表主網域政策，sp 代表子網域政策，np 代表不存在的子網域政策。當郵件驗證失敗時，收件方會根據這些標記決定處置方式。若未定義具體標記，系統會按照 np → sp → p 的順序進行回退繼承。若完全缺失 p，則預設為 none。此外，若啟用測試模式 t=y，會將 reject 降級為 quarantine，並將 quarantine 降級為 none。
RFC 9989: pct / rf / ri?
根據最新的 DMARC 標準（RFC 9989），部分在舊版本（RFC 7489）中定義的標記已被列為歷史遺留或被棄用。例如 pct（百分比限制）已被視為歷史標記，現代收件系統在處理時可能會忽略它。而 np（不存在的子網域政策）在當前標準中則是活躍且受支持的標記。
檢查結果沒有問題，是否能證明我的 DMARC 設定有效？
不能。此頁面只檢查你貼上的文字，不會查詢 DNS、展開服務供應商記錄、測試寄件者 IP，也不會確認收件郵件伺服器將傳回甚麼結果。要確保 DMARC 實際生效，你必須將正確的記錄發佈至網域的 DNS 伺服器中，並確保 SPF 和 DKIM 已正確配置。