[ 標準和DMARCbis ]

為域組合建構DMARCbis驗收測試包

設計版本化的DMARC驗收包,將策略發現、調整、報告和特定於產品組合的發布決策分開。

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

[ 重點 ]

  • 目前DMARC仍然使用v=DMARC1.
  • 預期結果需要版本化的裝置和觀察到的證據。
  • 投資組合準備必須保留例外情況和特定路線的範圍。
在此頁面上

定義接受意味著什麼

網域組合可以包含員工郵件、交易應用程式、行銷服務、非活動名稱和委託子網域。公司域旁的綠色勾號並不能確定這些不同的路由是否正常運作。驗收包應在列出測試之前定義正在評估的網域、身分、實作和路線。其目的是支援有限制的發布決策,而不是製造通用合規徽章。

目前的核心 DMARC 規格是 RFC 9989,總報告為 RFC 9990 和故障報告 RFC 9991。遷移審查必須區分這些功能。協定記錄仍使用v=DMARC1;規格中的變更不會建立名為 DMARC2 的DNS值。將規範版本和線上記錄值保留為套件中的單獨欄位。 RFC 9989 ,第 4.7 節及附錄 C

按行為而非所有權劃分投資組合

建立其成員共享有意義的操作屬性的群組:員工郵件路由、特定供應商整合、委派子網域模型或非發送策略範圍。保留例外,而不是強制每個網域都進入同一模板。同一企業擁有的兩個網域可以使用不同的供應商和策略發現路徑,而多個品牌可以共用一個基礎路徑。

對於每個群組,記錄企業擁有者、 DNS擁有者、發送應用程式、相關寄件者和身分驗證網域以及正在審查的實施情況。將實際生產庫存與建議的範例清單分開。域在資產暫存器中的存在並不能證明已找到其所有發送流。未知的路線應該作為間隙保持可見,而不是默默地被視為已接受。

決定包可以建立什麼。離線解析器裝置可以示範指定實作下的指定輸入處理,但它們不能證明即時DNS可用性或接收訊息行為。 DNS快照可以支援一次性原則發現,但它並不能顯示每個接收者的部署。在整個發布決策過程中保持這些證據等級的明確。

建構獨特的協議測試系列

策略測試應涵蓋有效和無效的版本放置和值、支援的標籤、策略發現和相關的DNS樹遍歷行為。 結盟 測試應區分原始 SPF 或者 DKIM 成功源自於與 RFC5322 .來自 領域。包括一種對齊機制通過而另一種機制失敗的情況,因此包不會意外地要求兩者都通過才能獲得DMARC成功。

報告測試屬於不同的家族。聚合報告有自己的發現、外部目標驗證和 XML 結構。失敗報告具有不同的格式和隱私表面。成功的策略解析並不能證明報告交付或安全報告處理有效。該包應將每個預期結果連結到提供它的精確部分,同時單獨標記特定於實現的行為。 RFC 9989 ,第 4.4、4.7 和 4.10 節; RFC 9990 ,第 3、4 節及附錄 A; RFC 9991 ,第 4 節和第 5 節

一起版本固定裝置和觀察結果

每個燈具都需要一個標識符、內容雜湊、目的、來源要求、輸入假設和預期結果。每次執行都需要執行名稱和版本、配置、執行時間、觀察結果、日誌和審核者。如果燈具發生變化,請保留新版本,而不是默默地替換同一識別碼下的舊輸入。否則,明顯的改進可能是由更簡單的測試而不是糾正的行為引起的。

在解釋觀察到的運行之前必須寫下預期結果。當結果不同時,對是否期望錯誤、實現不同、夾具無效或環境阻止有意義的測試進行分類。跳過或阻止的測試不算通過。在不解釋相關酌處權的情況下,當地政策接受的結果不應重新標記為符合標準。

將秘密和不必要的訊息內容排除在固定裝置之外。使用有限的、授權的合成輸入進行實驗室工作,並使用單獨批准的生產路線證據。本文不提供已執行的固定套件或傳送測試訊息、變更記錄或存取提供者帳戶的授權。

作品集驗收工作表

工作表應將投資組合組與固定裝置識別碼、預期結果、觀察到的結果、未解決的差異和發布決策連結起來。包括一個覆蓋列,顯示哪些域或路由被代表以及為什麼該分組是合理的。代表性案例可以支持記錄在案的推論,但它不能默默地成為不相關的實施或供應商的證據。

添加單獨的門欄,用於原始證據、人工審查、來源適用性、生產路線、視覺可及性和所有者發布。即使離線解析器測試通過,這些閘門也可以保持開啟。記錄誰可以關閉每個項目以及需要什麼工件。發布所有者應該看到簡潔的例外列表,而不是隱藏不支援範圍的百分比。

該包還應包含回滾和重新評估觸發器。提供者變更、 DNS委託變更、新的發送路由或規範澄清可能會使先前的接受假設失效。保留需要重新評估的活動和受影響的燈具系列,以便下一次審查從已知的基線開始,而不是從分散的門票中重建意圖。

虛構的投資組合決策

想像一個虛構的投資組合,其中包含員工郵件、收據服務和非活動品牌網域。提議的包將對齊案例分配給兩個發送路由,並將策略發現案例分配給所有三個群組。假設的實驗室實作可以正確處理有效版本值,但在一個發現裝置上有所不同。實際上沒有執行;這些是說明釋放決定的發明條件。

正確的反應不是將整個投資組合標記為就緒,因為大多數情況似乎都是可以接受的。審核者將保留發現差異,確定哪些群體依賴它,並在發布該範圍之前要求實施證據。即使實驗室對齊邏輯正確,收貨服務仍需要自己的授權路線證據。

提議的結果可以接受有限的離線行為,同時保持生產準備。這種區別是有用的而不是令人尷尬的:它準確地告訴所有者證據支持什麼。此範例並未聲明指定接收者已採用RFC 9989或真實域已通過測試。

原始證據仍然存在

該目錄需要一個版本化的夾具集和預期與觀察到的結果,而不僅僅是一個清單。該手稿描述如何建構該包,但沒有提供固定裝置執行、即時查詢或觀察到的結果。因此,最初的證據要求仍然開放,所有六個釋放門也是如此。

在發布操作之前,合格的審查者應驗證每個預期結果都有當前的權威依據,並且每個觀察結果都屬於規定的實施版本。不要將來源引用視為執行日誌的替代品。最終驗收聲明應列出所涵蓋的投資組合範圍、其例外情況以及未解決的操作依賴性。

[ 外帶 ]

僅發布由版本化的預期與觀察到的驗收記錄支援的組合範圍。

[ 按角色 ]

這對您意味著什麼

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

投資組合所有者

定義覆蓋範圍

共享所有權並不意味著相同的技術行為。

後續步驟

  1. 識別路由組和例外情況。
  2. 分配發布責任。

測試工程師

保持再現性

期望不是觀察到的傳遞。

後續步驟

  1. 版本固定裝置和實施。
  2. 保留差異並阻止運行。

獨立評審員

綁定接受

線下證據無法單獨關閉即時操作的大門。

後續步驟

  1. 檢查來源到案例的連結。
  2. 檢查覆蓋範圍並開啟相依性。

[ 常見問題解答 ]

常見問題

DMARCbis是否需要v=DMARC2?

不會。 RFC RFC 9989保留確切的版本值DMARC1 。

RFC 9989: DMARC

一個域可以代表每條路由嗎?

僅有明確合理的覆蓋範圍論證;不相關的路線需要單獨的證據。

SPF和DKIM必須都通過嗎?

DMARC可以透過對齊的傳遞機制進行傳遞。

RFC 9989: DMARC

解析器測試是否證明報告已交付?

不會。總結報告和故障報告有單獨的要求和證據。

RFC 9990 : DMARC聚合報告

跳過的比賽可以算通過嗎?

不。明確保留阻止或跳過的結果。

什麼標識了可重複運行?

夾具版本和雜湊、實作版本、配置、預期結果和保留的觀察結果。

該驗收包是否已執行?

不。這是一個帶有虛構投資組合範例的建議設計。

還需要什麼原始證據?

版本化的賽程和預期與觀察到的結果仍然開放。

[ 來源 ]

來源

  1. RFC 9989: DMARC

    部分 §2.4 超出範圍 · §4.4 標識符對齊說明 · §4.7 DMARC策略記錄格式 · §4.10 DNS樹遍歷 · §5 DMARC參與 · §6 DMARC反饋 · 附錄 A.6 刪除「pct」標籤 · 附錄 C 對RFC 7489的更改

  2. RFC 9990 : DMARC聚合報告

    部分 §3.1 總結報告 · §3.3 報告期間的策略變更 · §3.4 報告請求發現 · §3.5 報告傳送 · §4 驗證外部目標 · §5 可擴展報告 · §8.1 將內容報告為攻擊 · §8.2 虛假資訊 · §9 操作注意事項 附錄 § 3 DMARC

  3. RFC 9991 : DMARC故障報告

    部分 §2 DMARC故障報告 · §4 報告格式更新 · §5 驗證外部目標 · §7 隱私權注意事項 · §1 簡介

[ 詞彙表 ]

詞彙表

受理範圍
發布決策涵蓋的確切投資組合群組和行為。
夾具版本
具有雜湊值和記錄的預期結果的穩定的已識別輸入。
對準案例
將成功的身份驗證身分與寄件者域相關聯的測試場景。

RFC 9989: DMARC

觀察結果
來自命名實現和配置的保留結果,與期望不同。

企業出處

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

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

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

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

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

知識庫