Письма компании попадают в спам, когда принимающий сервер не может убедиться, что домен в поле «От» действительно отправил это сообщение. Три записи в DNS закрывают вопрос: SPF перечисляет серверы, которым разрешено отправлять почту от вашего имени, DKIM ставит на письмо цифровую подпись, а DMARC сообщает получателю, что делать с письмами, не прошедшими проверку.
Типичная картина выглядит так. Менеджер пишет клиенту с адреса info@вашкомпания.kz, письмо уходит без ошибок, но клиент его не видит. Через неделю выясняется, что сообщение лежало в папке «Спам», а счет остался неоплаченным. Одновременно сайт отправляет уведомления о заявках, CRM рассылает напоминания, бухгалтерия шлет документы из отдельного сервиса. У каждого источника свой сервер, и почтовый провайдер получателя должен понять, кому из них можно доверять. На проектах B2BPRO.KZ мы чаще всего видим именно эту ситуацию: ящик настроен, а домен ни разу не проверяли на корректность этих трех записей.
Что такое SPF, DKIM и DMARC простыми словами
SPF (Sender Policy Framework) — это TXT-запись в DNS домена со списком серверов и сервисов, которым разрешено отправлять почту с этого домена. Получатель смотрит на адрес отправителя, находит запись и сверяет IP-адрес сервера, откуда пришло письмо, со списком. Если IP в списке, проверка пройдена.
DKIM (DomainKeys Identified Mail) — это механизм цифровой подписи письма. Отправляющий сервер подписывает заголовки и тело закрытым ключом, а открытый ключ лежит в DNS домена. Получатель берет открытый ключ, проверяет подпись и убеждается, что письмо не изменили по дороге и что его действительно отправил владелец домена.
DMARC (Domain-based Message Authentication, Reporting and Conformance) — это политика домена, которая опирается на результаты SPF и DKIM. Запись DMARC говорит получателю, что делать с письмом, не прошедшим проверку: доставить, отправить в спам или отклонить. Кроме того, DMARC присылает владельцу домена отчеты о том, кто и сколько писем отправил от его имени.
Удобная аналогия: SPF похож на список сотрудников у охраны, DKIM на печать на конверте, а DMARC на инструкцию, как поступать с посылкой, если в списке имени нет или печать поддельная.
Почему письма уходят в спам без этих записей
Без SPF, DKIM и DMARC любой человек может написать письмо от имени вашего домена, поэтому крупные почтовые сервисы относятся к неаутентифицированной почте с подозрением. Для массовых отправителей это уже формальное требование. По справке Google, с 1 февраля 2024 года отправители, которые рассылают на Gmail более 5000 писем в сутки, обязаны настроить SPF и DKIM, опубликовать запись DMARC и держать долю жалоб на спам в Postmaster Tools ниже 0,30%. Google рекомендует держаться ниже 0,10%. Подробности есть в справке Google о требованиях к отправителям.
Небольшая компания, которая пишет клиентам несколько десятков писем в день, под формальный порог не попадает. Но алгоритмы фильтрации оценивают любое письмо по тем же признакам. Если подписи нет, SPF не проходит, а домен получателя ни разу не видел ваших писем, вероятность спама растет. Особенно это заметно в корпоративных ящиках, где администраторы выставили строгие правила,.
Из чего состоит корректная настройка домена для почты
Корректная настройка домена состоит из трех TXT-записей в DNS и согласованной работы всех сервисов, которые отправляют письма от вашего имени. Ниже сводная таблица: где находится каждая запись и за что отвечает.
| Запись | Где лежит в DNS | Что проверяет | Пример |
|---|---|---|---|
| SPF | TXT на корне домена | Разрешен ли отправляющий сервер | v=spf1 include:_spf.google.com ~all |
| DKIM | TXT на селекторе, например selector._domainkey | Подпись письма и его целостность | v=DKIM1; k=rsa; p=… |
| DMARC | TXT на _dmarc | Совпадение домена и политика при сбое | v=DMARC1; p=none; rua=mailto:… |
Значения в колонке «Пример» приведены для иллюстрации. Реальные записи вы получаете в панели своего почтового провайдера: Google Workspace, Яндекс 360, Mail.ru для бизнеса или хостинга, где размещена почта.
Как настроить SPF и не превысить лимит
SPF настраивается одной TXT-записью на корне домена, и в ней должны быть перечислены все сервисы, которые отправляют почту от вашего имени. Для компании, которая использует только Google Workspace, по справке Google запись выглядит так: v=spf1 include:_spf.google.com ~all. Google рекомендует завершать ее квалификатором ~all. Подробности описаны в справке Google по настройке SPF, там же сказано, что изменения могут вступать в силу до 48 часов.
Если почтой пользуется несколько сервисов, их include добавляются в одну запись: например, корпоративный ящик, сервис рассылок и CRM. Две отдельные SPF-записи на одном домене создавать нельзя: получатель такую конфигурацию считает ошибочной, поэтому все источники нужно собрать в одной строке.
Главная ловушка SPF — лимит на число DNS-запросов. Стандарт RFC 7208, раздел 4.6.4 требует ограничить число обращений к DNS при проверке десятью: считаются механизмы include, a, mx, ptr, exists и модификатор redirect. Если лимит превышен, результат проверки — permerror, то есть SPF считается нерабочим. Такое случается, когда за несколько лет к домену подключили пять-шесть сервисов, и у каждого свой include, внутри которого лежат еще вложенные записи. Лишние сервисы стоит удалить из записи, а вместо мертвых include оставить только действующие.
Различие между ~all и -all такое: первый вариант (softfail) говорит получателю считать письма с неизвестных серверов подозрительными, второй (fail) просит отклонять их. Для начала разумно оставить ~all, а ужесточать после того, как вы убедились, что все легитимные источники учтены.
Как настроить DKIM
DKIM включается в панели почтового провайдера: система генерирует пару ключей, а вам выдает TXT-запись с открытым ключом, которую нужно добавить в DNS. Google рекомендует ключ длиной 2048 бит, минимально допустимый для массовых отправителей — 1024 бита. После добавления записи в панели нужно нажать кнопку включения подписи, иначе ключ в DNS есть, а письма никто не подписывает.
У каждого сервиса, который отправляет почту от вашего домена, должна быть своя подпись. Корпоративная почта подписывает письма одним ключом, сервис рассылок другим, форма на сайте через SMTP-плагин может использовать собственную подпись провайдера. Если подписи нет, письмо все равно может пройти SPF, но для DMARC этого иногда недостаточно: проверка требует совпадения домена в поле «От» с доменом SPF или DKIM, и надежнее всего иметь оба механизма.
Частая ошибка — перенос DNS. Когда компания меняет хостинг или регистратора и забывает скопировать записи с селекторами DKIM, подпись пропадает, и письма резко начинают попадать в спам. Перед переносом домена выгрузите все TXT-записи и сравните список после смены серверов имен.
Как включить DMARC без риска потерять письма
DMARC включается TXT-записью на хосте _dmarc.вашдомен, и начинать нужно с мягкой политики p=none. По справке Google, перед включением DMARC нужно настроить SPF или DKIM и подождать до 48 часов. Политика none доставляет письма как обычно и присылает ежедневные отчеты, quarantine отправляет проблемные письма в спам, а reject отклоняет их. Google рекомендует начинать с none и ужесточать политику по мере подтверждения корректной аутентификации. Все детали собраны в справке Google по настройке DMARC.
Минимальная стартовая запись выглядит так: v=DMARC1; p=none; rua=mailto:dmarc@вашдомен.kz. Тег rua указывает адрес, куда приходят сводные отчеты. Google рекомендует всегда его указывать, адрес записывается с префиксом mailto:. Пара практических замечаний: теги v и p должны стоять первыми, а ящик для отчетов лучше создать отдельный, потому что отчеты приходят в формате XML и забивают рабочую почту.
Порядок перехода к строгой политике такой:
- Опубликуйте запись с
p=noneи адресом для отчетов. - Две-четыре недели читайте отчеты и составьте список всех источников, которые отправляют почту от вашего домена.
- Для каждого легитимного источника настройте SPF и DKIM, чтобы он проходил проверку.
- Переключите политику на
p=quarantineи понаблюдайте за доставкой. - Когда нарушений нет, переходите на
p=reject, если нужна полная защита домена от подделки.
Спешка здесь вредна. Если сразу поставить reject, а, например, система выставления счетов отправляет письма без DKIM, они начнут отклоняться, и вы узнаете об этом от клиентов.
Как проверить, что письма не уходят в спам
Проверка занимает минут десять и не требует специальных инструментов. Сначала посмотрите записи в DNS: любой сервис проверки DNS или команда nslookup -type=TXT вашдомен.kz покажет SPF, а запрос по адресу _dmarc.вашдомен.kz покажет DMARC. Для DKIM нужно знать селектор, он указан в панели провайдера.
Затем отправьте тестовое письмо на личный ящик в Gmail, откройте его и выберите пункт «Показать оригинал». В заголовке будут строки SPF: PASS, DKIM: PASS и DMARC: PASS. Если вместо PASS стоит FAIL или NEUTRAL, причина именно в этой записи. Проверку нужно повторить с каждого источника: с корпоративной почты, с формы на сайте, из CRM, из сервиса рассылок. Один успешный тест не говорит об остальных.
Для регулярного контроля удобно подключить Google Postmaster Tools, если вы отправляете на Gmail заметный объем писем: там видна репутация домена и доля жалоб на спам. А отчеты DMARC помогают найти сервисы, о которых вы забыли: старый CRM, тестовый сайт, рассылку, оставшуюся от прежнего подрядчика.
Почему письма с сайта WordPress чаще всего страдают первыми
Письма с сайта WordPress страдают чаще остальных, потому что по умолчанию их отправляет функция PHP на сервере хостинга, а не ваш почтовый провайдер. Адрес в поле «От» принадлежит вашему домену, а IP-адрес сервера в SPF не указан и подписи DKIM нет. Для получателя это почти классическая подделка.
Решение проверенное: подключить SMTP-плагин и отправлять уведомления через тот же почтовый сервис, что и обычные письма. Пошаговый разбор есть в нашей статье про SMTP на WordPress и проверку доставки. Если заявки с формы важны для продаж, настройку доставки лучше закладывать на этапе создания сайта, и именно так мы поступаем при разработке сайтов под ключ.
Похожий механизм есть и в других системах. Те же записи нужны, если вы хотите, чтобы почта из CRM или корпоративного портала доходила без потерь. Проблему уведомлений мы разбирали в материале о том, почему перестают приходить письма из Битрикс24.
Пример: как выглядит ошибка в реальной компании
Ниже иллюстративный пример, а не описание конкретного клиента. Оптовая компания в Алматы использует Google Workspace для сотрудников, отдельный сервис для рассылки прайс-листов и форму заявки на сайте. SPF в домене написан в 2019 году и содержит только старый хостинг. Менеджеры жалуются, что часть клиентов не получает коммерческие предложения.
Диагностика показывает три проблемы. Во-первых, в SPF нет Google, поэтому письма сотрудников проходят проверку только благодаря DKIM. Во-вторых, сервис рассылки подписывает письма собственным доменом, а не доменом компании, и DMARC на него не распространяется. В-третьих, записи DMARC нет вовсе, так что никто не знает, сколько писем уходит от имени домена.
Исправление занимает один рабочий день. В SPF добавляют актуальные сервисы и убирают старый хостинг, в панели сервиса рассылки подключают подпись собственного домена, а в DNS публикуют DMARC с политикой none. Через две недели по отчетам видно все источники, и политику можно ужесточать. Именно такая последовательность не ломает работающую почту.
Чек-лист для руководителя и администратора
Чтобы быстро оценить состояние домена, пройдите по списку:
- В DNS есть ровно одна запись SPF, и в ней учтены все источники писем.
- Число обращений к DNS в SPF не превышает десяти.
- DKIM включен для корпоративной почты и для каждого стороннего сервиса.
- Запись DMARC опубликована, адрес для отчетов указан.
- Тестовое письмо в Gmail показывает PASS по всем трем проверкам.
- Письма с сайта идут через SMTP, а не через стандартную функцию хостинга.
- При смене хостинга или регистратора список TXT-записей сохранен и перенесен.
Если домен вам не принадлежит технически, например доступ к DNS остался у прежнего подрядчика, начните с получения доступа. Без него ни одну запись не изменить. Если вы не уверены, кто управляет DNS, посмотрите регистратора домена в публичном реестре и запросите доступ у него.
Чем SPF отличается от DKIM и зачем нужен DMARC, если есть обе записи
SPF проверяет сервер, а DKIM проверяет само письмо, поэтому они закрывают разные сценарии. SPF привязан к IP-адресу отправителя и ломается при пересылке: если сотрудник перенаправил письмо на другой ящик, пересылающий сервер в SPF не указан. Подпись DKIM при пересылке сохраняется, пока никто не изменил тело письма и заголовки. Поэтому надежной считается связка из обоих механизмов.
DMARC добавляет к ним то, чего нет ни у одной из записей по отдельности: проверку совпадения домена. По справке Google, для прямых писем домен в поле «От» должен совпадать с доменом SPF или с доменом DKIM. Без этого злоумышленник мог бы пройти SPF со своего домена и подставить в видимое поле «От» ваш. Второй вклад DMARC — обратная связь: вы впервые видите, какие сервисы пишут от вашего имени, включая те, о которых никто не помнит.
Какие ошибки в настройке встречаются чаще всего
Чаще всего ошибки сводятся к четырем сценариям, и каждый проверяется за несколько минут.
- Две записи SPF на одном домене. Обычно вторую добавляет новый подрядчик, не заглянув в уже существующую. Решение: объединить в одну строку.
- Ключ DKIM добавлен в DNS, но подпись не включена в панели провайдера. Записи вроде бы есть, а заголовок в письме показывает отсутствие подписи.
- В записи DMARC указан адрес отчетов с опечаткой или без префикса
mailto:. Политика работает, а отчетов нет, и вы действуете вслепую. - Запись опубликована не на том хосте. Для DMARC нужен именно
_dmarcперед доменом, для DKIM — селектор и_domainkey. Ошибка в одном символе делает запись невидимой для получателя.
Отдельно стоит упомянуть поддомены. По справке Google, каждому домену нужна собственная запись SPF, и поддомены тоже нуждаются в своих записях. Если рассылки отправляются с поддомена вроде mail.вашдомен.kz, настройку нужно проверить именно на нем, а не только на основном домене.
Кому поручить настройку и что делать, если письма уже в спаме
Настройку обычно делает системный администратор или подрядчик, который ведет сайт и DNS. Если у компании нет ни того ни другого, этот объем работы небольшой: для одного домена и двух-трех источников почты хватает одного рабочего дня вместе с тестированием. Сложнее становится, когда источников много, а доступы разбросаны между регистратором, хостингом и почтовым провайдером.
Если письма уже уходят в спам, порядок действий такой: сначала убедитесь, что все три проверки в тестовом письме показывают PASS, затем исправьте то, что показывает FAIL, и только потом разбирайтесь с содержанием писем и частотой рассылок. Репутация домена восстанавливается не мгновенно, поэтому первые результаты видны через несколько дней после правок, а не через час.
Частые вопросы
Нужны ли SPF, DKIM и DMARC маленькой компании?
Да, нужны любой компании, которая пишет клиентам с корпоративного домена. Формальные требования Google касаются отправителей с объемом свыше 5000 писем в сутки, но фильтры спама оценивают аутентификацию в каждом письме. Три записи настраиваются за пару часов и снижают риск того, что коммерческое предложение попадет в спам.
Сколько ждать после изменения записей в DNS?
Google указывает, что SPF может начать работать в течение 48 часов, а перед включением DMARC рекомендует выждать до 48 часов после настройки SPF или DKIM. На практике записи обычно применяются быстрее, но проверять результат лучше через день, а не сразу после правки.
Можно ли сразу поставить DMARC с политикой reject?
Можно, но рискованно. Если какой-то легитимный сервис отправляет письма без SPF и DKIM, они начнут отклоняться. Google рекомендует начинать с p=none, изучить отчеты и только затем переходить к quarantine или reject. Спешка в этом деле обходится дороже, чем лишняя неделя наблюдения.
Что будет, если в SPF больше десяти include?
SPF перестанет работать. По стандарту RFC 7208 число обращений к DNS при проверке ограничено десятью, а при превышении результатом становится permerror. Письма после этого идут без успешного SPF, и все зависит от DKIM и репутации домена. Решение: убрать лишние сервисы и устаревшие include.
Как узнать, что письма попали в спам именно из-за настроек домена?
Отправьте тестовое письмо на Gmail и откройте «Показать оригинал»: там видно результат SPF, DKIM и DMARC. Если везде PASS, а письмо все равно в спаме, причина в содержании, репутации домена или массовой рассылке без отписки. Если стоит FAIL, ошибка в соответствующей записи.