SPF, DKIM, DMARC и BIMI: как сделать так, чтобы ваши письма доходили

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. За последний год ко мне минимум раз в неделю приходит клиент с одним и тем же запросом: «Наши счета и коммерческие предложения уходят в спам у клиентов, помоги». В 2026 году это уже не «было бы хорошо настроить аутентификацию» — это вопрос выживания корпоративной коммуникации. Mail.ru с октября 2024 года официально блокирует письма без DMARC от массовых отправителей, Gmail и Яндекс делают то же. В этой статье — практический разбор всех четырёх стандартов на боевых примерах из моего портфеля.

Что произошло на рынке email в 2024–2026

Чтобы понять, почему вопрос настройки SPF/DKIM/DMARC превратился из «приятной добавки» в «обязательное условие», давайте посмотрим хронологию событий за последние два года:

• Февраль 2024. Google и Yahoo одновременно объявляют новые требования к отправителям свыше 5 000 писем в сутки: обязательный DMARC, one-click unsubscribe, low spam rate. Кто не настроил — письма стали попадать в Junk.
• Октябрь 2024. Mail.ru присоединяется к этим требованиям и публикует свой postmaster guide. Без SPF + DKIM + DMARC массовая рассылка от вашего домена блокируется.
• Январь 2025. Microsoft 365 и Outlook.com подтягиваются и расширяют пороги: теперь даже разовые письма от незнакомых доменов без аутентификации идут в Junk.
• Лето 2025. BIMI получает поддержку у Mail.ru и Apple Mail, что подталкивает крупные российские бренды к получению VMC-сертификатов.
• Апрель 2026. На сегодня — для b2b-сектора в России настроенный DMARC = условный «зелёный паспорт» на доставку. Без него вы фактически работаете на 60 % мощности своего email-канала.

В моей практике у клиентов АйТи Фреш есть прямая зависимость: пока DMARC не настроен — 25–40 % писем проваливаются в спам у получателей. После настройки — 2–4 %. Это +20 % к доставляемости, которая прямо конвертируется в продажи.

SPF — простейший шаг, на котором обычно ломаются

SPF (Sender Policy Framework) — это TXT-запись в DNS вашего домена, которая перечисляет IP-адреса и хосты, которые имеют право отправлять почту от вашего имени. Получатель видит адрес отправителя, проверяет SPF домена и решает — впустить или нет.

Минимальный пример для домена, который шлёт почту через свой Postfix-сервер 81.177.6.45 и через Яндекс 360:

itfresh.ru.   IN TXT   "v=spf1 ip4:81.177.6.45 include:_spf.yandex.net ~all"

Что здесь важно. v=spf1 — обязательная преамбула. ip4: — IP вашего сервера. include: — подключение SPF-записи внешнего сервиса (Яндекс 360, Mail.ru, SendPulse). Хвостовой тег: ~all (soft fail — мягкий отказ, обычно ставлю на старте) или -all (hard fail — жёсткий отказ, ставлю после месяца DMARC-мониторинга).

Главные грабли по SPF, которые я постоянно вижу у новых клиентов:

• Лимит 10 DNS-lookup. SPF имеет жёсткое ограничение по RFC: не более 10 рекурсивных запросов через include/redirect. Включили SendPulse + Mailgun + Яндекс + Mailchimp — упёрлись. Письма перестают валидироваться. Решение — либо flatten записи через сервис типа dmarcian, либо отказаться от лишних сервисов.
• Несколько SPF-записей в одной зоне. Это нарушение RFC, и большинство почтовиков просто игнорируют ВСЕ ваши SPF, как будто их нет. Должна быть строго одна запись, объединяющая все источники.
• Забытый собственный сервер. Часто в SPF указан include:_spf.yandex.net, но не указан IP собственного 1С, который шлёт уведомления через свой Postfix. Эти письма проваливаются в спам.

DKIM — подпись, которая защищает целостность

DKIM (DomainKeys Identified Mail) — это криптографическая подпись каждого письма закрытым ключом вашего почтовика. Получатель берёт открытый ключ из вашего DNS, проверяет подпись и убеждается, что (а) письмо действительно от вас и (б) его не модифицировали по дороге.

Генерация ключей зависит от почтового сервера. Для Postfix + OpenDKIM:

# Генерируем ключ для селектора mail2026
sudo opendkim-genkey -s mail2026 -d itfresh.ru -b 2048
sudo mv mail2026.private /etc/opendkim/keys/itfresh.ru/
sudo chown opendkim: /etc/opendkim/keys/itfresh.ru/mail2026.private

# Содержимое mail2026.txt — публикуем в DNS
cat mail2026.txt

Содержимое txt-файла выглядит так:

mail2026._domainkey.itfresh.ru. IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Селектор (mail2026) — это произвольное имя, которое позволяет иметь несколько ключей одновременно. Я использую год + порядковый номер, чтобы помнить, когда генерировал. Минимум раз в год нужно ротировать ключи — это требование DMARC best practice.

В Microsoft 365 / Office 365 — DKIM активируется в Defender, ключи генерируются автоматически, в DNS публикуются CNAME selector1._domainkey и selector2._domainkey, указывающие на серверы Microsoft. В Яндекс 360 — ключ генерируется в админке, и админ публикует одну DKIM-запись.

DMARC — связующее звено и страховка от подделок

DMARC (Domain-based Message Authentication, Reporting & Conformance) — это политика, которая говорит почтовикам получателей: «если письмо от моего домена не прошло SPF и/или DKIM — делай вот это». Плюс — присылайте мне отчёты о том, кто и как пытается слать почту от моего имени.

Минимальная стартовая запись:

_dmarc.itfresh.ru. IN TXT
  "v=DMARC1; p=none; rua=mailto:dmarc@itfresh.ru; ruf=mailto:dmarc@itfresh.ru; fo=1; adkim=r; aspf=r; pct=100"

Разберём по тегам:

• p=none — никаких действий, просто отчёты. Обязательная стартовая стадия на 3–4 недели.
• rua — куда слать агрегированные отчёты (раз в сутки от каждого почтовика).
• ruf — куда слать форензик-отчёты (по каждому проваленному письму, не все почтовики поддерживают).
• fo=1 — генерировать форензик при провале хоть одного из SPF/DKIM.
• adkim=r / aspf=r — relaxed-режим алайнмента (домены сравниваются по organizational, а не точно).
• pct=100 — применять политику к 100 % писем.

Через 3–4 недели я смотрю в почтовом ящике dmarc@itfresh.ru сотни XML-отчётов — обычно их разбирает специальный сервис типа Postmark DMARC Digest, dmarcian, ondmarc. Я этим пользуюсь каждую неделю при настройке у нового клиента — если в отчётах видно, что 1С шлёт через свой IP, который не в SPF, или Mailchimp шлёт от вашего имени без подписи — это надо фиксить до перехода на reject.

После того как все легитимные источники добавлены и в отчётах больше нет «чужих» неподписанных писем, ставлю промежуточно p=quarantine на 2 недели, потом — p=reject. Только это даёт полноценную защиту от фишинга и подделок от вашего имени.

BIMI — логотип в письме как маркетинговое оружие

BIMI (Brand Indicators for Message Identification) — относительно молодой стандарт, который показывает логотип вашей компании рядом с именем отправителя у получателя в Gmail, Apple Mail, Yahoo, Mail.ru. Без BIMI там кружок с инициалами, с BIMI — ваш фирменный знак.

Зачем это нужно:

• Узнаваемость письма с первого взгляда — поднимает open rate на 10–15 % по моим данным у клиентов.
• Защита от фишинга — мошенники не смогут показать логотип, потому что у них нет VMC-сертификата.
• Доверие — клиент видит, что вы серьёзная компания, которая позаботилась о безопасности своей переписки.

Технические требования BIMI:

• DMARC обязательно с p=quarantine или p=reject и pct=100.
• Логотип в формате SVG Tiny PS (никаких градиентов, фильтров, внешних шрифтов), квадратный, прозрачный фон, размещён по HTTPS на вашем домене.
• VMC-сертификат (Verified Mark Certificate) от DigiCert или Entrust для Gmail и Mail.ru. Mark Certificate (упрощённый) для Yahoo и Apple Mail.

DNS-запись:

default._bimi.itfresh.ru. IN TXT
  "v=BIMI1; l=https://itfresh.ru/bimi/logo.svg; a=https://itfresh.ru/bimi/cert.pem"

VMC-сертификат стоит у DigiCert около 1 500 USD/год. Дорого — но для среднего и крупного бизнеса при 5 000+ писем в месяц окупается ростом доставки и кликов в первые 3–4 месяца. Для маленького офиса (10 ящиков, 200 писем в день) можно обойтись без BIMI и сосредоточиться на правильно настроенном DMARC.

Кейс: производственная компания и потерянные тендеры

В декабре 2024 года ко мне пришёл директор компании, которая поставляет металлоконструкции для крупных строек. Жалоба классическая: «Тендерные заявки и счета не доходят до клиентов — мы выпали из тендера на 40 миллионов рублей просто потому, что наши документы не дошли до тендерной комиссии». Стали разбираться.

Что я обнаружил при аудите:

• SPF — был, но устаревший: v=spf1 mx +all. +all — это «разрешить отправку с любого IP мира от моего имени». Фактически это сигнал «спам-доменам — вэлкам».
• DKIM — отсутствовал.
• DMARC — отсутствовал.
• В Mail.ru, на который шли тендерные заявки — все письма от компании автоматически уходили в Junk, причём чувствительность антиспама была повышена из-за плохой репутации домена.

За три недели мы привели в порядок все три записи: SPF с явными IP и Яндекс 360, DKIM ключ 2048 бит, DMARC с p=none и сбором отчётов. Через четыре недели мониторинга, увидев, что все легитимные источники подключены, переключили DMARC на p=reject. Параллельно прогрели домен через серию транзакционных писем (счета, акты), не делая массовых рассылок. Через два месяца проверили доставляемость — Mail.ru, Yandex, Gmail полностью пропускали в Inbox. Клиент заехал на следующий тендер уже с гарантией, что заявка дойдёт.

Чек-лист правильной настройки за полдня

Если вы решили сделать всё сами, держите мой чек-лист, который я выдаю клиентам после установочной встречи:

1. Сделать инвентаризацию: какие сервисы шлют почту от вашего домена. Не забыть 1С, мониторинг, корпоративный портал, CRM, marketing-рассылки.
2. Получить публичные SPF/CNAME-инструкции от каждого сервиса (Яндекс, Mail.ru, Microsoft 365, SendPulse, Unisender).
3. Собрать единый SPF в формате v=spf1 ... ~all, проверить на лимит 10 DNS lookup.
4. Сгенерировать DKIM-ключи для каждого источника, опубликовать TXT-записи в зону.
5. Создать почтовый ящик dmarc@вашдомен.ru для приёма отчётов.
6. Опубликовать DMARC с p=none, rua, ruf, pct=100.
7. Подключить сервис разбора отчётов (dmarcian, postmark, ondmarc) или поднять свой parsedmarc.
8. Через 3–4 недели проанализировать отчёты, добавить недостающие источники.
9. Переключить DMARC на p=quarantine на 2 недели, потом — на p=reject.
10. Протестировать через mail-tester.com, mxtoolbox.com, dmarcanalyzer.com — должны быть 10/10 по всем стандартам.
11. (Опционально) Заказать VMC-сертификат, подготовить SVG-логотип, опубликовать BIMI-запись.

Мониторинг после настройки

Главная истина — почтовая аутентификация не «настроил и забыл». Ключи DKIM ротируем раз в год. SPF постоянно обновляется по мере подключения новых сервисов. DMARC отчёты надо смотреть еженедельно — в них видно попытки фишинга от вашего имени, перед тем как мошенники нанесут реальный урон.

Я ставлю клиентам Zabbix-проверки на:

• Наличие и содержимое SPF/DKIM/DMARC-записей в DNS — раз в час.
• TTL VMC-сертификата (если есть BIMI) — алерт за 30 дней до истечения.
• Скорость роста размера ящика dmarc@ — если внезапно резкий всплеск отчётов, значит что-то происходит (фишинговая атака или сломался один из источников).

FAQ — что чаще всего спрашивают

Что важнее — SPF, DKIM или DMARC?

Все три обязательны и работают вместе. SPF проверяет IP отправителя, DKIM — целостность письма через подпись, DMARC связывает их и говорит получателю, что делать с непрошедшими проверку. Без хотя бы двух из трёх ваши письма попадают в спам у Mail.ru, Gmail и Яндекса.

Что такое BIMI и зачем нужен логотип в письмах?

BIMI — это стандарт, который показывает логотип компании рядом с именем отправителя в Gmail, Yahoo, Apple Mail и Mail.ru. Требует строгого DMARC и SVG-логотипа. Поднимает узнаваемость на 30–40 %, защищает от фишинга.

Сколько стоит сертификат VMC для BIMI?

От 1 200 до 1 800 USD в год у DigiCert или Entrust. В России выпускается через посредников. Mark Certificate (MC) дешевле — около 600 USD, но поддерживается меньшим количеством почтовиков.

Какую DMARC-политику ставить на старте?

Только p=none с rua-отчётами на 3–4 недели. Сначала смотрим в отчётах, кто легитимно отправляет от вашего имени, потом включаем quarantine, потом reject. Пропустить этот этап — потерять реальную почту.

Сколько стоит настройка под ключ?

В АйТи Фреш развёртывание полного стека SPF/DKIM/DMARC + анализ rua-отчётов в течение месяца + настройка BIMI обходится в 15 000–35 000 руб. в зависимости от количества доменов и почтовиков.