將協議與接收者資格分開
BIMI 資格不是透過尋找單字來確定的 DMARC 在DNS記錄中。在顯示徽標之前，運營商必須確定適用的身份驗證策略、實際訊息是否通過所需的檢查以及預期接收者當前的要求。這些是相關但又不同的問題。目前的協議規範和提供者的操作幫助頁面在術語或遷移時間方面也可能有所不同，因此證據需要日期和明確的範圍。
本文比較了保留的主要來源。 Google 的設定頁面已於 10 月 26 日更新；檢索Yahoo的BIMI頁面時沒有相應的可見修訂日期。 RFC 9989 提供當前DMARC協定上下文。本文不會測試租戶或推斷提供者已實現新 RFC 的各個方面。 BIMI仍處於草案階段，接收器顯示並非通用協定保證。
記錄Google實際公佈的情況
Google 的BIMI設定頁面顯示訊息必須經過DMARC驗證並列出 p=quarantine 或者 p=reject，其中pct=100.它還需要一個 VMC 或者 CMC 其記錄的憑證支援的工作流程，並且不支援在Gmail中獨立的僅 SVG 部署。將這些聲明記錄為 Google 發布的資格指南，而不是作為DMARC的完整定義或特定郵件結果的證明。 谷歌設定要求
它的 SVG 要求和託管指令形成了額外的門。適當的DMARC策略不會使無效映像變得適當、取得憑證或使 PEM 可公開存取。相反，有效的憑證不會修復失敗的寄件者的一致身份驗證。使用包含單獨行的清單，這樣團隊就不會在僅完成 DNS 策略行後意外地將整個專案標記為就緒。
公開而不是隱藏 PCT 差異
RFC 9989廢棄了早期的DMARC規範並刪除了 pct 標籤。其附錄解釋了歷史百分比機制，並介紹了帶有 y 和 n 值的測試標籤 t。這是一個有意義的協議更改，而保留的 Google BIMI頁面仍然明確提及pct=100.這兩個觀察結果都應該保留，而不是默默地重寫任一來源以使它們看起來相同。 RFC 9989 ，附錄 A.6
操作響應是在根據不匹配情況更改生產策略之前確認當前接收器的適用性。請勿聲稱 Google 忽略、線上要求或內部翻譯特定標籤，除非當前證據證實該行為。不要因為 RFC 解釋了它們的歷史關係，就將 t 視為 PCT 的普遍證明的BIMI資格替代品。提供者實施和提供者文件可以按照不同的時間表發展。
因此，來源適用性記錄應包括 RFC 版本、提供者頁面日期、確切的爭議條件和未解決的問題。要求負責的審核員使用目前的提供者證據或授權的、適當範圍的觀察來解決該問題。本文不進行該確認。衝突是設立大門的原因，而不是削弱執法或即興提出相容性聲明的原因。
獨立比較Yahoo規定的條件
Yahoo自己的BIMI頁面需要隔離或拒絕DMARC政策， BIMI記錄 指向有效的 SVG、大量郵件以及發送地址的足夠聲譽和參與度。它表示目前不需要 VMC，但提供的VMC會告知整體資格。它的頁面尊重子域BIMI記錄，同時更喜歡組織域設定。這些是 Yahoo 特有的聲明，並非Gmail共享相同證書或顯示政策的證據。 Yahoo BIMI要求
不要將該頁面上缺少 pct 條件的Yahoo解釋為每種可能的標記處理行為的證據。記錄來源實際陳述的內容以及未指定的內容。同樣，其大量郵件和聲譽條件意味著單一個人測試訊息可能無法代表記錄的徽標顯示群體。當審查的來源未提供數字發送閾值時，請勿發明數字發送閾值。
將政策連接到實際的訊息身份驗證
DMARC評估 結盟 可見的 From 域和傳遞的域之間 SPF 或者 DKIM 其規則下的身份。已發布的強制執行偏好並不強制每個合法寄件者通過。在提出更嚴格的處理之前，清點發送服務並確定它們驗證的身份。策略的變更可能會影響合法的工作流程，因此徽標截止日期不得繞過郵件團隊的準備和批准流程。 RFC 9989身份驗證和對齊
為了後續的受控觀察，保留實際收到的訊息和可信的身份驗證結果。在未識別生產系統和信任邊界的情況下，不要接受任意標頭的聲明通行證。將策略發現、訊息認證和標誌顯示作為單獨的結果；訊息無需滿足接收者的附加顯示條件即可通過認證。 RFC 8601信任邊界
原始接收者資格工作表
每個接收者和郵件流建立一行。以下建議欄位可防止通用的「 BIMI就緒」狀態隱藏重要差異。此工作表尚未評估任何實際部署。
- 來源：接收者頁面、檢索日期、可見修訂日期和協定參考版本。
- 域政策：確切適用的記錄以及任何組織或子域問題。
- 文件不符：有爭議的標籤或條件、證據和未解決的適用性所有者。
- 訊息證據：可見的寄件者、經過驗證的身份、一致性和可信結果來源。
- 資產：核准的 SVG 版本、接收器尺寸和結構發現。
- 證書：所需類別、頒發者狀態和託管 PEM 依賴性。
- 檢索與顯示：公共端點證據、接收者客戶端、觀察時間與限制。
- 決定：符合此流條件、不符合條件或未知，還有剩餘條件。
將監控和執行決策與顯示實驗分開。如果現有發送器無法對齊，請解決發送器配置和業務影響，而不是重複更改徽標檔案。如果身份驗證通過但沒有出現徽標，請調查證書、託管、支援和酌情資格，而不要僅因缺少圖形而聲明DMARC已損壞。
虛構範例：一張清單隱藏了兩位接收者
虛構的 Silver Orchard 準備了一份啟動清單，上面寫著「 DMARC pass，證書可選」。該措辭將Yahoo的證書位置與Gmail不同的記錄工作流程合併在一起。審查者還注意到，較舊的內部指南將 pct 視為未更改的通用協議要求，而RFC 9989刪除了它，並且 Google 的當前頁面仍然列出了pct=100.團隊有兩個文件問題，但沒有證據顯示任一接收器出現故障。
建議的下一步是將清單拆分為來源日期接收者行，並在更改生產DNS之前升級標籤適用性問題。每個流都需要實際的訊息證據及其自己的資產和證書檢查。未測試 Silver Orchard 訊息、 DNS記錄或接收器。此範例說明了通用清單如何隱藏未解決的假設。
該目錄需要特定接收者的資格矩陣以及DNS 、徽標、證書和訊息身份驗證的證據。本手稿提供了擬議的矩陣和記錄的差異，而不是操作證據。原始證據、人類 SME、來源適用性、生產路線、視覺可及性和所有者發布都保持開放。不暗示任何政策變更、現場測試或資格保證。