BIMI на практиці: як довести логотип бренду до інбокса Gmail і Apple Mail
Ти додав default._bimi TXT-запис тиждень тому, а в Gmail усе одно сіре коло з ініціалом. Проблема майже ніколи не в BIMI-записі. Розбираємо весь ланцюг DMARC → BIMI → SVG P/S → VMC: чому кожна ланка ламається, у чому пастка з SVG-профілем і за що насправді платиш ~1500 $/рік за сертифікат.
EvilMail Team14 липня 2026 р.11 хв читання
Ти додав default._bimi TXT-запис тиждень тому, ще й перевірив синтаксис у трьох валідаторах, а в Gmail усе одно сіре коло з першою літерою назви. Класика. І майже завжди причина не в самому BIMI-записі — він якраз коректний. Причина №1, яку я бачу в дев'яти випадках із десяти: DMARC не на enforcement. Політика p=none, або pct менше за 100, або її щойно виставили і провайдер їй ще не довіряє.
BIMI — це не окрема фіча, яку вмикаєш одним рядком у DNS. Це надбудова над автентифікацією, і логотип рендериться лише тоді, коли зійдеться весь ланцюг залежностей. Зламай будь-яку ланку — і замість лого користувач бачить дефолтний ініціал. Розберемо ланцюг у тому порядку, у якому його читає поштовий провайдер, а не в тому, у якому про це пишуть у більшості інструкцій.
Ланцюг залежностей, який усі ламають
Порядок тут не рекомендація, а жорстка послідовність воріт. Провайдер перевіряє їх зверху вниз і зупиняється на першому «ні».
SPF і DKIM проходять і вирівняні (aligned). BIMI спирається на DMARC, а DMARC вважає лист автентифікованим, лише коли хоча б один із механізмів проходить із доменним вирівнюванням. Просто «SPF pass» на bounce-домені не рахується.
DMARC-політика на enforcement.p=quarantine або p=reject, pct=100, і sp не none (інакше сабдомени пробивають політику). Gmail і Yahoo свідомо ігнорують BIMI при p=none або pct<100 — це зроблено, щоб лого не став подарунком для спуферів.
Домен має репутацію відправника. Свіжовиставлену політику p=quarantine треба «витримати» кілька тижнів реального трафіку. Провайдер хоче побачити, що ти справді фільтруєш підробки, а не поставив reject про людське око.
І лише тоді читається BIMI-запис. SVG по HTTPS, дійсний VMC у теґу a=.
Наголос, який економить тижні: DMARC треба виставити на enforcement заздалегідь і дати йому попрацювати. Якщо ти вмикаєш reject і BIMI в один день, лого не з'явиться миттєво навіть за ідеального решти ланцюга — провайдеру потрібен час, щоб побачити стабільний aligned-трафік під новою політикою.
Анатомія BIMI-запису в DNS
Сам запис простий — три теґи. Ось як він виглядає:
dns
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"
`v=BIMI1` — версія, завжди перша.
`l=` — URL до SVG-логотипу. Обов'язково HTTPS із валідним сертифікатом. Не HTTP, не самопідписаний.
`a=` — URL до VMC у форматі .pem. Без нього Gmail і Apple логотип не покажуть узагалі.
Порожній l="" — це не помилка, а свідома конструкція: означає «я підтримую BIMI, але навмисно не показую лого». Використовується рідко, але знати варто, щоб не сплутати з поламаним записом.
Селектор за замовчуванням — default._bimi. Якщо потрібен окремий логотип для різних потоків (наприклад, транзакційка проти маркетингу), відправник ставить у заголовок листа BIMI-Selector: v=BIMI1; s=brand, і провайдер шукає запис уже за brand._bimi.example.com.
Типові помилки в теґу l=, які я витягую з логів найчастіше:
HTTP замість HTTPS, або сертифікат домену з SVG протермінований.
Редірект на CDN — деякі провайдери не йдуть за 301/302 і трактують це як недоступний ресурс.
404 через неправильний шлях (файл переклали, забули оновити запис).
MIME-тип: сервер віддає SVG як text/plain або application/octet-stream замість image/svg+xml — і файл ігнорується.
SVG Tiny P/S: це не той SVG, що експортує Figma
Ось де провалюється більшість. BIMI вимагає не «просто SVG», а профіль SVG Portable/Secure (P/S) — жорстко урізану підмножину SVG Tiny 1.2. Ідея профілю проста: логотип має рендеритися однаково скрізь і не бути вектором атаки, тому все динамічне й зовнішнє заборонено.
Що root-елемент мусить мати:
<svg version="1.2" baseProfile="tiny-ps" ...> — саме tiny-ps, а не tiny чи full.
Обов'язковий <title> одразу всередині <svg>.
Квадратний viewBox зі співвідношенням 1:1.
Суцільний fill, логотип відцентрований по x і y.
Що заборонено (наявність будь-чого з цього робить файл невалідним):
<script> — жодного JS.
Зовнішні посилання: xlink:href на URL, зовнішній CSS.
Растрові вставки <image> (PNG усередині SVG не проходить).
<a> — жодних гіперпосилань.
Анімація: <animate>, будь-який SMIL.
Рекомендований розмір файлу — до ~32 КБ. Ось мінімальний валідний приклад, від якого варто відштовхуватися:
Експорт із Figma, Illustrator чи Inkscape майже завжди дає baseProfile відсутнім або встановленим у щось інше, тягне за собою <metadata>, <defs> з фільтрами, іноді вбудований CSS-клас — і валідатор відхиляє файл. Реальний воркфлоу конвертації: експортуєш чистий SVG, руками вирізаєш metadata, defs, будь-які скрипти й фільтри, додаєш version="1.2" baseProfile="tiny-ps" і <title>, приводиш viewBox до квадрата. Це п'ять хвилин у редакторі, але їх треба зробити свідомо.
VMC і CMC: за що платиш сертифікат
Тепер найдорожча ланка. Gmail показує BIMI-логотипи з 2021 року, а синю позначку «verified» — з 2023-го; Apple Mail підхопив BIMI з iOS 16 і macOS Ventura. Обидва вимагають VMC. Yahoo та Fastmail теж підтримують BIMI. Без VMC у топових провайдерах логотипа не буде — крапка.
VMC (Verified Mark Certificate) видають DigiCert і Entrust. У DigiCert це близько 1499 $/рік. І головна вимога — не гроші, а зареєстрована торгова марка: USPTO, EUIPO, WIPO, український Укрпатент тощо. Причому реєструється саме той знак, який лежить у теґу l=. Логотип у SVG має збігатися із зображенням у свідоцтві на ТМ, інакше центр сертифікації (CA) не пройде валідацію.
Технічна суть, за яку платяться гроші: CA вшиває логотип усередину сертифіката як logotype-розширення за RFC 3709. Тобто картинка не просто «лежить поруч» — вона криптографічно прив'язана до валідованого бренду підписом центру сертифікації. Ось що робить BIMI непідробним: зловмисник може скопіювати твій SVG, але не може отримати VMC із твоєю ТМ усередині.
Є дешевша альтернатива — CMC (Common Mark Certificate). Вона для знаків, які не є зареєстрованою ТМ: державні, публічні, некомерційні марки, а також бренди без свідоцтва. CMC коштує менше за VMC, але станом на 2026 його підтримує переважно Gmail, і синьої «verified» галочки він не дає — тільки саму картинку. Моя чесна позиція: якщо в тебе немає зареєстрованої торгової марки, BIMI поки не для тебе. Або реєструй ТМ (це місяці й окремі гроші), або чекай на ширшу підтримку CMC. Отримати логотип без ТМ через VMC неможливо в принципі — CA просто не видасть сертифікат.
Перевірка і дебаг у терміналі
Коли щось не рендериться, я не гадаю, а йду по ланцюгу воріт із першої діаграми знизу вгору. Ось базовий набір:
bash
# 1. Що реально лежить у BIMI-записі
dig +short TXT default._bimi.example.com
# 2. Головна причина №1 — перевіряємо DMARC на enforcement
dig +short TXT _dmarc.example.com
# шукаємо p=quarantine або p=reject, pct=100, sp не none
# 3. SVG віддається по HTTPS з правильним MIME?
curl -sI https://example.com/bimi/logo.svg
# треба HTTP/2 200 і Content-Type: image/svg+xml
# 4. Інспекція VMC: емітент, термін і вшитий logotype
openssl x509 -in vmc.pem -text -noout | grep -A3 -i "logotype\|Not After\|Issuer"
Якщо curl -I показує Content-Type: text/html — сервер віддає не той MIME, і жоден валідатор далі не піде. Якщо openssl не показує logotype-розширення — тобі продали не VMC або файл зіпсовано під час експорту.
Поверх ручних команд — два обов'язкові сервіси. BIMI Inspector на bimigroup.org проганяє весь ланцюг разом і покаже, на яких воротах ти застряг. А Google Postmaster Tools — єдине надійне джерело правди про те, чи Gmail взагалі бачить твою автентифікацію й довіряє домену; без нормальних DMARC-агрегатних звітів там ти дебажитимеш наосліп. Типовий цикл: спершу підтверджуєш по агрегатних DMARC-звітах, що трафік проходить aligned, потім валідуєш SVG, і лише в кінці колупаєш VMC.
Чекліст впровадження
Порядок дій, у якому це реально працює, а не в якому хочеться:
Довести SPF і DKIM до стабільного aligned на всьому легітимному трафіку.
Виставити DMARC p=quarantine (або reject), pct=100, sp не none — і витримати кілька тижнів.
Підготувати SVG Tiny P/S (baseProfile="tiny-ps", <title>, квадратний viewBox) і провалідувати його.
Купити VMC у DigiCert або Entrust; логотип у сертифікаті має збігатися з SVG.
Викласти SVG і .pem на HTTPS із правильним MIME image/svg+xml.
Опублікувати default._bimi TXT із v=BIMI1; l=…; a=….
Перевірити: dig, BIMI Inspector, і тестовий лист із чистого домену в Gmail та Apple Mail.
Остання дія, яку люди пропускають: надішли тестовий лист і подивись на нього в мобільному Gmail, а не тільки на десктопі. Десктопний вебклієнт і застосунок на iOS/Android рендерять аватар відправника по-різному, і буває, що на десктопі логотип уже є, а в застосунку ще висить старий кеш — або навпаки.
І тверда думка про ROI. BIMI виправданий там, де твій логотип бачать масово й де впізнаваність прямо конвертує — B2C-розсилки великих ритейл- і фінансових брендів. Для суто транзакційної пошти невеликого сервісу ~1500 $/рік за картинку в аватарці окупаються погано: гроші й час краще вкласти в те, що BIMI все одно вимагає першим — залізний DMARC на enforcement і чисту репутацію домену. Автентифікацію ти зробиш у будь-якому разі; логотип — це вишенька, за яку є сенс платити, лише коли її справді хтось побачить.
