SPF, DKIM и DMARC: почему письма из CRM требуют проверки домена

CRM показывает «доставлено», а получатель письма не видит. Разбираем, как проверить домен отправки по заголовкам и отличить проблему аутентификации от фильтрации и чтения.

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

Письмо ушло, а его нет: что именно проверять в домене отправителя

Представим условную ситуацию: менеджер в CRM нажимает «Отправить», интерфейс показывает зелёную галочку «доставлено», а через день клиент говорит, что ничего не получал. В CRM всё чисто, в журнале отправки — статус успеха, в папке «Отправленные» письмо есть. Дальше начинается знакомый по офисным разговорам перебор версий: «наверное, у них спам», «позвони и попроси проверить», «а давай отправим с личной почты менеджера». В этом условном случае подпись «доставлено» скрывает лишь приём письма сервисом отправки. В другой интеграции тот же статус может соответствовать иному событию. Поэтому сначала сверяют контракт статусов CRM и почтового провайдера: отображаемая галочка сама по себе не подтверждает ни получение нужным человеком, ни прочтение.

Механизм, который стоит держать в голове, простой по идее и муторный по деталям. Письмо проходит несколько независимых ворот: аутентификацию домена отправителя, приём на сервере получателя, фильтрацию и, наконец, решение человека прочитать. На каждом шаге свой набор причин для отказа, и лечатся они разными действиями. Если смешать эти шаги в одну кучу, диагностика превращается в гадание, а «настройка почты» — в бесконечную переписку с подрядчиком. Эта статья — про один узкий срез: как убедиться, что домен, с которого CRM шлёт служебные и клиентские письма, настроен и проверен, и как отличить проблему домена от всех остальных.

Если ваша задача — проверить домен отправки, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Три записи в DNS, которые решают разные задачи

SPF, DKIM и DMARC часто упоминают одной связкой, будто это один переключатель «включить доставляемость». На самом деле это три разных механизма с разной логикой. SPF отвечает на вопрос «имел ли право этот сервер отправлять от имени домена». Список разрешённых серверов лежит в TXT-записи домена, и получатель сверяет по нему IP-адрес отправителя. DKIM — это криптографическая подпись: сервер отправки подписывает письмо приватным ключом, а получатель проверяет подпись публичным ключом, опубликованным в DNS. DMARC связывает первые два и говорит получателю, что делать, если проверки не сошлись, — и куда присылать отчёты.

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

Полезно держать в голове, что записи живут в DNS домена, а не в CRM. CRM лишь сообщает сервису отправки, от чьего имени слать. Поэтому «настроить почту в CRM» — это на самом деле «привести DNS домена в соответствие с тем, через что вы шлёте». Официальные рекомендации Google для отправителей описывают, какие проверки ожидает крупный почтовый провайдер от массовых отправителей, — это полезный ориентир, но не гарантия, что конкретный получатель поведёт себя так же: правила для отправителей писем. Там же есть отдельные инструкции по настройке SPF и настройке DKIM — их удобно использовать как чек-лист синтаксиса, а не как обещание результата.

Почему «зелёная галочка» ничего не доказывает

Самое частое заблуждение в этой теме — считать статус в CRM отчётом о доставке. Между «сервер отправки принял письмо» и «письмо лежит во входящих у клиента» может быть несколько развилок, и ни одна из них не видна из интерфейса CRM. Сервер отправки может принять письмо и потом получить временный отказ от сервера получателя. Письмо может пройти аутентификацию и всё равно попасть в спам из-за репутации или содержания. Получатель может отфильтровать его по своим правилам. Наконец, человек может просто не открыть папку.

Отсюда практический вывод: чтобы разбирать инциденты, нужен не один статус, а цепочка свидетельств. Минимум — заголовки письма (headers) из того экземпляра, который дошёл хотя бы до одного получателя, и результат проверки аутентификации, который получатель записал в этих заголовках. Если письмо не дошло вообще никуда, нужны логи сервиса отправки: принял ли он письмо, что ответил сервер получателя. Без этих двух источников любой разговор о «плохой доставляемости» — это разговор о погоде.

И здесь всплывает организационная проблема, а не техническая. В небольшой компании доступ к DNS часто у веб-студии или «того человека, который делал сайт», доступ к сервису отправки — у маркетолога, а CRM администрирует интегратор. Когда письма перестают доходить, каждый смотрит в свой угол и не видит общей картины. Прежде чем что-то менять, стоит зафиксировать, кто владеет DNS-зоной, кто владеет сервисом отправки и кто отвечает за переписку с получателями. Это скучно, но именно отсутствие этой карты ответственности превращает часовой инцидент в трёхдневный.

Условный эпизод: письма из CRM перестали доходить после смены сервиса

Разберём условный, но типичный сценарий. Компания среднего размера рассылает клиентам счета и уведомления из CRM через один сервис отправки. В какой-то момент решают перейти на другой сервис — дешевле, удобнее, «там всё современное». В CRM меняют настройки SMTP, отправляют тестовое письмо на корпоративный ящик, оно приходит. Через неделю выясняется, что часть клиентов не получает уведомления, а у нескольких писем в заголовках стоит отметка о провале проверки.

Что произошло. В SPF-записи домена остался старый список серверов, нового сервиса там нет. DKIM-ключ нового сервиса не опубликован в DNS, а старый селектор указывает на ключ прежнего сервиса. Тестовое письмо дошло, потому что получатель на тот момент был мягок к отправителю или письмо ушло на ящик, где фильтры настроены иначе. Через неделю накопилась статистика, и часть писем начала отсекаться.

Порядок действий здесь такой. Сначала выписать, через какие серверы реально идёт отправка: CRM, сервис рассылок, корпоративная почта сотрудников, возможно, ещё что-то вроде формы на сайте. Затем сверить SPF-запись со списком этих серверов. Потом проверить, что DKIM-селектор нового сервиса опубликован и подпись сходится на реальном письме. И только после этого трогать DMARC-политику. Если сделать наоборот — сразу поставить строгую политику, — можно отрезать почту, которая до этого доходила.

Отдельная ловушка — «тест на свой ящик». Он почти ничего не доказывает, потому что ваш ящик, скорее всего, в белом списке у вашего же провайдера и фильтры там мягче, чем у клиента. Проверять надо на нескольких внешних получателях, желательно разных провайдеров, и смотреть не «пришло/не пришло», а заголовки аутентификации.

Какой домен проверяют SPF и DKIM на самом деле

Видимый адрес From не определяет автоматически все почтовые проверки. SPF проверяет домен SMTP MAIL FROM (а в отдельных случаях HELO) и разрешённые для него отправляющие узлы. DKIM проверяет подпись по домену d= и селектору из заголовка DKIM-Signature. DMARC сопоставляет прошедшие проверки с доменом видимого From по правилам выравнивания. Поэтому нельзя посмотреть только на адрес отправителя в интерфейсе CRM и объявить DNS настроенным.

Если компания использует поддомен, выпишите фактические домены из заголовков тестового письма и из конфигурации сервиса отправки. SPF родительского домена не наследуется как готовое разрешение для произвольного поддомена MAIL FROM. DKIM-запись ищут по селектору и домену подписи, которые могут отличаться от видимого From. Поведение DMARC для поддоменов зависит от найденной записи и её политики; один набор записей нельзя без проверки копировать во все зоны.

Для рабочего перечня достаточно связать поток писем, сервис отправки, видимый From, MAIL FROM, d= и селектор. Затем проверить результат SPF, DKIM и DMARC в заголовках реального тестового письма. Если какой-либо домен или селектор неизвестен, его уточняют у администратора сервиса до изменения DNS. Поддомен может помочь разделить потоки, но сам по себе не гарантирует отдельную репутацию или попадание во входящие.

Пересылка: когда письмо ломается уже после отправки

Есть класс проблем, который не связан с настройками домена отправителя напрямую, но регулярно всплывает в той же диагностике, — пересылка. Клиент настроил автоматическую пересылку со своего рабочего ящика на личный, письмо уходит дальше, и на этом втором шаге SPF может не сойтись: письмо теперь отправляет сервер пересылки, которого нет в SPF-записи исходного домена. DKIM при пересылке может выжить, потому что подпись привязана к телу и набору подписанных заголовков, а не к IP. Но если пересылка меняет подписанные заголовки или тело, подпись тоже не сойдётся. Именно поэтому DKIM считают более устойчивым механизмом, чем SPF.

Для отправителя это означает, что жалобы «письмо не дошло» могут приходить от людей, у которых настроена пересылка, и виноват в этом не ваш домен. Проверить это можно по заголовкам: если в цепочке виден промежуточный сервер пересылки, а SPF не сошёлся именно на нём, — дело не в вашей настройке. Это не значит, что проблему надо игнорировать: возможно, стоит попросить получателя настроить пересылку так, чтобы она сохраняла письмо целиком, или предложить альтернативный адрес. Но чинить DNS домена в этом случае бессмысленно.

Неверный селектор DKIM: самая незаметная поломка

DKIM-селектор — это метка, по которой получатель находит публичный ключ в DNS. В записи домена может быть несколько ключей с разными селекторами, и сервис отправки подписывает письма конкретным селектором. Если в DNS опубликован ключ, а сервис подписывает другим селектором, подпись не проверится, и внешне всё будет выглядеть нормально: письмо уходит, ошибок нет, а в заголовках у получателя стоит dkim=fail.

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

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

Слишком строгая политика без предварительной проверки

DMARC-политика бывает в нескольких режимах: от «ничего не делать, только собирать отчёты» до «отклонять письма, не прошедшие проверку». Соблазн сразу поставить строгий режим понятен: кажется, что так «безопаснее». На практике это самый быстрый способ отрезать легитимную почту, о существовании которой вы не знали.

Прежде чем ужесточать политику, нужно собрать статистику: кто шлёт от имени домена, проходят ли эти письма проверки, нет ли среди отправителей чего-то неожиданного — например, старого сервиса рассылок, о котором забыли, или формы на сайте, которая шлёт уведомления через сторонний сервер. DMARC-отчёты как раз для этого и нужны, но их надо читать, а не просто складывать в папку. Отчёты приходят в виде XML-файлов, и без инструмента их разбора это малополезная груда текста.

Рекомендация здесь такая: сначала режим «только наблюдать», потом — после того как вы убедились, что все легитимные отправители проходят проверки, — постепенное ужесточение. И на каждом шаге проверка на реальных письмах к разным получателям. Строгая политика — это не цель, а следствие того, что вы разобрались со всеми отправителями. Если разобраться не удалось, строгая политика только усугубит проблему.

Проверка почтового домена: карточка домена отправки

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

Такая карточка особенно полезна интеграторам, которые ведут несколько клиентов: без неё каждый новый проект начинается с археологии. И она же дисциплинирует: если поле «дата последней проверки» пустое полгода, значит, никто не смотрел, а письма тем временем могли тихо перестать доходить.

Проверка почтового домена на экране сотрудника

Здесь важно разделить два интерфейса, потому что смешивать их — источник конфликтов. Менеджеру в CRM не нужны SPF-записи и DKIM-селекторы. Ему нужно понимать, что делать, когда клиент говорит «не получил». Администратору или интегратору нужны технические детали: заголовки, логи, статусы проверок.

Для менеджера достаточно простого правила в интерфейсе: если клиент говорит, что письма нет, — не отправлять повторно с личной почты и не просить клиента «посмотреть в спам» как единственное действие. Вместо этого — зафиксировать факт, взять у клиента или из системы заголовки письма, если оно дошло хотя бы до кого-то, и передать администратору. Хорошо, если в CRM есть поле «статус доставки» с честной формулировкой: «принято сервером отправки», а не «доставлено». Это мелочь, но она снимает половину ложных ожиданий.

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

Что касается инструментов, то здесь каждый выбирает под свою задачу. Кто-то держит контент-процессы в одном месте — например, контент-завод для бизнеса вроде Киры помогает с производством материалов, — но настройка домена отправки остаётся отдельной технической задачей, которую нельзя закрыть контентным инструментом. Речевая аналитика или ИИ-тренер сотрудников тоже не решают вопрос аутентификации почты: это разные слои. Не стоит ждать, что один сервис закроет всё.

Как проверить домен отправки: пошаговый практикум

Разберём практикум на другом примере, чтобы не повторять арифметику из начала. Условная компания продаёт оборудование и шлёт из CRM три типа писем: подтверждение заказа, счёт и уведомление о готовности к отгрузке. Адрес отправителя — orders@shop.example.ru, поддомен shop. Основной домен example.ru настроен давно, а про поддомен никто не думал.

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

Шаг второй — проверка записей. Для shop.example.ru посмотрите SPF-запись: есть ли в ней сервер сервиса отправки. Посмотрите, опубликован ли DKIM-ключ для селектора, которым подписывает сервис. Если для поддомена записей нет вообще — это первое, что надо исправить.

Шаг третий — проверка на реальных письмах. Отправьте по одному письму каждого типа на несколько внешних адресов у разных провайдеров. Получите заголовки и посмотрите результаты SPF, DKIM и DMARC. Не «пришло/не пришло», а именно строки проверок. Если что-то не сходится — вернитесь к шагу два.

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

Шаг пятый — закрепление. Заполните карточку домена, назначьте ответственного и периодичность проверки. Договоритесь, что при смене сервиса отправки или подрядчика по сайту карточка обновляется. Это самая скучная часть, но именно она предотвращает повторение истории из первого эпизода.

Проверка почтового домена: когда стандартная схема не срабатывает

Есть случаи, где простая схема «настроил записи — и всё хорошо» даёт сбой. Первый — несколько сервисов отправки одновременно. Компания шлёт письма из CRM, из сервиса рассылок и из корпоративной почты, и у каждого свой набор серверов. SPF-запись должна включать все, но у SPF есть ограничение на количество механизмов и DNS-запросов; если сервисов много, запись может стать слишком длинной или превысить лимит. Тогда часть серверов придётся вынести на отдельные поддомены — и это уже архитектурное решение, а не правка одной строки.

Второй случай — сторонние сервисы, которые шлют письма от имени вашего домена без вашего ведома. Например, какая-то форма на сайте или старый плагин. Такие отправители всплывают в DMARC-отчётах как неожиданные источники. Их надо либо легализовать (добавить в разрешённые), либо отключить. Гадать тут бессмысленно — нужны отчёты.

Третий случай — смена провайдера DNS. При переезде зоны записи могут потеряться или скопироваться не полностью. После переезда проверку надо делать заново, даже если «ничего не меняли». Четвёртый — корпоративная почта сотрудников, которая шлёт от имени того же домена, что и CRM. Если сотрудники шлют через один сервер, а CRM через другой, оба должны быть в SPF, а подписи — сходиться у обоих.

Во всех этих случаях универсального рецепта нет, и это нормально. Важно не притворяться, что стандартная схема покрывает всё, а иметь процедуру разбора: собрать факты, посмотреть заголовки и отчёты, зафиксировать вывод в карточке.

Что не стоит обещать себе и клиентам

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

То же касается сроков и «процентов доставляемости». Числа без замера — это фантазия. Если хотите что-то измерять, измеряйте конкретное: долю писем, у которых в заголовках сходятся все три проверки, по выборке реальных отправок. Это скромный, но честный показатель, и он напрямую связан с тем, что вы контролируете.

И последнее: не превращайте настройку домена в разовую акцию. Сервисы меняются, ключи ротируются, подрядчики уходят. Карточка домена и регулярная проверка — это не бюрократия, а способ не оказаться в ситуации, когда полгода никто не смотрел, а письма тихо не доходили.

Один шаг, с которого стоит начать

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

Этот шаг занимает меньше часа и сразу отделяет проблему домена от всех остальных. Дальше — по обстоятельствам: карточка, инвентаризация, политика. Но начать стоит именно с факта, а не с предположения.

Смежный вопрос разобран отдельно: Email-маркетинг с ИИ-агентами: цепочка, которая понимает задачу.