BIMI: як працює Brand Indicators for Message Identification

BIMI розшифровується як Brand Indicators for Message Identification. Це стандарт автентифікації електронної пошти, який дозволяє відправнику публікувати логотип бренду для оцінки підтримуваними поштовими провайдерами та — там, де це дозволяє їхня власна політика — відображення поряд із повідомленнями відправника.

BIMI — це не функція завантаження зображень. Він побудований поверх автентифікованої електронної пошти, DNS, обмеженого формату SVG та політики одержувача. Коректний BIMI-запис не зобов’язує поштову скриньку показувати логотип. Поштові провайдери самостійно приймають рішення для кожного домену.[1]

Практичний шлях складається з чотирьох частин:

1. автентифікувати домен відправника та забезпечити примусове застосування DMARC;
2. підготувати валідний логотип у форматі SVG Tiny Portable/Secure;
3. опублікувати BIMI assertion record і, якщо потрібно, файл сертифіката; та
4. протестувати розгорнутий домен, не припускаючи, що одна лише публікація запису є достатньою.

Запустити аудит BIMI-домену або валідувати логотип перед внесенням змін до DNS.

Що робить BIMI

BIMI assertion record вказує на розташування файлу логотипу та, якщо це застосовно, файлу сертифіката. Підтримуючий одержувач може отримати ці ресурси, оцінити їх разом із автентифікацією відправника та вирішити, чи відображати індикатор.

Результатом є впізнаваний ідентифікатор відправника у вхідних повідомленнях одержувача. Однак основна мета полягає в посиленні автентифікації відправника. BIMI залежить від DMARC; він не замінює DMARC, SPF або DKIM.

Що BIMI не робить

BIMI не гарантує доставку до вхідних, репутацію відправника чи відображення логотипу. Технічно валідний запис може так і не відобразитися, якщо провайдер-одержувач застосовує іншу політику, якщо ресурс неможливо отримати або валідувати, або якщо повідомлення не відповідає умовам автентифікації одержувача. Тому BIMI слід впроваджувати як частину ширшої програми автентифікованої електронної пошти, а не як косметичне скорочення шляху.[1]

Шлях впровадження

1. Забезпечити примусове застосування DMARC

Відповідно до задокументованого Google процесу роботи з BIMI, DMARC має бути налаштований із політикою p=quarantine або p=reject і pct=100; p=none не відповідає вимогам.[2] SPF або DKIM також мають автентифікувати пошту в спосіб, що задовольняє вирівнювання DMARC.

Якщо домен перебуває ще в режимі моніторингу, розпочніть із керованої програми DMARC. DMARCSwiss — це портфельний сервіс для безперервного моніторингу зведених звітів та поступального переходу до примусової політики. Ця сторінка не розглядає p=none як стан готовності до BIMI.

Ознайомтеся з детальним посібником з вимог DMARC.

2. Підготувати логотип у форматі SVG Tiny P/S

BIMI використовує обмежений профіль SVG, призначений для безпечного відображення в середовищі з підвищеними вимогами до безпеки. Експорт зі стандартних інструментів дизайну часто містить непідтримувані елементи, зовнішні посилання, скрипти, анімації або геометрію, яка потребує нормалізації.

Опублікований Google посібник містить вимоги до SVG Tiny P/S та специфічні умови для Gmail, зокрема абсолютні розміри в пікселях і рекомендації щодо квадратного представлення, суцільного фону, розміру файлу та елемента desc.[2]

makeBIMI конвертує та валідує SVG-активи відповідно до відповідних технічних обмежень. Результат є технічною валідацією, а не гарантією того, що центр сертифікації або поштовий провайдер прийме фінальне розгортання.

Конвертувати або валідувати логотип · Прочитати посібник із SVG Tiny P/S · Прочитати технічний стандарт

3. Опублікувати BIMI-запис

Стандартний BIMI assertion record публікується за адресою:

default._bimi.example.com

Показовий запис виглядає так:

v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/certificate.pem

Тег v= оголошує версію BIMI. Тег l= вказує на розміщений SVG-файл. Тег a= вказує на файл сертифіката, якщо реалізація одержувача цього вимагає.

Ресурси повинні бути публічно доступні через HTTPS і залишатися стабільними після публікації. У посібнику Google пояснюється конструкція файлу сертифіката та зазначається, що сертифікат суб’єкта, проміжні сертифікати і кореневий сертифікат зазвичай додаються в такому порядку при використанні PEM-файлу.[2]

Ознайомтеся з посібником із DNS-записів BIMI перед публікацією реального запису.

4. Визначити, чи потрібен сертифікат

Вимоги одержувачів різняться. Google документує VMC або CMC для налаштування BIMI та зазначає, що підтверджений значок у Gmail пов’язаний із VMC.[2] VMC базується на логотипі, що є торговою маркою, та проходить суворий процес верифікації. CMC може бути доступний для прийнятних випадків використання без торгової марки — відповідно до поточних вимог центру сертифікації та одержувача.

Затверджене формулювання щодо активних емітентів VMC для портфельного контенту таке: DigiCert та Entrust є активними емітентами VMC. Не покладайтеся на застарілі списки емітентів і не припускайте, що будь-який тип сертифіката дає однаковий результат у одержувача.

Прочитати посібник із VMC та CMC · Порівняти VMC та CMC · Зв’язатися з veriBIMI

Значення політики одержувача

Стандарт BIMI надає одержувачам уніфікований спосіб отримання та оцінки інформації про логотип. Він не усуває дискреційні повноваження одержувача. BIMI Group прямо зазначає, що поштовий провайдер не зобов’язаний відображати логотип для домену, який застосовує BIMI, і може приймати локальні рішення для окремих доменів.[1]

З цієї причини makeBIMI підтримуватиме датовану BIMI Receiver Requirements Matrix. Вона відокремлюватиме задокументовані вимоги провайдерів від загальних правил стандартів і позначатиме непевну або незадокументовану поведінку як таку. Вона не робитиме висновків про підтримку на основі скриншотів, тверджень третіх сторін або застарілих публікацій у блогах.

Поширені причини відсутності логотипу

Типові причини досить прості:

• DMARC все ще встановлено як p=none, або потік відправки не є вирівняним.
• SVG містить заборонений вміст або не відповідає задокументованим обмеженням одержувача.
• BIMI assertion record сформований некоректно, опублікований під неправильним селектором або ще не відображається в DNS.
• Розміщений SVG або PEM-файл неможливо отримати безпечно.
• Ланцюжок сертифікатів або зв’язок із логотипом не валідується.
• Стороння платформа для відправки не налаштована для вирівняної автентифікації.
• Провайдер-одержувач не відображає індикатор для цього повідомлення або домену.

Скористайтеся аудитом BIMI для перевірки видимої конфігурації домену, а потім дотримуйтесь відповідного технічного посібника замість того, щоб одночасно змінювати кілька параметрів.

Дисциплінована послідовність впровадження

Пов’язані посібники з впровадження

• Технічний стандарт BIMI
• Підтримка BIMI поштовими клієнтами
• BIMI зі сторонніми відправниками та ESP
• Як перевірити, чи працює BIMI
• Чому логотип BIMI не відображається
• BIMI та Microsoft Outlook

Часті запитання

Чи працює BIMI без примусового застосування DMARC?

Ні, в задокументованому Google процесі роботи з BIMI — ні. Google вимагає політики DMARC p=quarantine або p=reject і pct=100, а не p=none.[2]

Чи достатньо звичайного SVG?

Ні. BIMI використовує обмежений профіль SVG Tiny P/S. Логотип, який відображається на веб-сайті, може містити елементи, що не відповідають обмеженням BIMI. Валідуйте фінальний розміщений актив, а не припускайте, що експорт із інструменту дизайну є придатним.

Чи гарантує валідний BIMI-запис логотип у кожній поштовій скриньці?

Ні. Відображення в одержувача залишається рішенням одержувача. BIMI Group зазначає, що провайдери можуть приймати локальні рішення для окремих доменів.[1]

Які емітенти VMC є активними?

Для портфельного контенту використовуйте затверджене актуальне формулювання: DigiCert та Entrust є активними емітентами VMC. Вимоги щодо сертифікатів та одержувачів можуть змінюватися, тому перевіряйте поточні вимоги перед подачею заявки.

Джерела

[1] BIMI Group — Mailbox Providers

[2] Google Workspace Admin Help — Set up BIMI

[3] BIMI Group — Supporting Documents