Настройка домена для рассылок: SPF, DKIM и DMARC

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

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

Что такое SPF, DKIM и DMARC

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

SPF помогает бороться с подделкой отправителя, но не является полной защитой. Запись проверяет сервер, с которого отправлено письмо, однако не подтверждает неизменность его содержимого. Кроме того, SPF имеет ограничение в десять DNS-запросов при обработке записи. Слишком большое количество подключенных сервисов может привести к ошибке проверки.

DKIM добавляет к каждому письму цифровую подпись. Почтовый сервис создает закрытый ключ, а открытый ключ публикуется в DNS домена. Сервер получателя использует открытый ключ, чтобы проверить подпись и убедиться, что письмо действительно отправлено авторизованной системой и не изменялось во время доставки.

DKIM-запись размещается не в корне домена, а на специальном поддомене, который называется селектором. Например, адрес записи может выглядеть так: mail._domainkey.example.ru. Конкретный селектор и значение ключа всегда нужно брать в настройках выбранного сервиса email рассылок.

DMARC объединяет результаты SPF и DKIM и задает почтовым серверам правило обработки подозрительных сообщений. В записи можно указать, что делать с письмами, которые не прошли проверку: только собирать статистику, отправлять сообщения в спам или отклонять их.

DMARC также проверяет согласованность домена в технических заголовках письма и адресе отправителя. Это важно для защиты от фишинга, поскольку злоумышленник может подменить видимый адрес, даже если письмо отправлено с другого сервера. Настройку DMARC рекомендуется начинать с режима мониторинга, а ужесточать политику после анализа отчетов.

Как настроить записи

Сначала определите домен, который будет использоваться в поле отправителя, например news.example.ru или example.ru. Для регулярных рассылок желательно применять отдельный поддомен. Это позволяет отделить маркетинговые письма от корпоративной переписки и уменьшить влияние возможных проблем с репутацией рассылочного адреса.

Затем откройте раздел управления DNS. Он может называться «DNS-записи», «Управление зоной», «Редактор зоны» или «Доменные записи». Перед изменениями сохраните текущую конфигурацию и проверьте, где находятся записи: у регистратора, на хостинге или в отдельном DNS-сервисе, например Cloudflare.

Шаг 1. Добавьте SPF. Создайте TXT-запись для корня домена. В поле имени обычно указывают символ @ или оставляют его пустым. В поле значения вставьте строку, предоставленную сервисом рассылок. Упрощенный пример может выглядеть так: v=spf1 include:send.example -all.

Не копируйте этот пример без проверки. Директива include должна соответствовать реальному домену почтовой платформы. Если письма отправляются также из CRM, формы на сайте или другого сервиса, их авторизованные источники нужно добавить в ту же SPF-запись. Для одного домена должна использоваться только одна запись SPF. Несколько TXT-записей с началом v=spf1 могут привести к ошибке PermError.

Параметр ~all означает мягкую политику: сообщения от неизвестных серверов помечаются как подозрительные. Параметр -all задает строгий запрет. На этапе настройки безопаснее использовать значение, рекомендованное сервисом, а переход к строгой политике выполнять после проверки всех источников отправки.

Шаг 2. Добавьте DKIM. В кабинете платформы найдите раздел проверки домена или аутентификации отправителя. Сервис покажет имя TXT-записи и длинное значение открытого ключа. Имя обычно содержит селектор и суффикс ._domainkey. Вставьте данные без изменений, не удаляя кавычки, пробелы или фрагменты ключа, если интерфейс не подставляет их автоматически.

Иногда сервис предлагает создать DKIM в виде CNAME-записи. В этом случае в DNS добавляется адрес, указанный платформой, а сам ключ хранится на стороне сервиса. Не нужно создавать одновременно TXT и CNAME для одного и того же имени: используйте только способ, который указан в инструкции провайдера.

Шаг 3. Добавьте DMARC. Создайте TXT-запись с именем _dmarc. Для первичной настройки подойдет политика мониторинга: v=DMARC1; p=none; rua=mailto:dmarc@example.ru. Здесь rua указывает адрес для агрегированных отчетов. Лучше использовать отдельный почтовый ящик, поскольку отчеты могут приходить регулярно и содержать технические данные в формате XML.

После нескольких дней наблюдения можно изменить политику на p=quarantine, чтобы подозрительные письма отправлялись в спам. Если все легитимные источники проходят проверки, допустимо перейти к p=reject. Для дополнительной защиты применяют параметры adkim и aspf, а также задают процент сообщений, к которым применяется политика, с помощью параметра pct.

DNS-изменения не всегда вступают в силу сразу. Обычно обновление занимает от нескольких минут до суток, но в отдельных случаях может потребоваться больше времени из-за TTL и кэширования записей. Не отправляйте большую кампанию сразу после сохранения DNS: сначала завершите проверку домена в сервисе рассылок.

Проверка и ошибки

После публикации записей откройте в сервисе email рассылок раздел доменной аутентификации и нажмите кнопку проверки. Платформа должна увидеть SPF и DKIM, после чего домен получит статус подтвержденного. Для независимой проверки можно использовать DNS-проверяющие сервисы или команды nslookup и dig. Проверяйте записи через публичные DNS-серверы, например Google или Cloudflare, если локальная панель показывает устаревшие данные.

Одна из частых ошибок SPF — наличие нескольких записей с префиксом v=spf1. Объедините разрешенные источники в одну строку и удалите дубли. Другая проблема — превышение лимита в десять DNS-запросов. Ее решают удалением неиспользуемых сервисов, сокращением цепочек include или использованием механизма, рекомендованного почтовой платформой.

Если не проходит DKIM, проверьте имя записи, селектор и отсутствие лишних пробелов. Часто ошибка возникает, когда DNS-панель автоматически добавляет домен к имени записи. Например, вместо mail._domainkey.example.ru получается повтор: mail._domainkey.example.ru.example.ru. Также убедитесь, что для записи выбран тип TXT, если сервис не требует CNAME.

Ошибка DMARC может быть связана с неправильным адресом для отчетов, синтаксисом или отсутствием согласованности доменов. Не устанавливайте политику reject сразу: при неверной настройке можно заблокировать собственные письма. Сначала изучите отчеты и проверьте все источники отправки, включая транзакционные письма, CRM, формы обратной связи и корпоративные серверы.

Итоговую проверку проводите не только в DNS-сервисе, но и по заголовкам тестового письма. В почтовом клиенте найдите строки Authentication-Results и убедитесь, что SPF, DKIM и DMARC имеют статус pass. Отправьте тесты на несколько почтовых систем и оцените не только прохождение аутентификации, но и попадание во входящие.

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