A DMARC記錄 是一個DNS TXT記錄 以適用的_dmarc名稱發布。它說明網域擁有者的策略並可以請求身份驗證回饋。建立一個需要一個預期的策略、一個有效的DNS發布路徑以及一種驗證真實郵件發生情況的方法。
本指南遵循從準備到驗收的設定。它使用新的受監控部署作為範例。如果網域已經有更嚴格的核准策略，請在進行變更之前檢查現有狀態。此範例是教學記錄，而不是替換每個域配置的指令。
確定域的使用方式
在批准策略之前，請詢問該網域是否發送員工郵件、應用程式通知、活動或根本不發送合法郵件。包括外包服務和定期流量。域的目的決定了團隊需要發現和測試的內容。
第一個有用的交付物是所有者和服務列表，而不是執行百分比。如果企業已經使用限制性政策，詢問有什麼證據證明改變它是合理的。初學者的監控範例不應自動取代操作控制。
指派專人接收和審查報告。請求無人收集的回饋的配置會讓企業失去部署本應創建的證據。
檢查發送身份和DNS訪問
協議參考： RFC 9989 §4.4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.5, RFC 9989 §8。下面的操作清單和決定是編輯指南。
確定可見的發送域、其權威DNS提供者、允許編輯區域的人員以及批准的恢復過程。儲存目前記錄集。
對於每個合法的發送路由，建立 SPF 評估的信封身分並 DKIM 簽署身份。 DMARC 需要傳球對齊 SPF 或DKIM路徑。全面參與需要SPF和DKIM一致 RFC 9989 §8，即使一條經過的對齊路徑可以滿足訊息級規則。
使用 Microsoft 365 或者 Google Workspace 當這些是實際發送服務時的說明。包括使用不同提供者的任何應用程式。
建立預期記錄
協議參考： RFC 9989 §4.5, RFC 9989 §4.7, RFC 9990 §4。下面的操作清單和決定是編輯指南。
對於開始受監控部署的網域，以下是說明性的開始記錄：
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com將該值發佈為TXT記錄： _dmarc.example.com。在接受相對名稱的DNS編輯器中 example.com 區域，擁有者可以輸入為 _dmarc。其他編輯希望得到全名。驗證提供者的進入模型，而不是假設一種形式在任何地方都適用。
- 部分： v=DMARC1;本例中的意義： DMARC版本標記；它屬於第一
- 部分： p=none;此範例中的意義：沒有網域擁有者對DMARC失敗的處理首選項
- 部分： rua=mailto:...;本例中的意義：請求 總結報告 到批准的目的地
此範例使用同域報告地址並假設那裡的收集工作正常。將其替換為實際批准的目的地。相關域關係以外的目的地可能需要由接收域控制的單獨權限記錄。
請勿複製 example.com 進入生產記錄。當已有一條 DMARC 策略記錄存在時，請勿新增第二筆DMARC策略記錄。查看並更新現有記錄集。
驗證權威DNS答案
協議參考： RFC 9989 §4.5, RFC 9989 §4.10.1, RFC 2308 §5, RFC 8767 §4。下面的操作清單和決定是編輯指南。
命令語法和選項如下 ISC的挖掘參考。直接查詢禁用遞歸；檢查權威答案標誌和完整的回應上下文。
從確切的所有者名稱開始：
挖掘_dmarc.example.com 。 TXT +noall +評論 +答案 +權威辨識該區域的委派權威伺服器，然後直接查詢相關權限。例如，使用實際的權威伺服器來代替下面的說明性伺服器：
挖掘@ ns1.example.net 。 _dmarc.example.com 。 TXT +norecurse +noall +評論 +答案 +權威檢查名稱、記錄類型、完整值和記錄集邊界。一筆TXT記錄可以包含多個字串；這與幾個單獨的候選人政策記錄不同。確認權威後比較遞歸答案，同時考慮正緩存和負緩存。
如果沒有預期的答案，請按照 缺失記錄診斷。避免重複將相同的策略新增到不同的控制面板。
透過重要路線測試真實消息
協議參考： RFC 9989 §5.3.5, RFC 8601 §7.1。下面的操作清單和決定是編輯指南。
將受控訊息發送給單獨的收件人並在那裡保留原始訊息。檢查接收系統的可信賴結果、可見的寄件者域、 SPF身分和每個相關的 DKIM簽名.
假設適用的有效策略並已完成身份驗證檢查。這個綜合範例說明了為什麼成功的記錄檢查還不夠：
- 觀察： DMARC TXT記錄；結果：出現在預期名稱處
- 觀察： SPF ；結果：傳遞給不相關的提供者域
- 觀察： DKIM ；結果：沒有對齊的傳遞簽名
- 觀察： DMARC傳遞路徑；結果：不成立
修復支援的發送配置，而不是將DNS存在視為成功。修正後重複測試並保留變化和觀察結果。這 對齊指南 解釋了身份比較。
確認報告到達收集系統
協議參考： RFC 9989 §5.3.8, RFC 9990 §3.1。下面的操作清單和決定是編輯指南。
檢查收集目的地是否接受郵件以及是否可以處理報告。觀察報告接收者的代表性流量並保留報告者身分和報告週期。
所請求的報告不能保證來自每個接收者，而且它們並不代表組織發送的每個訊息。缺少回饋可能反映參與、流量、目的地、過濾或處理問題。調查這些階段而不是宣布該域安靜。
設定驗收標準
需要配置、關鍵訊息身份驗證、收集和所有權的證據。在變更要求的政策之前，請先查看間接郵件和未解決的例外情況。
擷取準確的變更、其批准者、先前狀態和驗證結果。定義在合法通訊中斷時何時恢復先前核准的配置。回滾應該保留調查線索。
對於初始部署，監控是一個證據收集階段。這不是拒絕的自動日曆倒數。使用 監測決策指南 確定下一個政策決定所需的調查結果。
實用的外賣
將DNS記錄、身份驗證測試和報告路徑視為一種實作。當這些檢查完成後，保留配置、擁有者和未解決的異常。任何後續的執行決定都應遵循域名的實際使用和證據。
應用證據而不誇大其詞
分別保留遞歸和權威回應。空洞的答案需要地位和權威背景；這並不是自動缺席。 TTL 過期不是全域撤銷期限，因為合格的服務過時行為可以保留超過新鮮度的資料。命令為未執行的教學實例；報告收集和訊息測試仍然是運營商的驗收工作。