BIMI на субдоменах: як працює успадкування

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

Як працює успадкування BIMI

Успадкування BIMI відбувається за тією ж ієрархією пошуку, що й DMARC. Коли поштовий сервер-отримувач оцінює повідомлення, надіслане з marketing.example.com, він шукає BIMI-запис у такому порядку:

1. default._bimi.marketing.example.com — специфічний запис для субдомену
2. default._bimi.example.com — резервний запис організаційного домену

Якщо запис на рівні субдомену відсутній, отримувач переходить до запису організаційного домену. Це означає, що один BIMI TXT-запис, опублікований на default._bimi.example.com, автоматично покриває всі субдомени.

Що означає «організаційний домен»

Організаційний домен — це зареєстрований домен, тобто частина безпосередньо під публічним суфіксом. Для mail.example.com та marketing.example.com організаційним доменом є example.com. Успадкування BIMI завжди розв’язується вгору до цього рівня, ніколи до проміжного субдомену.

Публікація єдиного BIMI-запису для всіх субдоменів

Якщо всі ваші субдомени для надсилання використовують однаковий логотип, достатньо одного DNS-запису.

Кроки:

1. Переконайтеся, що ваш організаційний домен має дійсну DMARC-політику (див. вимоги до узгодження DMARC нижче).

2. Підготуйте квадратний SVG-логотип, що відповідає профілю SVG Tiny P/S.

3. Розмістіть SVG за стабільною, публічно доступною HTTPS-адресою.

4. Опублікуйте єдиний BIMI TXT-запис на вашому організаційному домені:

   text

   default._bimi.example.com  TXT  "v=BIMI1; l=https://brand.example.com/logo.svg; a=https://brand.example.com/cert.pem"
   

5. Переконайтеся, що на рівні субдоменів немає конфліктуючих BIMI-записів.

Усі субдомени — mail.example.com, marketing.example.com, transactional.example.com — тепер автоматично успадковують цей запис.

Перевизначення BIMI для окремого субдомену

Ви можете перевизначити успадкований запис для будь-якого окремого субдомену, опублікувавши окремий BIMI TXT-запис безпосередньо на мітці _bimi цього субдомену.

Коли варто перевизначати:

• Субдомен надсилає листи під іншим брендом або логотипом продукту.
• Субдомен потребує іншого Сертифіката верифікованого знака (VMC).
• Ви хочете придушити відображення BIMI для конкретного субдомену (опублікуйте порожній запис).

Кроки для перевизначення:

1. Визначте субдомен, який потребує іншого логотипу або сертифіката.

2. Опублікуйте специфічний для субдомену BIMI-запис:

   text

   default._bimi.marketing.example.com  TXT  "v=BIMI1; l=https://brand.example.com/marketing-logo.svg; a=https://brand.example.com/marketing-cert.pem"
   

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

Щоб придушити BIMI на субдомені, опублікуйте запис з порожнім значенням l=:

default._bimi.noreply.example.com  TXT  "v=BIMI1; l=;"

Покриття VMC для субдоменів

Сертифікат верифікованого знака (VMC) автентифікує ваш логотип і є обов’язковим для основних поштових провайдерів — включаючи Gmail та Apple Mail — для відображення індикатора бренду з позначкою верифікації.

Один VMC покриває всі субдомени, що використовують той самий логотип

VMC видається на конкретний файл логотипу (SVG), а не на конкретний домен або субдомен. За умови, що той самий SVG вказаний у всіх ваших BIMI-записах, один VMC покриває ваш організаційний домен і кожен субдомен, який успадковує або явно посилається на цей логотип.

Вам не потрібен окремий VMC для кожного субдомену.

Різні логотипи потребують різних VMC

Якщо різні субдомени відображають різні логотипи — наприклад, логотип материнського бренду на mail.example.com і логотип продукту на app.example.com — кожен окремий логотип потребує власного VMC.

Визначальним фактором завжди є кількість унікальних логотипів, а не кількість доменів або субдоменів.

Вимоги до узгодження DMARC для субдоменів

BIMI не відображатиметься, якщо надіслане повідомлення не пройде автентифікацію DMARC. Для відправників з субдоменів критично важливою конфігурацією DMARC є тег sp= — політика субдоменів.

Тег sp=

Тег sp= у DMARC-записі вашого організаційного домену визначає політику, що застосовується до повідомлень із субдоменів. BIMI вимагає політики quarantine або reject — політика none є недостатньою.

Приклад DMARC-запису з політикою субдоменів:

_dmarc.example.com  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"

Правила успадкування політики

Важливо: Якщо sp= не вказано, субдомени успадковують значення p=. Переконайтеся, що p= встановлено на quarantine або reject, перш ніж покладатися на успадкування.

Специфічні DMARC-записи для субдоменів

Ви також можете опублікувати DMARC-запис безпосередньо на субдомені, щоб перевизначити успадковану політику:

_dmarc.marketing.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

DMARC-запис на рівні субдомену має повний пріоритет над записом організаційного домену для цього субдомену — та сама логіка успадкування та перевизначення, що застосовується до BIMI-записів.

Поширені помилки BIMI для субдоменів

Короткий довідник: контрольний список BIMI для субдоменів

• [ ] DMARC p=