SPF, DKIM и DMARC: как настроить аутентификацию писем и не попасть в спам

Вы запускаете акцию, готовите красивое письмо, проверяете верстку на трех устройствах, нажимаете «отправить». А потом смотрите в отчет — open rate 4%, и это при базе, которая раньше открывала на 25%. Письма не попали в спам в прямом смысле слова, они просто растворились где-то между вашим ESP и почтовым ящиком клиента. И виноват чаще всего не контент.

Проблема почти всегда сидит в технической прослойке, которую маркетологи привыкли спихивать на айтишников и забывать. Три буквенные аббревиатуры — SPF, DKIM, DMARC — решают, поверит ли почтовый сервер Gmail или Mail.ru, что письмо реально от вас, а не от мошенника, который прикрылся вашим доменом. Разложить это так, чтобы вы могли проверить настройку сами и поставить грамотную задачу разработчику, поможет CRM-маркетолог ClientCore Василина Бреусенко.

Зачем почтовикам вообще проверять, кто вы

Представьте, что почтовый сервер получателя — это охранник на входе в бизнес-центр. К нему ежесекундно подходят тысячи людей и говорят: «Я из компании ClientCore, пропустите». Охраннику нужен способ отличить настоящего сотрудника от человека, который просто назвал чужое имя. Аутентификация писем — это и есть пропускная система.

Без нее почтовик вынужден гадать. Поскольку фишинг и спуфинг (подделка отправителя) — это огромная индустрия, охранник по умолчанию настроен подозрительно. Любое письмо без четких доказательств уходит в спам, в карантин или отклоняется совсем. Для бизнеса с базой и повторными продажами это прямые деньги: триггерные цепочки, реактивация, брошенные корзины — все просто не доходит.

Приходит клиент: доставляемость упала с 96 до 71% за месяц, ничего не меняли. Лезем в DNS — а там SPF-запись с лишним include от старого сервиса, который отвалился полгода назад. Почтовики начали воспринимать домен как сомнительный. Починили запись за час, через две недели доставляемость вернулась к 95%.

Василина Бреусенко

CRM-маркетолог, ClientCore

SPF: список тех, кому разрешено отправлять от вашего имени

SPF (Sender Policy Framework) — это запись в DNS вашего домена, где перечислены все серверы и сервисы, которым разрешено слать письма от вашего имени. Mindbox, Unisender, ваша CRM, корпоративная почта — каждый, кто отправляет письма с адреса @вашдомен.ру, должен быть в этом списке.

Работает так: почтовик получает письмо, смотрит на адрес отправителя, идет в DNS-записи вашего домена и спрашивает, имеет ли этот сервер право отправлять от вашего имени. Если IP есть в SPF — все хорошо. Если нет — письмо подозрительное.

Главная ловушка SPF — лимит в 10 DNS-запросов (lookups). Каждый `include:` в записи может тянуть за собой свои include. Подключили пять разных сервисов рассылок, и вот уже превысили лимит — запись становится невалидной целиком, и проверка проваливается даже для легитимных писем.

DKIM: цифровая подпись, которую нельзя подделать

Если SPF проверяет, откуда пришло письмо, то DKIM (DomainKeys Identified Mail) проверяет, не подменили ли содержимое по дороге. Это криптографическая подпись, которую ваш сервер ставит на каждое исходящее письмо.

Механика простая на уровне идеи. У вас есть пара ключей — приватный и публичный. Приватный хранится на сервере отправки и подписывает письма, его никто не видит. Публичный лежит в DNS, и почтовик получателя берет его, чтобы проверить подпись. Совпало — значит, письмо действительно отправлено вами и не менялось в пути. Не совпало — что-то не так.

Для маркетолога здесь важно одно: DKIM настраивается на стороне сервиса рассылки. В Mindbox это делается через панель, вам выдают значение для DNS, вы или разработчик его прописываете. Дальше платформа подписывает все письма автоматически. Проблема возникает, когда домен в DKIM-подписи не совпадает с доменом отправителя — тогда DMARC проверку не засчитает.

Частая история при миграции на новую платформу: DKIM настроили, ключ в DNS прописали, но не проверили выравнивание с доменом из поля From. Внешне все зелено, тесты проходят, а DMARC валится — подпись стоит от технического поддомена платформы, а письмо как бы от основного домена. Это вылавливается только сквозной проверкой отчетов, вручную не заметишь.

Василина Бреусенко

CRM-маркетолог, ClientCore

DMARC: правила игры для всего домена

SPF и DKIM по отдельности — два разных способа доказать подлинность. DMARC (Domain-based Message Authentication, Reporting and Conformance) связывает их вместе и говорит почтовику, что делать с письмами, которые проверку не прошли.

DMARC задает политику. Их три. `p=none` — мониторинг: почтовик ничего не блокирует, но шлет вам отчеты. `p=quarantine` — подозрительные письма уходят в спам. `p=reject` — отклоняются совсем. Большинство компаний начинают с none, собирают данные, убеждаются, что вся легитимная рассылка проходит, и только потом ужесточают политику.

Второй ключевой момент — alignment, выравнивание. Недостаточно, чтобы SPF или DKIM просто прошли. Домен, который они подтверждают, должен совпадать с доменом в видимом адресе отправителя (поле From). Именно на выравнивании спотыкается большинство «вроде бы настроенных» доменов: письмо технически подписано, но подпись от чужого домена — и DMARC ее не засчитывает.

С 2024 года Gmail и Yahoo сделали DMARC обязательным для отправителей, которые шлют больше 5000 писем в сутки на их адреса. Для любого mid-market бизнеса с активной базой это означает: без DMARC вы просто не долетаете до значимой доли аудитории. Это уже не «хорошо бы», а условие входа.

Как настроить SPF, DKIM и DMARC: порядок действий

Порядок важен — он не даст вам сломать доставляемость в процессе настройки.

Шаг 1 — инвентаризация. Выпишите все сервисы, которые отправляют письма от вашего домена: CRM, платформа рассылок, транзакционные письма (чеки, подтверждения), корпоративная почта, формы обратной связи. Пропустите хоть один — и его письма перестанут доходить, когда вы ужесточите политику.

Шаг 2 — SPF. Соберите include всех актуальных сервисов в одну запись, проверьте лимит lookups. Если упираетесь в 10 — используйте flattening (схлопывание include в прямые IP) через специализированные сервисы.

Шаг 3 — DKIM для каждого сервиса отправки: берете значение в панели платформы, прописываете в DNS.

Шаг 4 — DMARC: начинаете с `p=none` и обязательно с тегом `rua` для сбора отчетов.

Дальше — выждать. Две-четыре недели на `p=none`, читаете отчеты, находите источники, которые проваливают проверку (часто всплывают забытые сервисы или неправильно настроенный поддомен). Чините. И только когда 100% вашей легитимной рассылки проходит SPF и DKIM с правильным alignment — повышаете политику до quarantine, потом до reject.

Никогда не выставляйте reject с первого дня. Видела кейс, где компания сделала это сразу после настройки — и за сутки половина транзакционных писем с подтверждением заказа ушла в никуда, клиенты не получали чеки. Откатывали ночью. DMARC ужесточается только после того, как отчеты две недели показывают чистую картину.

Василина Бреусенко

CRM-маркетолог, ClientCore

Чек-лист доставляемости email, который стоит прогнать прямо сейчас

Пройдитесь по нему, открыв свои DNS-записи и любой бесплатный проверочный сервис.

• SPF-запись одна, валидна, укладывается в 10 lookups, без лишних include
• DKIM настроен для каждого сервиса отправки, подпись валидна
• DMARC-запись существует, отчеты собираются и кто-то их читает
• alignment проходит и по SPF, и по DKIM с основным доменом
• для рассылок используется отдельный поддомен, а не корневой домен
• PTR-запись (обратный DNS) настроена для отправляющих IP
• репутация отправляющего IP и домена проверена в постмастерах Google и Mail.ru

Отдельно про поддомен. Грамотная практика — слать массовые рассылки не с @вашдомен.ру, а с @news.вашдомен.ру или похожего. Так репутация маркетинговых писем не пачкает репутацию транзакционных и деловой переписки. Если завтра кампания зацепит спам-жалобы, письма о подтверждении заказа продолжат доходить.

Настройка — это не разовая история. DNS-записи устаревают, сервисы меняются, кто-то добавляет новый инструмент рассылки и забывает прописать его в SPF. Проверяйте конфигурацию раз в квартал и обязательно — при любой миграции платформы или подключении нового канала.