網域對於您的組織來說可能是新的，但又不依賴郵件。新的註冊可能會被新網站使用，而獲得或重新註冊的名稱可能繼承了新所有者尚未發現的應用程式、轉發規則或期望。
第一個有用的 DMARC 因此，決定是一個有目的的決定。確定誰控制網域、將發送什麼、將接收什麼以及誰可以批准變更。然後配置並驗證該範圍的相關記錄。
建立一個小型目的暫存器
將網域視為擁有負責任的所有者的資產。記錄註冊商帳戶、權威DNS提供者、續約聯絡人、變更審核者和預期用途。管理權限應在員工離職後繼續存在。
繼續將發送和接收作為兩個單獨的欄位：
- 預期用途：僅限網站；發送問題：任何表格、支援工具或應用程式都可以使用此網域發送嗎？接收問題：客戶或服務需要這裡的地址嗎？
- 預期用途：交易產品郵件；傳送問題：哪些應用程式帳戶和復原路徑發送？接收問題：回覆、交付失敗和支援請求將去往何處？
- 預期用途：員工郵件；發送問題：哪些使用者、代表和連結的工具發送？ ；接收問題：存在哪些郵箱、別名和轉送路徑？
- 預期用途：防禦性註冊；發送問題：組織是否批准了任何發送？ ；收貨問題： 需要入境服務嗎？
這個建議的暫存器使隱藏的假設變得可見。 「沒有員工信箱」並表示網域不會傳送任何內容。
檢查不太明顯的郵件依賴性
在宣布網域不發送之前，請檢查網站表單、監控工具、電子商務設定、發票系統、身分提供者和支援平台。詢問他們是否使用該網域作為可見寄件者、信封寄件者地址或 DKIM 簽章域。
對於收購的網域，包括收購移交中的合約和應用程式所有者。 DNS快照記錄現在發布的內容；它不能證明不存在休眠應用程式或計劃於下個月發送的訊息。
使用 寄件者庫存 將每個發現的用途附加到指定帳戶和所有者。將未回覆的檢查保留為開放的調查結果，而不是將沉默轉化為認可。
驗證DNS更改實際上屬於何處
在發布之前確認權威伺服器和確切的完全限定所有者名稱。註冊商帳戶和DNS託管帳戶可以是不同的系統。子網域委派可以將名稱樹的特定部分移至另一個機構。
對於新的發送網域，請遵循平台為實際帳戶產生的配置。發布DKIM密鑰或委託記錄並不能證明服務已開始簽署； RFC 6376 §3.6.2.1 和 RFC 6376 §5 單獨的密鑰檢索和簽名。透過預期路由發送受控訊息並檢查受信任的接收驗證和 結盟.
在下面 RFC 9989 §4.5， DMARC策略以適用的_dmarc名稱發布。放置在網域根的值不會取代該擁有者名稱。 出版工作流程 將DNS驗證與訊息和報告證據連結。
為非發送域選擇正確的分支
一個真誠的 非發送網域 可以發布策略，表達所有者對未經授權使用其寄件者網域的處理偏好。限制性DMARC策略是一個範圍決策，仍然取決於接收器實施和分析。
SPF 和入境服務需要單獨決定。在下面 RFC 7208 §5.1 和 RFC 7208 §4.6.2，一個說明性的 v=spf1 -all 策略聲明該SPF策略沒有為所評估的網域授權任何來源。它本身並不描述每個可能的子網域或阻止入站郵件。
空MX聲明涉及接收。 RFC 7505 §3 將其定義為唯一 MX記錄，優先順序為零且目標為單點，對於不接受郵件的網域。中的指導 RFC 7505 §4.2 說域使用於 郵件來自 或可見的寄件者地址不應發布 null MX 。不要僅僅因為網域沒有普通收件匣就應用它。
使用 非發送網域指南 在組合這些控制項之前。它們表達的意圖不同，必須與實際使用一致。
研究虛構的新產品領域
假設一家公司註冊了一個產品域。其啟動清單將名稱標記為“僅限網站”，但三項檢查顯示了其他用途：
- Discovery：密碼重設服務將使用From中的產品域；結果：此名稱是發送域
- 發現：回覆應到達支援位址；結果：需要一條入站路由
- 發現：備份應用程式區域使用單獨的提供者帳戶；結果：該帳戶需要自己的配置和訊息證據
正確的下一步是修改目的暫存器，配置核准的路由並驗證它們。應用非發送記錄集將與計劃的服務相矛盾。
單獨的防禦名稱可能確實沒有批准的發送或接收用途。其所有者可以選擇用於不同目的的控制措施並記錄支援分類的檢查。
讓報告成為可行的操作路徑
如果請求匯總報告，請驗證目的地以及任何所需的外部目的地授權 RFC 9990 §4。決定誰將審查報告以及如何調查意外流量。報告地址並不僅僅因為它出現在TXT值中而有用。
新域可能產生很少的合法流量。在下面 RFC 9990 §3.1 和 RFC 9989 §5.3.8、空收件匣可能反映沒有觀察到郵件、收件者參與或收件問題。使用受控測試和收集檢查來區分這些可能性。
保持報告隱私和訪問與目的相稱。 報告隱私指南 解釋如何評估收集的數據。
在啟用新服務之前查看目的變更
初始配置不應成為團隊繞過的障礙。當網域取得員工郵件、交易使用或新的子網域時，需要進行用途更新以及相應的身份驗證和接收審核。
目前完整的DMARC參與需要多個傳遞訊息： RFC 9989 §8 包括協調一致的SPF和DKIM 、報告和政策發布。通用員工域也需要互通性評估 RFC 9989 §7.4 在選擇拒絕之前。
持久的結果是擁有者、目的和記錄一致的域名。當域的業務角色發生變化時，請查看該協議，而不是假設首日標籤永遠保持準確。
保持下一步行動具體
產品域固定裝置需要核准的傳送路徑和回覆路徑，因此在選擇非傳送控制項之前必須變更其僅網站標籤。備份帳戶仍然是一項獨特的驗證任務。 Null MX 、 SPF -all和DMARC處理首選項不是可互換的開關。這些是規劃結果，而不是實施記錄或實際採購評估。