← Назад в блогРуководства

BIMI: логотип рядом с письмом в Gmail, требования и ограничения

Что такое BIMI-запись и что нужно для логотипа рядом с письмом: DMARC в режиме enforcement, логотип SVG Tiny PS, сертификат VMC или CMC и ограничения.

Опубликовано: · 6 мин чтения

BIMI (Brand Indicators for Message Identification) — это TXT-запись, которая сообщает почтовым провайдерам, где лежит ваш логотип, чтобы они могли показывать его рядом с письмами, прошедшими проверку DMARC. Сама запись — одна строка. Работа кроется в предварительных условиях: DMARC в режиме enforcement (p=quarantine или p=reject), логотип в ограниченном профиле SVG и, для провайдеров, которые интересуют большинство, сертификат на знак, выпущенный удостоверяющим центром. Но даже когда всё это на месте, показывать логотип или нет, решает получатель.

Одно нужно понимать с самого начала: BIMI — не стандарт RFC. Это спецификация рабочей группы AuthIndicators (BIMI Group), опубликованная в виде черновиков IETF (Internet-Drafts). Провайдеры реализуют её в разной степени, а их требования меняются.

Как выглядит запись

$ dig +short TXT default._bimi.example.com
"v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"
Тег Значение
v=BIMI1 Версия, должна идти первой
l= HTTPS-адрес логотипа (SVG)
a= HTTPS-адрес подтверждающего документа: сертификата на знак в формате PEM

default — это селектор. Отправитель может опубликовать и другие селекторы (например, newsletter._bimi.example.com) и выбирать нужный для каждого письма заголовком BIMI-Selector. Большинству доменов никогда не понадобится ничего, кроме default.

Поддомены наследуют запись: для письма с news.example.com получатель, не нашедший записи на default._bimi.news.example.com, обращается к записи организационного домена. Поддомен может опубликовать собственную запись, чтобы показывать другой логотип.

Требование 1: DMARC в режиме enforcement

Здесь на самом деле начинается большинство проектов по BIMI, и сюда уходит больше всего времени.

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
  • Политика организационного домена должна быть p=quarantine или p=reject. p=none не подходит.
  • sp=none (мягкая политика для поддоменов) и значение pct ниже 100 могут лишить домен права на логотип.
  • Каждое конкретное письмо должно проходить DMARC: SPF или DKIM проходит, и аутентифицированный домен выровнен с доменом в поле From.

Логика проста. Логотип — сигнал доверия, и получатель прикрепит его только к почте домена, который объявил всему миру, что подделки надо отклонять. Чтобы безопасно до этого дойти, нужна инвентаризация всех систем, отправляющих почту от вашего имени, выровненный DKIM у каждой из них и недели чтения отчётов перед ужесточением политики; порядок внедрения описан в статье MX, SPF, DKIM и DMARC: как они работают вместе. Текущее состояние домена покажет проверка DMARC в OrbitProbe, а генератор DMARC соберёт синтаксис записи.

Требование 2: логотип в формате SVG Tiny PS

Получатели не принимают произвольные SVG-файлы. Логотип должен соответствовать профилю SVG Tiny Portable/Secure (SVG Tiny PS) — урезанному профилю, определённому специально для BIMI:

  • никаких скриптов;
  • никаких внешних ссылок (ни подключаемых изображений, ни шрифтов, ни таблиц стилей): всё встроено в один файл;
  • никакой анимации;
  • квадратные пропорции;
  • рекомендуется сплошной фон, потому что провайдеры обрезают изображение до круга или скруглённого квадрата и показывают его как на светлой, так и на тёмной теме;
  • отдаётся по HTTPS.

Корневой элемент объявляет профиль, и ожидается наличие <title>:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny-ps" viewBox="0 0 100 100">
  <title>Example Ltd</title>
  …
</svg>

Экспорт напрямую из дизайнерского инструмента почти никогда не соответствует требованиям: в нём есть метаданные редактора, неверный baseProfile и нередко встроенное растровое изображение. Планируйте ручную чистку или отдельный шаг преобразования, а логотип держите по центру с запасом вокруг, чтобы круглая обрезка его не задела.

$ curl -I https://example.com/bimi/logo.svg
HTTP/2 200
content-type: image/svg+xml

Ответ 200, тип содержимого image/svg+xml и отсутствие редиректа на страницу входа или согласия: проверьте эти три пункта.

Требование 3: сертификат на знак

Тег a= указывает на сертификат, который связывает логотип с вашей организацией. Его выпускает удостоверяющий центр после проверки вашей личности и вашего права на логотип, причём сам логотип встраивается в сертификат. Выпускают их лишь немногие удостоверяющие центры. Существует два вида:

VMC (Verified Mark Certificate) CMC (Common Mark Certificate)
Зарегистрированный товарный знак Требуется Не требуется
Основание для логотипа Регистрация товарного знака Например, подтверждённое использование логотипа в прошлом
Проверка личности удостоверяющим центром Да Да

Это не TLS-сертификаты. Они не ставятся на веб-сервер и не имеют отношения к HTTPS-сертификату, под которым отдаются файлы.

Поддержка провайдерами по состоянию на сентябрь 2026 года

Поддержка различается у разных почтовых провайдеров и уже не раз менялась. Что известно на момент написания:

  • Gmail требует VMC или CMC. Google объявила о поддержке CMC в 2024 году; синяя галочка подтверждения привязана к VMC.
  • Apple Mail требует VMC.
  • Некоторые провайдеры могут показать логотип и без сертификата, по собственному усмотрению (запись «с самостоятельным утверждением», содержащая только тег l=).
  • Некоторые крупные провайдеры не поддерживают BIMI вовсе.

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

Чего BIMI не делает

  • Показ всегда остаётся решением получателя. Действительная запись, действительный сертификат и пройденный DMARC делают вас кандидатом. Провайдеры смотрят ещё и на репутацию домена и источника отправки и могут отказать, не объясняя причин.
  • Сам по себе он не улучшает доставляемость. BIMI не переносит почту из спама во входящие. Помогает та работа над DMARC, которую вы проделали, чтобы получить право на логотип; сам логотип показывается на письмах, которые и так были бы доставлены. Если ваши письма попадают в спам, начните с чек-листа проверки DNS для писем, попадающих в спам.
  • Это не гарантия от фишинга. Похожий по написанию домен может пройти тот же путь со своим логотипом, а получатели, чей почтовый клиент не показывает BIMI, в любом случае ничего не видят. Отсутствие логотипа ничего не доказывает.
  • Логотипы кэшируются. Получатели скачивают SVG и сертификат по собственному расписанию. Новый или изменённый логотип может появиться через несколько дней, а удалённый — задержаться.

Путь по порядку

  1. Выровняйте SPF и DKIM для каждого сервиса, который отправляет почту от вашего домена. Важнее всего выровненный DKIM, потому что он переживает пересылку.
  2. Опубликуйте DMARC с p=none и адресом rua, читайте отчёты.
  3. Перейдите на p=quarantine, затем на p=reject, при pct=100 и без sp=none.
  4. Подготовьте логотип SVG Tiny PS и разместите его по HTTPS на постоянном адресе.
  5. Получите сертификат (VMC, если у вас есть зарегистрированный товарный знак и нужна самая широкая поддержка, иначе CMC) именно для этого файла логотипа.
  6. Опубликуйте BIMI-запись на default._bimi.
  7. Отправьте настоящие письма на ящики у тех провайдеров, которые вам важны, и ждите.

Шаги 1–3 в организации с множеством отправляющих систем обычно занимают месяцы. Шаги 4–6 занимают дни плюс время проверки в удостоверяющем центре.

Чек-лист

  • _dmarc на организационном домене: p=quarantine или p=reject, pct не ниже 100, без sp=none
  • Каждый отправляющий сервис проходит DMARC с выравниванием (смотрите отчёты, а не одно тестовое письмо)
  • Логотип в формате SVG Tiny PS: квадратный, самодостаточный, без скриптов, без анимации, с baseProfile="tiny-ps"
  • Адрес логотипа и адрес сертификата отвечают 200 по HTTPS, без редиректов на другой контент
  • Логотип в сертификате — тот же, на который указывает тег l=
  • Одна TXT-запись на default._bimi, начинающаяся с v=BIMI1
  • Дата окончания сертификата записана в календарь: сертификаты на знак истекают, как и любые другие

Опубликованную BIMI-запись домена можно посмотреть в проверке BIMI.

Частые ошибки

  • Опубликовать BIMI-запись, пока DMARC ещё стоит на p=none, и ждать логотип, который не может появиться.
  • Поставить p=reject на основном домене и оставить в записи sp=none или pct=50 с более ранней стадии внедрения.
  • Загрузить SVG-экспорт дизайнера без изменений.
  • Разместить запись на _bimi.example.com вместо default._bimi.example.com.
  • Разместить логотип за редиректом, cookie-заглушкой или правилом CDN, которое блокирует небраузерные клиенты.
  • Изменить файл логотипа после выпуска сертификата. Сертификат содержит конкретный логотип; другой файл по адресу l= ему уже не соответствует.
  • Сначала купить сертификат, а проект по DMARC начать потом.
  • Ожидать логотип в каждом почтовом ящике. Поддержка у провайдеров частичная, а показ — на их усмотрение.
  • Считать BIMI средством защиты. Защиту даёт DMARC в режиме enforcement; BIMI — видимая награда за неё.

Проверьте в OrbitProbe

Поскольку в BIMI всё зависит от DMARC, начните с него. Проверка DMARC в OrbitProbe запрашивает запись на _dmarc для домена, показывает, какую политику он публикует (none, quarantine, reject), и отмечает отсутствующую, продублированную или некорректную запись. Запустите её сначала для организационного домена, а затем для каждого поддомена, с которого уходит почта. Проверка DNS показывает опубликованную политику на этот момент. Она не может сказать, проходят ли отдельные письма проверку с выравниванием (это видно в сводных отчётах DMARC), и никакой запрос не предскажет, решит ли почтовый провайдер показать логотип.