編輯DNS之前驗證依賴關係
發布一個 BIMI 斷言是一個小的DNS更改，具有多個外部依賴項。該記錄可能引用另一個團隊託管的徽標或證據文檔，並且接收提供者可能會拒絕其他可讀文件，因為其證書或身份驗證條件不符合。從核准的網域、接收者特定的計畫和確切的資產版本開始，而不是通用的TXT字串。
本指南涵蓋了記錄的預設選擇器工作流程。保留的BIMI版本 15 文件描述了其他選擇器和發現規則，但它仍然是互聯網草案，而不是 RFC。不介紹先進的 選擇器 行為只是因為發送平台可以插入標頭；首先確認預期的發送者和接收者實現。 BIMI Internet-Draft 15，第 4.3–4.4 節.
建立正確的擁有者和斷言值
對於簡單的預設情況 example.com，斷言所有者是 default._bimi.example.com。版本標籤是 v=BIMI1;指示器位置使用 l=，並且權威證據位置使用 a=。該草案將證據位置定義為可選語法，但這並不意味著證據對於每個接收者都是可選的。 BIMI Internet-Draft 15，第 4.3 節.
一個虛構的雙位置插圖是 v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem。這不是生產記錄、託管資產或證書推薦。不要用這些範例值取代真實的斷言或真實的憑證 URL。
Google 記錄了Gmail的基於 PEM 的設置，包括一個空的範例 l= 值和憑證位置 a=。僅 SVG 記錄不是相同的實作路徑。選擇目標接收者支援的形式和提供的證據，而不是將每個已發布的範例視為可互換的。 Google BIMI設置，步驟 2-4.
檢查適用的身份驗證策略
使用目前的確認作者域和適用的組織域策略 DMARC 發現規則。然後檢查來自預期路由的實際訊息以進行一致的身份驗證。 BIMI集團呼籲強制執行，並指出對自我斷言記錄的支援有限，但政策文字和記錄建構結果都不能證明發送者已準備好。 BIMI實施指南; RFC 9989 ，第 4.4 和 4.10 節.
必須結合其版本上下文來閱讀提供者文件。目前的Google頁面仍然包括 pct=100， 然而 RFC 9989 刪除了那個標籤。將此差異保留為郵件管理員的相容性問題。請勿使用百分比設定或測試模式作為聲稱的BIMI資格捷徑，並且在調試不相關的資產問題時不要削弱現有的執行力度。 RFC 9989 ，附錄 A.6.
驗證斷言將通告的資源
託管擁有者應提供準確的公共 HTTPS URL、預期位元組及其雜湊值。建議的提取應確認回應是預期的資產或憑證包，而不是登入頁面、品牌錯誤頁面或重定向到不相關的資源。記錄狀態、最終 URL、內容類型、大小和TLS結果。這些觀察結果必須來自實際的生產路徑，而不僅僅是本地文件預覽。
對於標記憑證路徑，根據目標提供者的要求驗證已頒發的證據和鏈。 Google 的說明描述了其 PEM 捆綁包和發行人提供的鍊式訂單。 HTTPS伺服器憑證保護檢索；它不是 VMC 或者 CMC 這提供了標記證據。獨立檢查這兩種關係。 Google BIMI設定、網路伺服器需求與步驟 2-3.
此處未取得代表真實部署的公開 URL。如果團隊無法提供已批准的資產或證書，請保留該依賴關係未解決，而不是建立可能被誤認為有效證據的佔位符。
透過正確的DNS權威機構發布
確定確切所有者的權威DNS服務，並在進行更改之前檢查現有記錄。確認編輯器是否需要相對主機標籤或完全限定名稱。保留先前的值和 TTL，並使用經過審查的變更請求，其中指定了預期所有者、類型和值。避免在同一發現名稱上出現重複的競爭斷言。
授權發布後，建議的檢查包括 挖掘@AUTH_IP default._bimi.example.com 。 TXT +norecurse 和 挖@RESOLVER_IP default._bimi.example.com 。 TXT。大寫端點是佔位符。保存時間戳記、完整回應、記錄邊界和實際值。這些命令是建議的，而不是執行的觀察。
在將分歧解釋為快取之前檢查權威一致性。然後比較與可用觀察結果的預期接收器相關的遞歸路徑。 DNS TTL 或提供者的估計顯示視窗並不能保證每個接收器都已刷新或將顯示徽標。
驗證訊息並計劃恢復
僅在其先決條件準備就緒後，才能透過確切批准的工作流程發送受控訊息。保留作者網域、簽名身分、可信任身分驗證結果和任何相關的BIMI診斷。分別記錄顯示觀察結果以及郵箱提供者、用戶端版本和日期。例如，Apple Mail 的BIMI路徑取決於提供 Apple 指定的支票和標頭的接收提供者。 Apple BIMI伺服器指南.
如果檢索失敗，請修正託管依賴項或復原變更計畫下已核准的先前斷言。如果身分驗證失敗，請調查寄件者和策略。如果僅缺少顯示，則在不檢查接收方行的情況下不要推斷DNS錯誤。維護安全、授權回滾所需的舊證據；不要廣泛減少DMARC保護來恢復標誌。
確切的證據門是「特定於接收者的資格矩陣和DNS 、徽標、證書和訊息身份驗證的證據」。本草案提供了文獻矩陣和虛構記錄插圖。沒有發生即時發布、 DNS查詢、證書驗證、租戶變更或訊息/顯示測試，因此操作門和擁有者發布批准仍然開放。