Как подготовить домен к показу логотипа BIMI

Чтобы почтовый сервис рассмотрел логотип BIMI, настройте DMARC с политикой p=quarantine или p=reject и pct=100, обеспечьте прохождение DMARC для писем и опубликуйте подходящую DNS-запись с SVG Tiny PS. Сертификат требуется не каждому получателю, а решение о показе принимает сам почтовый сервис. Ниже — рабочий порядок проверки без сказок о мгновенном результате.

Что BIMI проверяет до показа логотипа

BIMI — способ показать фирменный логотип возле письма в тех почтовых системах, которые поддерживают эту возможность и решили принять ваш домен. Для обычной <a href="https://itfresh.ru/uslugi/korporativnaya-pochta/">корпоративной почты</a> это дополнительный слой отображения, а не настройка, которая сама повышает доставляемость или доказывает добросовестность каждого отправителя. BIMI опирается на уже настроенную аутентификацию: SPF и DKIM должны быть выстроены так, чтобы хотя бы один прошедший механизм совпадал с доменом в видимом адресе From и письмо проходило DMARC. Если сервер подпишет письмо DKIM, но подпись окажется от постороннего домена, само наличие подписи делу не поможет.

Для BIMI подходит политика DMARC p=quarantine или p=reject; p=none недостаточно. Нужен также охват pct=100, иначе политика применяется не ко всей исходящей почте. Для используемых поддоменов проверяют и фактически действующую для них политику. Значит, «сначала обязательно reject» — неверное правило: quarantine тоже подходит, если DMARC настроен и проверка конкретного письма проходит. При этом карантин и отклонение влияют на чужие письма, которые не прошли проверку, поэтому переходить к ним вслепую нельзя. BIMI не заменяет защиту от подмены адреса и не является самостоятельным средством против фишинга.

Отдельно сверяю организационный домен и домен в From: у поддомена может действовать собственное правило, а у основного домена — отдельная запись BIMI. Если в DMARC указан sp=none, это не превращается в подходящую защиту только потому, что для корня написано p=reject. Для каждого реально используемого домена проверяют эффективную политику и фактический результат аутентификации письма. Поэтому одного снимка DNS недостаточно: контрольное письмо надо отправить через каждый важный сервис и посмотреть заголовки Authentication-Results, где видно, прошли ли SPF, DKIM и DMARC и какие домены участвовали в проверке.

С чего начать на примере офиса «Путь груза»

Разберу условный пример из вводных: московский логистический офис «Путь груза», 31 рабочее место. Здесь важна не цифра сотрудников сама по себе, а все источники отправки: почтовый сервер, сайт с формами, система учёта, рассылка и подрядчики. Я собираю список отправителей, проверяю домены в From и сверяю с DNS SPF и DKIM. Если найден забытый сервис, я не выкидываю его из SPF ради красивой строки: сперва выясняю, нужен ли он бизнесу и можно ли включить DKIM с выравниванием. Иначе можно получить аккуратный DNS и внезапно потерянные письма. Порядок проверок перед ужесточением политики подробнее разобран в материале про <a href="https://itfresh.ru/articles/dmarc-p-reject-3-oshibki-kotorye-ubyut-vashu-pochtu.html">ошибки при переходе на p=reject</a>.

Если сейчас стоит p=none, я сначала читаю агрегированные DMARC-отчёты, в том числе записи, которые приходят на адрес из параметра rua. Они помогают увидеть отправляющие IP и результаты проверок, но не дают волшебной гарантии, что ни один редкий сценарий не потерян: отчётный период может не включать сезонную рассылку, новый сервис или письмо от имени поддомена. После инвентаризации владелец почты подтверждает, какие источники легитимны; затем для них исправляют SPF, DKIM и выравнивание с From. Только когда поток понятен, выбирают enforcement-политику — quarantine либо reject — и применяют её ко всем сообщениям через pct=100. Я не обещаю здесь «100 % чистоты»: это не измеримый результат одной недели, а проверка всех реально используемых сценариев.

На таком условном разборе я не стал бы сообщать, что логотип появился через 48 часов или что его увидели восемь из десяти получателей. DNS обновляется с учётом TTL и кэшей, сертификат может проходить отдельную проверку, а каждый почтовый сервис устанавливает свои условия отображения. Поэтому итог аудита — не красивый скриншот из одного ящика, а список легитимных отправителей, исправленные механизмы аутентификации, состояние DMARC и проверенные ссылки на файлы BIMI. А цифры вроде «80 % аудитории увидит бренд» без замера конкретной аудитории — просто декорация.

Для перехода я разделяю отправителей на те, которыми управляет компания, и внешние сервисы. У внешнего поставщика проверяю, можно ли подписывать письма доменным DKIM-ключом и какой домен он ставит в подпись; менять include в SPF без понимания его назначения нельзя. Если письмо отправляет сайт, владелец должен знать, какой сервер его отправляет и кто отвечает за подпись. Затем я тестирую каждую категорию отдельно: обычное письмо сотрудника, уведомление с сайта, документ из учётной системы и рассылку. Один успешно доставленный тест из почтового клиента не подтверждает всю почтовую схему. В итоговой таблице фиксирую источник, домен From, результат SPF, домен DKIM и результат выравнивания DMARC — так видно, что именно исправлять, а не просто что «почта вроде работает».

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

После аутентификации настраивают публикацию. Для стандартного селектора запись размещают как TXT по имени default._bimi домена. Значение указывает версию BIMI, URL логотипа и, если есть, URL сертификата. Условный пример для документации выглядит так:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a="

Здесь example.com — пример из документации, а пустой a= означает, что в записи не указан сертификат. Синтаксис ввода в панели DNS может немного отличаться, но имена селектора и параметры записи должны остаться точными. Внимательно сверьте точку в имени, кавычки, адрес SVG и отсутствие пробелов или опечаток в значении.

Логотип нужно разместить по публичному HTTPS-адресу, который почтовый сервис сможет получить без входа в учётную запись. Если используется сертификат, его файл тоже должен быть доступен по URL, указанному в a=. Проверяйте DNS TXT-запись внешним запросом и отдельно открывайте оба ресурса снаружи вашей сети. Наличие правильной записи в панели регистратора ещё не доказывает, что авторитетные DNS-серверы отдают именно её. Также не путайте BIMI с DMARC: у них отдельные TXT-записи и разные имена. Для домена на Zimbra пригодится отдельная инструкция по <a href="https://itfresh.ru/articles/nastroi-ka-spf-dkim-dmarc-v-zimbra-proverka-cherez-mxtoolbox.html">проверке SPF, DKIM и DMARC</a>.

Значение l= — URL логотипа, а a= — URL сертификатного файла, если сертификат используется. Это не взаимозаменяемые поля: подставить PEM вместо SVG в l= или SVG вместо сертификата в a= — значит опубликовать бессмысленную запись. В некоторых вариантах сертифицированный логотип встраивается в PEM-файл, поэтому получатель читает знак из него; конкретный пример записи зависит от способа публикации и требований получателя. У отдельных сервисов есть дополнительные ограничения на домен, где размещён файл. Например, их справка может потребовать хранить SVG на том же домене, что и исходящую почту. Я сверяю это до публикации: снаружи должны открываться именно финальные URL, которые записаны в DNS, без перенаправления на страницу входа или временный файл.

Как подготовить SVG, чтобы его приняли

Обычный файл с расширением .svg ещё не означает, что логотип подходит для BIMI. Требуется профиль SVG Tiny Portable/Secure — его часто сокращают до SVG Tiny PS. Практический контрольный список короткий: холст квадратный, знак узнаваем в маленьком размере, фон сплошной, файл не превышает 32 КБ. Последний предел указан в официальных рекомендациях по настройке, поэтому я использую его как безопасный ориентир. Прозрачность может выглядеть по-разному на светлом и тёмном фоне, и «на макете красиво» тут не считается тестом. Лучше проверить знак в размере аватара до загрузки в DNS.

В SVG не должны попадать скрипты, анимация или внешние ссылки на изображения и шрифты: файл обязан быть самодостаточным и безопасно обрабатываться получателем. После экспорта проверьте профиль, поля XML, размер и доступность файла по HTTPS. Отдельно убедитесь, что сервер отдаёт корректный MIME-тип image/svg+xml; некоторые системы проверяют это наряду с содержимым. Если исходный брендбук содержит сложные градиенты или мелкие подписи, это не автоматический запрет, но такой рисунок часто теряет читаемость в крошечном кружке. Упростить композицию здесь разумнее, чем спорить с тем, как её уменьшает чужая почтовая программа.

Проверка на рисунке должна быть не только технической. Я смотрю логотип в маленьком масштабе, на светлом и тёмном фоне, затем проверяю, что на хостинге лежит именно тот файл, который прошёл валидацию. Одна официальная рекомендация предлагает добавить в SVG элемент <desc> с описанием для доступности; это полезная деталь, но она не заменяет базовые требования SVG Tiny PS и не является универсальной гарантией отображения. После финального изменения файл валидируют повторно. Если меняется сам знак, размер холста или способ экспорта, старый результат проверки уже не доказывает, что новая версия соответствует профилю.

• Профиль SVG Tiny PS
• Квадратный холст и простой фон
• Размер не более 32 КБ
• Нет скриптов, анимации и внешних ссылок
• Публичный HTTPS и MIME image/svg+xml

Когда нужен сертификат и почему значок не гарантирован

Опубликованная BIMI-запись может указывать на логотип без сертификата, но поддержка такой записи ограничена и зависит от почтового сервиса. Часть получателей требует подтверждение связи бренда с доменом и принимает сертификат VMC или CMC. VMC связан с проверкой зарегистрированного товарного знака; CMC — другой тип подтверждения, который нельзя подменять рассуждением «у нас есть логотип, значит, подойдёт любой документ». Перед заказом сертификата я сверяю требования именно тех почтовых систем, где нужен значок, и проверяю, подходит ли права на используемую версию бренда под их процедуру. Сам сертификат — не обычный TLS-сертификат сайта, а отдельное подтверждение для BIMI.

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

Если значка нет, я иду по цепочке от проверяемого к зависимому: письмо прошло DMARC с выравниванием; политика стоит на quarantine или reject и действует на весь поток; TXT-запись находится у правильного селектора; получатель может скачать SVG или PEM; файлы соответствуют требованиям; сам почтовый сервис поддерживает BIMI для этого сценария. Для DNS и публичных URL проверка должна идти из внешней сети, а не с сервера, где файл лежит локально. Отдельное руководство для одного из получателей говорит, что после добавления DNS-записи логотип может появиться в течение 48 часов, но это ориентир конкретного сервиса, а не SLA для всех почтовых систем. Поэтому я не обещаю ни точное время появления, ни долю адресатов: фиксирую доступность и корректность публикации, а отображение проверяю на нескольких реальных получателях.

Частые вопросы