[ BIMI及品牌 ]

Apple Branded Mail 和BIMI是不同的路線

在選擇徽標顯示項目之前,將 Apple 的業務驗證路線與 Apple Mail 中BIMI背後的接收提供者檢查進行比較。

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

[ 重點 ]

  • Apple Business Branded Mail 註冊和BIMI DNS聲明是不同的管理路徑。
  • Apple Mail 的BIMI顯示取決於接收提供者的參與、檢查和標頭。
  • Gmail憑證或複選標記規則無法轉移給 Apple 或每個用戶端。
在此頁面上

Apple Mail 中電子郵件旁邊的標誌不會告訴專案團隊是哪個身分識別系統提供的。 Apple 品牌郵件和 BIMI Apple Mail 中的支援是具有不同權限和依賴性的不同路由。因此,在任何人訂購證書或更改DNS之前,「開啟 Apple 徽標」的請求應成為有關品牌、發送身分、目標郵箱和用戶端介面的記錄選擇。

Apple 目前的品牌郵件單頁指南描述了向 Apple Business 註冊的企業,或將管理委託給第三方,以及在郵件中添加名稱和徽標的企業。早期材料使用 Apple Business Connect 名稱。該指南將 Mail 和 iCloud Mail 識別為顯示表面,並表示蘋果會檢查DNS記錄 DMARC。這是 Apple 的業務驗證途徑,而不是BIMI斷言已發布的證據。 Apple 品牌郵件概述.

將兩條權力鏈分開

對於品牌郵件,請確定企業帳戶所有者、授權代表品牌的一方以及控制註冊電子郵件範圍的管理員。保留實際帳戶狀態和批准訊息(如果有)。行銷機構可以在未經授權管理組織身份的情況下準備藝術品。同樣,對DNS區域的控制並不建立徽標的所有權。

對於BIMI ,網域所有者發布聲明並提供所需的徽標和證據。接收提供者應用其身份驗證、證據和顯示策略。發送者僅僅透過新增一個並不能獲得通用顯示權限 TXT記錄。 BIMI集團明確表示,參與的郵箱提供者設定了自己的顯示標準。 BIMI實施指南.

Apple Mail 新增了接收方相依性。 Apple 記錄了 macOS Ventura 13、iOS 16 和 iPadOS 16 或更高版本上的BIMI支援。其提供者條件包括蘋果驗證、檢查訊息和網域合規性、驗證證據文件以及添加所需的標頭。未執行這些操作的提供者不會產生記錄的 Apple Mail BIMI顯示路徑。 Apple 的BIMI伺服器指南.

使用具有明確未知數的路線圖

本文所附的比較將管理權限、域證據、識別證據、接收依賴性和觀察結果分開。這是一份文件路線圖,而不是帳戶審計。對於「品牌郵件」列,未解決的欄位是組織批准的企業身分、允許的寄件者範圍以及適用的目前 Apple 審核要求。對於BIMI列,它們是已發布的斷言、已接受的證據、已驗證的訊息和接收提供者的參與。

不要使用提供者行銷頁面的螢幕截圖來填充觀察結果行。該圖像演示了升級的介面,而不是該組織的配置。受控測試的螢幕截圖必須識別實際的郵箱提供者、用戶端、作業系統版本、日期和發送身分。相同的客戶端應用程式可以顯示來自不同提供者的郵件,因此「在 Apple Mail 中測試」並不是完整的證據。

來源限制仍然存在:無法完全檢索目前的介紹品牌郵件指南。單獨的 Apple 概述、可用的驗證摘錄和BIMI開發人員指南支援此處的有限比較,但並未建立每個目前的控制台設定或區域顯示條件。實施前請確認授權帳戶中的這些詳細資訊。

協調身份驗證而不合併程序

DMARC檢查 結盟 作者網域和經過身份驗證的網域之間 SPF 或者 DKIM 標識符。該協議結果不同於業務驗證和品牌資產的接受。 DMARC通行證並非商業身分的證書,經核准的業務設定檔不能取代訊息驗證。 RFC 9989 ,第 4.3–4.4 節.

Apple 可用的網域驗證指南列出了隔離或拒絕,以及在其所述情況下的父子網域策略替代方案,並且仍然提到 pct=100。將其視為 Apple 記錄的兼容性語言,而不是現代DMARC的定義。 RFC 9989 刪除了 百分比 標籤。讓郵件管理員解決適用的收件者要求,而不將百分比標籤視為可靠的分階段執行控制。 Apple 網域驗證指南; RFC 9989 ,附錄 A.6.

在外觀發布日期之前保留寄件者庫存和身份驗證修復。如果合法的交易郵件尚未準備好執行,品牌團隊不應僅僅為了滿足徽標項目而強制更改網域範圍內的策略。

請勿在接收者之間轉讓證書或徽章承諾

Gmail目前的設定指南接受 驗證標誌證書 或者 通用標誌證書 其BIMI路由並描述了其對 VMC 驗證的寄件者的複選標記。這些是Gmail聲明。他們沒有確定相同的CMC會產生 Apple Mail 顯示,Apple Branded Mail 需要相同的證書,或者Gmail徽章會出現在另一個應用程式的介面中。 Google 的BIMI設定指南.

Apple 的BIMI頁面討論了接收提供者信任的 VMC 和其他證據文件。記錄特定提供者接受的證據,而不是將該語言轉換為全面的CMC支援。對於 Apple Branded Mail,請取得該單獨業務工作流程的要求,而不是僅僅因為兩條路線都可以顯示徽標而購買標記證書。

測試定義的路線並儲存結果

考慮一個虛構的品牌 offers@example.com。建議的計劃為同一寄件者提供一個品牌郵件註冊行和一個單獨的BIMI行。兩行均未標示為完整。團隊將驗證第一個的帳戶和網域狀態,然後驗證第二個的DNS 、資產、憑證適用性和可信任接收者身分驗證。它將記錄針對相關提供者和客戶的每個實際顯示觀察結果。

本文未測試任何帳戶、 DNS記錄、憑證或顯示。其確切的目錄證據要求仍然開放:「使用蘋果擁有的來源和支持的顯示觀察結果製作並排的路線圖。」提供文獻地圖;支持的原始顯示觀察結果和經常帳戶適用性仍然缺失。不保證徽標、複選標記、收件匣放置或發布日期。

[ 外帶 ]

確定哪條路線提供了證據,並測試指定的郵箱提供者和用戶端組合,而不是承諾使用 Apple 範圍內的徽標。

[ 按角色 ]

這對您意味著什麼

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

品牌擁有者

選擇預期的身份路由

相同的標誌可能會透過具有不同審批鏈的不同程序出現。

後續步驟

  1. 確定經批准的品牌和授權的 Apple 客戶經理。
  2. 對任何BIMI證書和DNS項目保留單獨的決定。

電子郵件管理員

保持認證證據的獨立性

註冊的企業身份並未證明特定訊息通過了一致的身份驗證。

後續步驟

  1. 保留實際的發送者身分和可信任接收者結果。
  2. 解決目前的接收器要求,而無需強制進行不安全的網域範圍變更。

支援分析師

識別接收上下文

Apple Mail 是一個可以連接到不同郵件提供商的用戶端介面。

後續步驟

  1. 記錄每次觀察的提供者、作業系統、客戶端版本和日期。
  2. 如果沒有路線證據,請勿將標誌或徽章歸因於BIMI 。

[ 常見問題解答 ]

常見問題

註冊 Apple Branded Mail 是否會發布BIMI記錄?

請勿將註冊視為BIMI主張的證據。 Apple業務驗證路由和基於DNS的BIMI路由需要單獨配置和取證。

為什麼本文要同時使用 Apple Business 和 Business Connect?

早期材料名為 Business Connect。目前 Apple 擁有的品牌郵件概述使用 Apple Business。驗證目前授權帳戶工作流程,而不是依賴舊的選單名稱。

Apple Mail 可以顯示與其連接的每個郵件帳號的BIMI嗎?

不支持這種一攬子主張。 Apple 要求接收郵件提供者滿足其參與、驗證和標頭要求。郵箱提供者是測試上下文的一部分。

Apple 的BIMI指南是否建立了普遍的CMC接受度?

不。它討論了接收提供者信任的 VMC 和其他證據文件。確認特定提供者接受的證據,而不是假設所有 CMC 都合格。

Apple Mail 中會出現Gmail VMC複選標記嗎?

Google 的聲明涉及Gmail的 VMC 驗證寄件者。它不會在另一個應用程式或程式中建立相同的徽章。

行銷機構可以透過控制DNS來批准品牌嗎?

僅DNS控制並不能建立品牌權利或管理 Apple 企業識別的權限。分別記錄品牌方的授權和帳戶委託。

我應該如何處理仍然提到pct=100?

將其保留為提供者相容性語言。 RFC 9989刪除了 pct;讓電子郵件管理員協調適用的要求,而不是使用百分比設定作為強制實施承諾。

並排路線圖還缺什麼?

原始支援顯示觀察結果和實際組織的帳戶、網域和證據狀態。所提供的地圖是記錄性的,目前的蘋果控制台適用性尚未得到驗證。

[ 來源 ]

來源

  1. Apple:準備您的電子郵件伺服器以支援 Apple Mail 中的BIMI
  2. Apple 品牌郵件概述
  3. Apple:驗證您的品牌郵件電子郵件網域
  4. BIMI Internet-Draft 15(2026 年 10 月 31 日;正在進行中)
  5. Google Workspace :設定BIMI
  6. BIMI集團實施指南
  7. RFC 9989 :基於網域的訊息驗證、報告和一致性

[ 詞彙表 ]

詞彙表

Apple 品牌郵件
Apple 的業務工具路線,用於將註冊的企業品牌名稱和徽標與電子郵件相關聯。
Apple 郵件BIMI路徑
客戶端顯示路徑取決於接收提供者執行 Apple 記錄的BIMI檢查並提供所需的標頭。
業務驗證
對業務身分進行特定於程序的評估,與訊息的網域身份驗證結果分開。
BIMI證據文件
接收提供者根據該提供者的信任要求評估指標與域的關係的證據。
顯示觀察
指定接收服務和用戶端針對特定受控訊息顯示的內容的日期記錄。

企業出處

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

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

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

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

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

知識庫