Служебные заголовки в письмах нужны для защиты от мошенников, которые могут рассылать спам от чужого имени. Настройку таких заголовков называют email-аутентификацией, без неё не получится отправлять массовые рассылки через платформы рассылок.
С 2024 года требования к аутентификации ужесточились: Google и Yahoo начали отклонять письма от отправителей без настроенных DKIM, SPF и DMARC, а с мая 2025 года к ним присоединился Microsoft. Эти требования касаются компаний, которые отправляют более 5 тысяч писем в день.
В статье расскажем, как именно заголовки влияют на доставляемость и как их настроить.
Зачем нужны служебные заголовки в рассылке
У каждого письма есть видимая часть (тема, текст, изображения) и скрытая, техническая. Служебные технические заголовки — это как раз скрытая часть. В них хранится информация о том, кто и откуда отправил письмо, через какой почтовый сервер оно прошло и можно ли доверять отправителю. На основе этих данных почтовик решает, доставить письмо во «Входящие», отправить в спам или заблокировать совсем.
Заголовки нужны, чтобы почтовый сервер мог проверить, что:
- письма действительно отправлены от имени отправителя;
- по пути письмо не перехватили мошенники и не подставили своё содержание (это называется фишингом).
Если компания отправляет пару сотен писем в день, то настраивать технические заголовки необязательно. В этом случае у серверов не возникает сомнений, что рассылка отправлена легитимным отправителем.
Но при работе через платформу email-рассылок между отправителем и получателем появляется дополнительное звено. В этом случае отправителем является компания — инициатор рассылки, но технически сообщения приходит с адреса сервиса рассылок.
У почтового сервера возникает справедливый вопрос, не перехватили ли письмо. Поэтому важно настроить служебные заголовки email, где будет подтверждение, что платформе рассылок можно доверять.
Есть три важных протокола проверки, которые отражаются в служебных заголовках: SPF, DKIM и DMARC. Разберём их подробнее.
DKIM-подпись
Domain Keys Identified Mail, или идентификация письма по ключу домена, — это зашифрованная подпись, по которой можно понять, не было ли изменено электронное письмо в процессе доставки и есть ли у этого домена право отправлять рассылки. По сути, DKIM работает как водяной знак на банкнотах.
Метод проверки строится на паре ключей шифрования:
- приватный ключ хранится в платформе email-рассылок;
- публичный размещается в DNS-записи домена.
При отправке платформа рассылок создаёт DKIM-подпись с помощью приватного ключа и добавляет её в технический заголовок письма. Почтовый сервер получателя берёт публичный ключ из DNS и проверяет подпись на подлинность.
Если проверка прошла успешно, письмо попадает в почтовый ящик получателя. Если нет, то письмо либо не придёт вовсе, либо с пометкой «возможно мошенничество, мы не можем проверить подлинность отправителя» — зависит от DMARC-политики, о которой расскажем ниже.
Как правило, платформы email-рассылки помогают клиентам с настройкой DKIM. Но если компания отправляет письма самостоятельно, то создание цифровых подписей остаётся на её стороне.
Также, если у компании несколько доменов, стоит выделить для рассылок одно доменное имя. Например, mail.site.ru или site.mail. Так будет проще, потому что для каждого доменного имени все служебные заголовки нужно настраивать отдельно.
SPF-запись
Sender Policy Framework, или инфраструктура политики отправителя — с её помощью сервер узнаёт, кто имеет право на отправку писем от имени домена.
По сути, SPF — это список доменов и IP-адресов, с которых могут отправляться рассылки компании. При получении письма сервер отслеживает адрес отправителя, затем заглядывает в SPF и проверяет, есть ли там этот адрес. Если всё совпадает, сообщение отправляется получателю.
Главная задача SPF — подтверждение отправителя. Это важно для репутации домена: чем она выше, тем меньше шансов, что письма попадут в спам.
Важно понимать: под адресом отправителя в этом случае понимается не то, что видит получатель в своём ящике. Речь идёт про Return-Path — технический обратный адрес, с которого уходят письма. Он может отличаться от адреса в сообщении.
Например, компания работает через инструмент рассылок в CDP Sendsay и служебные заголовки в письмах не настроены, все рассылки будут с адреса mail.sendsay.ru. Получатель увидит домен компании, но технически письмо будет отправлено с адреса платформы.
При этом некоторые почтовые сервисы сообщают об этом подписчику. Например, в интерфейсе почты Google появляется надпись, что сообщение, отправлено через mail.sendsay.ru. Это никак не влияет на доставляемость рассылки, но может повлиять на репутацию компании-отправителя.
Для самостоятельного подключения SPF-записи нужно зайти в настройки домена и на странице редактирования DNS-настроек добавьте новую запись с типом TXT или использовать уже существующую. В параметрах записи в поле «Name» нужно указать полное имя домена с точкой в конце, а в поле Text — запись v=spf1 include:spf.sendsay.ru ~all, где вместо sendsay.ru указать домен платформы рассылок.
Подробнее о настройках служебных заголовков письма в разных почтовых сервисах можно посмотреть в официальной информации от Google, Яндекса и Mail.ru.
DMARC-политика
Domain-based Message Authentication, Reporting and Conformance — это политика, которая объясняет почтовому серверу, что делать с письмами, не прошедшими проверку SPF и DKIM.
Если предыдущие два протокола нужны, чтобы рассылка прошла проверку на подлинность, то DMARC объясняет, что нужно делать с письмами, которые эту проверку не прошли.
Также при настройке DMARC нужно указать адрес для ежедневных отчётов с результатами проверки всех адресов, с которых отправлялись сообщения от имени домена.
В DMARC-политике есть три варианта действий с подозрительными письмами:
- reject — отклонить;
- quarantine — отправить в папку «Спам»;
- none — пропустить в почтовые ящики.
Можно включить строгую политику reject и запретить доставку подобных писем. Но мы не советуем так делать: из-за этого могут заблокироваться рассылки из CRM-системы. Также письма нельзя будет пересылать.
В отчётах стоит отслеживать подозрительные IP-адреса. Если они появляются, можно временно ужесточить политику, чтобы защитить получателей от мошенников.
Для самостоятельной настройки DMARC-политики нужно перейти в настройки домена и создать следующую TXT-запись:
_dmarc.site.ru TXT "v=DMARC1; p=none; rua=mailto:postmaster@your.tld"
где site.ru — домен компании, p — тип политики: none, quarantine или reject, rua — почтовый адрес для ежедневных отчётов.
Какие ошибки допускают при настройке
Даже если DKIM, SPF и DMARC настроены, письма всё равно могут попадать в спам. Вот самые распространённые ошибки, которые к этому приводят.
Настроить не все протоколы. Некоторые отправители ограничиваются одним из двух протоколов. Но почтовые серверы проверяют оба: DKIM подтверждает целостность письма, а SPF — право сервера на отправку. Без любого из них DMARC-проверка может не пройти.
Оставить стандартный Return-Path. Если технический обратный адрес (Return-Path) не совпадает с доменом в поле «От кого», DMARC не пройдёт проверку по SPF. Чтобы этого избежать, стоит настроить собственный Return-Path на домене отправителя.
Отправлять с бесплатного ящика. Массовые рассылки с адресов на @gmail.com, @mail.ru или @yandex.ru в большинстве случаев не пройдут аутентификацию. Почтовые провайдеры запрещают использовать такие ящики для рассылок — нужно создать собственный с уникальным доменом.
Не добавить List-Unsubscribe. С июня 2024 года Google и Yahoo требуют от отправителей добавлять заголовок List-Unsubscribe, который позволяет получателю отписаться от рассылки из интерфейса почты. Без этого заголовка письма могут быть заблокированы. Платформы рассылок (например, CDP Sendsay) добавляют его автоматически.
Не согласовать домены. Если в поле «От кого» домен отличный от указанного в DKIM или SPF, DMARC расценит это как несовпадение. Нужно указать все адреса отправителя.
Как проверить служебные заголовки письма
Проще всего открыть исходный код любого сообщения: в нём видны все технические заголовки, включая результаты проверки DKIM, SPF и DMARC.
В Gmail для этого нужно открыть письмо, нажать на три точки рядом с кнопкой ответа и выбрать «Показать оригинал». В Яндекс Почте — «Свойства письма», в Mail.ru — «Служебные заголовки».
Для анализа служебных заголовков домена без отправки письма есть специальные сервисы. MxToolbox проверяет SPF, DKIM и DMARC прямо по доменному имени. А EasyDMARC показывает подробный отчёт с рекомендациями по исправлению.
Что запомнить о технических заголовках
- Служебные заголовки — это скрытая техническая часть письма, по которой почтовый сервер решает, доверять отправителю или нет.
- Три обязательных протокола для настройки, которые отображаются в служебных заголовках: DKIM подтверждает целостность письма, SPF — право сервера на отправку, DMARC — задаёт правила действий при неудачной проверке.
- Многие почтовики требуют от массовых отправителей настройку всех трёх протоколов. Без них письма могут быть заблокированы.
- Return-Path и домен в поле «От кого» должны быть согласованы, иначе письмо не пройдёт проверку.
- Для массовых рассылок также обязателен List-Unsubscribe и кнопка отписки в один клик.
- Проверить настройку заголовков можно через MxToolbox или аналогичные сервисы: они покажут ошибки в записях домена.
Ответы на частые вопросы
