[ DMARC和政策 ]

DMARC p=none:執行前可以進行哪些監控

監控有助於識別觀察到的寄件者、身分驗證漏洞和策略影響。它並不能證明完全覆蓋或使固定的等待期足以被拒絕。

由EmailAuth研究團隊提供 · 7 分鐘閱讀

[ 重點 ]

  • 監控視窗涵蓋觀察到的流量,而不是每個潛在的發送者。
  • 保留未知的歸屬,直到證據解決為止。
  • 選擇使用關鍵路由、間接郵件和復原準備的政策。
在此頁面上

在下面 RFC 9989 §4.7, a DMARC 的政策 p=none 表示域所有者對DMARC故障沒有處理偏好。配置和審查報告時,它創造了一個機會來了解哪些服務使用該網域、合法訊息在哪裡失敗以及策略變更可能會影響什麼。

透過調查,監控變得有用。報告需要到達收集系統,來源需要所有者,未解決的故障需要決策。經過的時間或一個高通過率並不能確定每項重要服務都已涵蓋。

使報告集合可觀察

對於開始受監控部署的網域,範例性策略是:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

該範例假設預期 _dmarc 出版品和有效的同域收藏地址。如果該域已經有更強大的批准策略,請不要僅僅為了匹配示例而削弱它。使用 記錄工作流程 來驗證實際配置。

下列的 RFC 9990 §4 獲得外部許可和 RFC 9989 §5.3.8 對於收件者報告,請檢查報告目標、任何所需的外部目標權限、郵件傳送和解析。保留報告者身分、期間和相關配置歷史記錄。收到來自一個提供者的報告表明了該觀察的工作路徑;它並不能證明全民覆蓋。

將服務分類並保留不確定性

對於每個有意義的來源模式,調查應用程式、客戶特定帳戶或路由、可見網域、信封身分、簽章身分和擁有者。

使用明確的工作類別:

  • 類別:已批准的服務,具有預期的一致路徑;下一步行動:保留所有權並監控變更
  • 類別:已批准的服務未通過身份驗證或 結盟;下一步操作:修正並測試支援的配置
  • 類別:合法間接路線;下一步行動:分析轉發、修改和接收者處理
  • 類別:來源不明;下一步行動:保留不確定性並進行調查
  • 類別:已確認未經授權的使用;下一步行動:記錄支持證據和回應

雲端提供者名稱、 ASN或國家/地區不足以批准寄件者。同樣,失敗的行不足以聲明每個關聯的訊息都是惡意的。

工作範例:安靜的窗口錯過了薪資單

考慮一個示例性組織,該組織審查十天的員工和行銷郵件。報告看起來很健康。在此期間,月薪服務尚未發送,其簽名配置尚未經過測試。

正確的結論是,觀察到的流在這十天內看起來很健康。這並不是說整個領域已經準備好接受更嚴格的政策。

該團隊可以直接調查和測試薪資路線,識別任何其他定期服務並擴展其證據。觀察視窗應反映實際的商業週期和相關的互通性考慮因素,而不是從儀表板中選擇的通用數字。

選擇適合域的策略

該決定比通過率目標更廣泛。需要關鍵服務覆蓋、負責任的所有者、評估的間接郵件群體、解決高影響力的故障和恢復過程。

RFC 9989 §7.4 明確警告不要 p=reject 用於通用電子郵件並討論使用者參與 Internet 郵件清單的網域。其互通性指南包括針對這些領域的具體觀察和比較步驟。不要用每個受監控域最終都應被拒絕的通用承諾來取代該指南。

嚴格控制的事務發送域和用於一般員工通訊的網域可以具有不同的操作約束。單獨的身份流服務於真正的治理目的,同時驗證產生的配置和實際訊息。

定義下一個決策的證據

執行審查應該用證據回答這些問題:

  • 重要的合法服務是否已被識別、擁有並經過測試?
  • 每個受影響的服務是否都有受支援的對齊路徑?
  • 是否考慮了週期性和小流量?
  • 郵件清單、轉送和其他間接路由是否被理解?
  • 是否描述了報告覆蓋範圍,而沒有將其視為所有已發送的電子郵件?
  • 例外情況是否已確定範圍、擁有併計劃進行審查?
  • 團隊能否批准、驗證提議的變更並從中恢復?

該決定可能是改進寄件者、改變網域分離、繼續監控或應用適合網域記錄使用的策略。將推理與變更記錄一起保存。

為調查結果分配所有者

詢問團隊希望了解什麼以及誰將根據研究結果採取行動。為企業提供哪些服務?哪些關鍵訊息失敗?哪些明顯的寄件者仍未識別?什麼證據將決定下一步?

包括 IT 團隊直接視圖以外的工作。每月薪資通知或年度續約通知可能很重要,但對整體訊息總數的貢獻卻很小。

避免自動倒數採取更強有力的政策。一周幾乎沒有明顯的故障可能意味著發送正常、報告不完整或服務尚未發送。為維護的庫存和已結束的調查結果付費,而不僅僅是為過去的天數付費。

政策變更後繼續監控

新軟體、供應商變更、密鑰輪換和DNS編輯可能會造成新的差距。在任何政策變更後繼續調查新的寄件者和合法失敗。

向企業領導者解釋剩餘風險:接收者保留自己的處理選擇 RFC 9989 §5.4,且網域身份驗證並不能阻止所有相似的訊息、帳戶外洩或詐欺請求。對於證據解釋,請使用 總結報告演練。對於原始通道失敗,請使用 對齊指南.

實用的外賣

監控的產出應該是擁有的發送者清單、經過驗證的關鍵路線和合理的政策決策。隨著環境的變化不斷監控,以便以後的應用程式、金鑰或網關變更不會悄悄地重新開啟相同的差距。

記錄決定及其限制

對於虛構的十天窗口,將每月薪資單保留為未經測試,而不是將其標記為健康。添加其所有者、下一個代表性工作流程以及縮小差距所需的證據。如果收集工作正常但應用程式從未發送,則對相同報告的更多分析無法建立其身份驗證。沒有為此插圖收集任何報告或工資測試。

[ 外帶 ]

監控視窗涵蓋觀察到的流量,而不是每個潛在的發送者。保留未知的歸屬,直到證據解決為止。選擇使用關鍵路由、間接郵件和復原準備的政策。

[ 按角色 ]

這對您意味著什麼

選擇您的角色以執行後續實際步驟。

IT/郵件管理員

使收集和分類過程可見。

驗證目標和攝取路徑,保留報告上下文並根據訊息和服務配置調查來源模式。明確未知的歸屬。

後續步驟

  1. 在需要時檢查外部目標權限。
  2. 直接測試定期服務而不是盲目等待。
  3. 保留支持每個寄件者分類的證據。

CISO / SecOps

選擇網域記錄使用的策略。

一般通訊域和嚴格控制的事務身分可以有不同的限制。在批准政策之前,請先檢視目前的互通性指南和關鍵流程證據。

後續步驟

  1. 評估郵件清單、轉寄和例外情況。
  2. 需要所有權、恢復條件和審查日期。
  3. 任何政策決定後繼續監測。

創辦人/非技術人員

將監控變成有名的工作。

觀察應確定您的企業所使用的服務以及需要注意的重要訊息。詢問團隊將學到什麼、誰會採取行動以及什麼證據將支持下一個決定。

後續步驟

  1. 在庫存中包括每月和季節性服務。
  2. 優先考慮嚴重故障而不是看起來健康的故障總數。
  3. 詢問已結束的調查結果,而不僅僅是過去的監測天數。

[ 常見問題解答 ]

常見問題

p=none是否會停用SPF或DKIM檢查?

不會。這些機制和DMARC評估仍然可以運作。該策略沒有表示網域擁有者對DMARC失敗的處理偏好;它不是跳過身份驗證的指令。

RFC 9989 §4.7

當網域使用p=none?

是的。接收者可以套用自己的過濾、信譽、收件人和其他策略。 None 不是保證交付設定。

RFC 9989 §5.4

監控策略是否會自動產生有用的報告?

不可以。報告請求、目的地許可(如果適用)、交付、解析和操作審查必須有效。接收者在報告參與方面也存在差異。

RFC 9989 §5.3.8 RFC 9990 §4

通過率高就足以離開監控嗎?

否。檢查基礎人口、重要服務、未解決的所有權和間接路線。高容量的健康流可以隱藏失敗的關鍵流。

觀察期應持續多久?

將其與網域的發送週期、相關標準指南和證據需求相符。請勿單獨使用經過時間作為承保範圍或安全性的證明。

每個網域最終都應該發布拒絕嗎?

沒有普遍的進展是適當的。 RFC 9989對通用域和郵件清單互通性發出警告。根據網域使用、合法流量和適用指南選擇策略。

RFC 9989 §7.4

一旦實施更強而有力的政策,監控是否應該停止?

不會。新服務、更改的路線和過時的權限可能會在以後帶來問題。維護收集、所有權和根據調查結果採取行動的流程。

監測的有用結果是什麼?

擁有的寄件者儲存、經過驗證的合法路線、解決了重大差距、了解了限制並記錄了政策決策,以及更改和恢復流程。

[ 來源 ]

來源

  1. RFC 9989

    部分 §4.7 · §5.3.8 · §5.4 · §7.4

  2. RFC 9990

    部分 §3.1 · §4

[ 詞彙表 ]

詞彙表

報告範圍
報告所代表的接收者和觀察期;總結報告並非對已發送郵件的完整普查。

RFC 9989 §5.3.8 RFC 9990 §3.1

來源不明
尚未歸因於已批准的服務或已確認的濫用的觀察結果;不確定性仍待調查。

企業出處

為什麼頂級金融機構和政府 退役了他們的電子郵件安全儀表板。

傳統的電子郵件驗證平台會向您出售儀表板並要求您的工程師來完成這項工作。在高風險環境中,手動監督意味著延遲執行、配置漂移和不受監控的影子域。

EmailAuth是代理電子郵件來源平台。 我們的代理人強制執行 p=reject,保持第三方寄件者一致並將您的網域移至完整狀態 RFC 9989 合規性、新的DMARC標準,以及人機互動審核能力。

政府 大型企業 一級金融機構

SaaS · 專用租賃 · 氣隙本地部署 · BYOK 加密

知識庫