SPF, DKIM и DMARC для сайта на Битрикс: зачем нужны и как проверить

01

Почему настройка почты Битрикс начинается с домена, а не с шаблона

Когда посетитель отправляет форму обратной связи, 1С-Битрикс создаёт почтовое событие и передаёт его выбранному механизму отправки: PHP mail(), SMTP-серверу хостинга, корпоративной почте или внешнему транзакционному сервису. Получатель видит адрес в поле From и оценивает, имеет ли сервер право отправлять от имени указанного домена. Если такого права нет, письмо может попасть в спам, быть отклонено или дойти с предупреждением.

Типичная ошибка — указать в шаблоне адрес sales@company.ru, а отправлять письмо через сервер хостинга, который не внесён в SPF и не подписывает DKIM. Визуально уведомление сформировано правильно: тема, поля формы, ссылка на заявку есть. Но для Gmail, Mail.ru, Яндекс Почты и корпоративных шлюзов оно выглядит как возможная подмена отправителя.

SPF, DKIM и DMARC решают разные части одной задачи. SPF публикует список разрешённых отправителей в DNS. DKIM помещает в каждое письмо криптографическую подпись. DMARC сопоставляет результаты проверок с доменом в поле From и определяет политику обработки ошибок. Настраивать только одну запись недостаточно: например, SPF не защитит письмо при пересылке, а DKIM без DMARC не даёт владельцу домена единой политики.

Для маркетолога это не инфраструктурная формальность. От доставляемости зависят заявки, уведомления о заказах, письма менеджерам и корректная фиксация источника лида в CRM. Проверку лучше проводить на тестовой форме с полями имени, телефона, e-mail и UTM, а не на единичном письме «тест» из панели хостинга.

03

Что именно проверяют SPF, DKIM и DMARC

SPF — это TXT-запись в DNS домена. Она отвечает на вопрос: имеет ли IP-адрес или почтовый сервис право послать письмо с envelope sender, связанным с доменом. В записи должны быть перечислены все реальные каналы: корпоративная почта, SMTP-сервис, сервер сайта, сервис рассылок. Нельзя добавлять источники «на всякий случай»: широкое разрешение повышает риск отправки от имени домена.

DKIM работает иначе. Почтовый сервер подписывает исходящее письмо закрытым ключом, а публичный ключ публикуется в DNS по селектору, например selector1._domainkey.example.ru. Получающий сервер извлекает ключ и проверяет подпись. В заголовках успешный результат выглядит как dkim=pass. Подпись переживает многие промежуточные проверки лучше SPF, если содержимое подписанных частей не изменено.

DMARC публикуется в _dmarc.example.ru и связывает технические проверки с видимым адресом From. На старте обычно ставят p=none: письма не блокируются, но владелец получает отчёты. После аудита всех легитимных источников можно рассматривать quarantine или reject. Резкий переход к reject без инвентаризации отправителей способен остановить письма сайта, CRM и рассылок.

04

Инвентаризация отправителей: первый шаг перед изменением DNS

Одна DNS-запись SPF должна учитывать не абстрактную «почту компании», а конкретные источники. Сайт может отправлять заказы через SMTP Microsoft 365, письма менеджеров уходят через Яндекс 360, а маркетинговая рассылка — через отдельную платформу. Если заменить существующую SPF-запись новой строкой только для сайта, рабочая почта других подразделений начнёт получать SPF fail.

Сначала соберите таблицу: кто отправляет, какой домен указан в From, какой сервис или IP используется, есть ли DKIM и кто владеет доступом к DNS. Разработчик должен подтвердить способ отправки в настройках сайта, а не предполагать его по почтовому адресу в шаблоне. В 1С-Битрикс дополнительно проверьте почтовые события, шаблоны и адреса, заданные в настройках главного модуля.

Полезно разделить транзакционные и маркетинговые потоки. Уведомления о заказах и заявках должны иметь стабильный адрес отправителя, например noreply@ или orders@, а в Reply-To — реальный адрес отдела продаж. Тогда ответ клиента попадёт человеку, а техническая подпись не будет нарушаться подменой From на введённый посетителем e-mail.

05

Как проверить результат на письме из веб-формы

Проверка через DNS-сервисы полезна, но она не отвечает на главный вопрос: подписывает ли письмо фактический сервер, который использует сайт. Создайте временную тестовую форму или отправьте существующую форму с отдельной страницей. Введите распознаваемый текст, тестовый номер, e-mail и UTM-метки. Отправьте заявку на ящик в крупном почтовом сервисе и на корпоративный ящик, если он использует собственный антиспам-шлюз.

В полученном письме откройте технические заголовки. Ищите строку Authentication-Results и значения spf=pass, dkim=pass, dmarc=pass. Дополнительно сравните адрес в From, домен d= в DKIM-Signature и домен return-path. Для DMARC важен не только pass, но и alignment: домены должны совпадать либо быть организационно согласованными в рамках выбранного режима.

Параллельно проверьте прикладную цепочку. Заявка должна появиться в административной части или CRM один раз, с теми же контактами и UTM. Письмо менеджеру должно содержать ссылку или идентификатор обращения, чтобы ошибку можно было найти в журнале. О настройке почтовых событий и шаблонов можно свериться с документацией 1С-Битрикс.

06

Порядок проверки: от DNS до заявки в CRM

Изменения в DNS не вступают в силу мгновенно: срок зависит от TTL и кэшей резолверов. Поэтому сначала зафиксируйте исходное состояние: сохраните текущие TXT-записи, снимите заголовки нескольких писем и запишите, через какой канал отправляет сайт. Это позволит быстро откатить ошибочную правку и объяснить, что именно изменилось.

Не ограничивайтесь формой «обратный звонок». На проектах чаще всего забывают о письме после оформления заказа, восстановлении пароля, уведомлении администратору и автоматическом сообщении из интеграционного обработчика. Каждый тип события может использовать свой шаблон и адрес отправителя. Если в обработчике задан адрес посетителя в From, DMARC-проверка будет нестабильной.

Для руководителя проекта достаточно назначить владельцев: доступ к DNS — у доменного администратора, настройка SMTP и обработчиков — у разработчика, сценарии и получатели — у маркетинга или отдела продаж. После каждого этапа нужен один понятный артефакт: запись, заголовок, тестовая заявка или журнал изменений.

1. 1

   Соберите источники. Перечислите все сервисы, которые отправляют письма от имени домена.

2. 2

   Сохраните DNS. Экспортируйте действующие SPF, DKIM и DMARC-записи до правок.

3. 3

   Настройте канал. Укажите проверенный SMTP и единый доменный адрес From в событиях сайта.

4. 4

   Проверьте подписи. Отправьте реальные тестовые заявки и изучите полные заголовки.

5. 5

   Сверьте CRM. Убедитесь, что поля формы, UTM и ответственный сохраняются без дублей.

07

Ошибки, из-за которых почта сайта продолжает попадать в спам

Самая опасная ошибка SPF — создание второй TXT-записи с v=spf1. Для одного домена должна существовать одна SPF-политика; несколько записей часто дают постоянную ошибку PermError. Новые сервисы добавляют в имеющуюся запись через согласованный include или другой допустимый механизм после проверки документации поставщика.

У DKIM частая проблема связана не с ключом, а с тем, что сайт отправляет через другой сервер. Ключ опубликован для корпоративного почтового сервиса, но PHP mail() использует MTA хостинга без подписи. В таком случае запись в DNS существует, но в заголовке письма dkim=none или dkim=fail. Исправление — не «переиздать ключ», а настроить фактический канал доставки.

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

08

Какой режим DMARC выбрать для сайта и бизнеса

Для домена без инвентаризации безопаснее начать с записи p=none и адреса rua для агрегированных отчётов. Этот режим не просит получателей отклонять письма, но позволяет увидеть, откуда фактически идёт отправка и какие источники не проходят проверку. Отчёты приходят в XML и обычно требуют отдельного сервиса или технического специалиста для удобного анализа.

Политика quarantine рекомендует отправлять подозрительные письма в спам, а reject — отклонять их. Эти режимы уместны, когда подтверждены сайт, корпоративная почта, CRM, сервисы рассылок, счета и любые автоматические интеграции. Можно начать с pct=10 или pct=25, чтобы применить новую политику только к части потока и отследить последствия.

Для субдоменов, например mail.example.ru, правила могут отличаться от основного домена. Это полезно, когда транзакционная почта сайта отделена от маркетинговых рассылок. Но схема должна быть документирована: иначе при смене SMTP или подрядчика никто не поймёт, где нужно обновлять DNS и что сломается после удаления старого сервиса.

09

Что считать готовой настройкой

Готовая настройка — это не три строки, добавленные в DNS, и не скриншот из регистратора домена. Результат подтверждает реальное письмо из веб-формы или заказа: оно отправлено через известный канал, использует адрес домена компании, проходит SPF, DKIM и DMARC, а заявка сохраняется в нужной системе без потери полей.

Начните с аудита фактических отправителей и текущих DNS-записей. Не заменяйте SPF целиком, если не понимаете, какие сервисы уже используют домен. DMARC вводите поэтапно: сначала наблюдение и отчёты, затем усиление политики после проверки всех сценариев. Отдельно следите за адресом From: e-mail посетителя должен быть Reply-To, а не отправителем письма сайта.

Подключать подрядчика стоит, когда нет доступа к DNS, неизвестен маршрут отправки, письма форм проходят по разным обработчикам или после настройки нужно проверить связку сайт — CRM — уведомления менеджера. В рамках поддержки сайта можно зафиксировать схему, настроить безопасный SMTP-канал, проверить журналы и подготовить критерии для повторной проверки после обновлений.