Электронная почта работает на протоколе SMTP с 1982 года, и встроенной проверки отправителя в нём нет: поле From заполняет тот, кто отправляет письмо, и указать там можно почти любой адрес. Поверх этого выросли три механизма — SPF, DKIM и DMARC. Пётр Пахомов, продуктовый менеджер CDP Sendsay, разбирает их на аналогии с бумажным письмом: конверт с надписью «От кого», список доверенных курьеров, сургучная печать и помощник директора, который сверяет одно с другим.

Ключевой вывод его разбора: результаты spf=pass и dkim=pass сами по себе не дают dmarc=pass. Приёмный сервер смотрит не только на то, прошли ли проверки, но и на то, какой домен они подтверждают. Эта деталь касается каждого, кто рассылает письма через внешнюю платформу: домен принадлежит компании, а часть почтовой инфраструктуры живёт на стороне сервиса.

SPF проверяет сервер отправки

SPF (Sender Policy Framework) — это TXT-запись в DNS, которая перечисляет серверы, имеющие право отправлять почту от имени технического домена. Выглядит она примерно так: v=spf1 include:spf.provider-name.ru ~all. Когда приходит письмо, приёмный сервер читает запись и сравнивает IP отправителя со списком. Совпадение даёт spf=pass; при модификаторе ~all отсутствие в списке даёт spf=softfail.

Сравнивается при этом IP отправителя и домен из служебного поля Mail From — технического обратного адреса вида bounce@mail.romashka.ru, куда почтовые серверы шлют уведомления о недоставке. Адрес из поля From, который видит получатель, в SPF-проверке не участвует: к этому моменту тело письма ещё не передано, серверу хватает данных SMTP-сеанса. Поэтому SPF ничего не знает о том, менялось ли письмо в пути.

DKIM подтверждает, что подписанные части не тронули

DKIM (DomainKeys Identified Mail) добавляет в заголовки письма криптографическую подпись, построенную на закрытом ключе. Приёмный сервер берёт из заголовка DKIM-Signature домен d= и селектор s=, находит по адресу <селектор>._domainkey.<домен> открытый ключ в DNS и проверяет подпись. Если подписанные части письма изменились — например, кто-то заменил ссылку http://romashka.ru на http://romashka-security.ru, — подпись перестаёт соответствовать письму, и результат становится dkim=fail.

Закрытый ключ остаётся у владельца домена или у сервиса, которому доверена отправка; без него корректную подпись собрать нельзя. Но и здесь есть зазор: платформа рассылок может подписать письмо своим техническим доменом, и тогда dkim=pass header.d=provider.ru подтверждает provider.ru, а не тот домен, что стоит в поле From.

Где рвётся связка: выравнивание доменов

Оба механизма могут отработать успешно и всё равно подтвердить чужой домен. Пользователь видит From: news@romashka.ru, а Mail From указывает на bounce@provider.ru, для которого SPF настроен корректно. Проверка проходит и подтверждает provider.ru.

DMARC (Domain-based Message Authentication, Reporting and Conformance) закрывает именно этот разрыв. Он не выполняет SPF и DKIM заново и не требует, чтобы прошли обе проверки. Он берёт домен из видимого From и задаёт два вопроса: прошёл ли SPF и связан ли проверенный им домен с доменом из From; прошёл ли DKIM и связан ли домен подписи с доменом из From. Хотя бы одно «да» — DMARC пройден.

Эта связь называется alignment, выравнивание доменов. Оно бывает мягким (relaxed), когда домены относятся к одному организационному домену и поддомен mail.romashka.ru считается связанным с romashka.ru, и строгим (strict), когда домены должны совпадать точно. Режимы задаются тегами aspf и adkim, по умолчанию оба relaxed. В записи v=DMARC1; p=none; adkim=s; aspf=r для DKIM включён строгий режим: при d=mail.romashka.ru и From: promo@romashka.ru результат dkim=pass не пройдёт DMARC, потому что домены не совпадают точно.

Политика обработки и отчёты

Что делать с письмом, которое провалило DMARC, задаёт параметр p в записи _dmarc.romashka.ru. Значений три. p=none — проверять и фиксировать результат, но не применять специальных мер; режим для этапа внедрения, когда почта уходит из нескольких мест: CRM, корпоративная почта, система поддержки, платформа рассылок. p=quarantine — относиться к неподтверждённому письму как к подозрительному, на практике это папка «Спам». p=reject — отклонять такие письма на этапе приёма; этот режим защищает домен от прямого спуфинга, но при одном легитимном источнике с неверной настройкой под блокировку попадут собственные письма.

Слово Reporting в названии отвечает за параметр rua: v=DMARC1; p=none; rua=mailto:dmarc-reports@romashka.ru. На этот адрес приёмные серверы шлют агрегированные отчёты — по ним видно, какие источники отправляют почту от имени домена и как проходят проверки. Частая находка в таких отчётах: отдел продаж подключил собственную CRM, поддержка завела отдельный сервис рассылок, а про старый SMTP-сервер никто не вспомнил.

Поддомен для рассылок и его делегирование

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

Отсюда практика выделять под рассылки отдельный поддомен mail.romashka.ru и делегировать его DNS-зону платформе. Технически это несколько NS-записей: mail.romashka.ru NS ns1.provider.ru и далее по списку серверов платформы. После этого за записи внутри mail.romashka.ru отвечает платформа, а основной romashka.ru с сайтом и корпоративной почтой остаётся под контролем компании. Получатель по-прежнему видит From: promo@romashka.ru, а ошибки доставки уходят на bounce@mail.romashka.ru.

Делегирование не влияет на репутацию домена и не открывает письмам путь во «Входящие». Значения spf=pass, dkim=pass и dmarc=pass подтверждают только техническую подлинность письма; на попадание в нужную папку влияют репутация отправителя, история отправок и жалобы получателей. Делегирование меняет одно: кто создаёт и поддерживает записи.

Что проверить у себя

Отправная точка — один вопрос: сходится ли домен из From с тем, что подтверждают SPF и DKIM для ваших реальных рассылок. Если письма уходят через внешнюю платформу, посмотрите, чьим доменом подписано письмо и какой домен стоит в Mail From. Затем включите p=none с параметром rua и пару недель почитайте отчёты — они покажут все источники почты от имени домена до того, как строгая политика начнёт отклонять что-то нужное.