Короткий ответ: одной записи SPF недостаточно
Чтобы письма компании реже отклонялись из-за проблем аутентификации, а злоумышленникам было сложнее подменять домен, нужно совместно настроить SPF, DKIM и DMARC. SPF перечисляет разрешённые источники отправки, DKIM добавляет к письму проверяемую цифровую подпись, а DMARC связывает результаты этих проверок с доменом в поле «От кого», задаёт политику обработки нарушений и предоставляет отчёты.
Безопасный порядок такой: сначала найти все легитимные сервисы, затем привести в порядок SPF и DKIM, включить DMARC в режиме наблюдения, изучить отчёты и только после этого переходить к карантину или отклонению. Резкое включение строгой политики без инвентаризации может заблокировать полезные письма из CRM, сайта, 1С, службы рассылок или системы уведомлений.
Почему деловое письмо может не дойти
Получатель оценивает не только текст письма. Почтовый сервер проверяет, кто отправил сообщение, согласуется ли источник с доменом, есть ли корректная подпись, как настроены DNS и транспорт, а также репутацию отправителя и характер рассылки. Поэтому письмо с обычным коммерческим предложением может попасть в спам или получить отказ, если техническая аутентификация не настроена или настроена частично.
Обратная проблема — подмена. Злоумышленник указывает в видимом поле адрес вашей компании и просит контрагента заменить реквизиты или открыть файл. Почтовая аутентификация не устраняет все виды фишинга, но помогает принимающей стороне отличить разрешённые источники вашего домена от посторонних. Это защита репутации и рабочего процесса, а не только задача маркетинга.
SPF, DKIM и DMARC решают разные задачи
Механизмы дополняют друг друга. SPF проверяет, разрешён ли серверу отправлять почту для технического домена возврата. DKIM подтверждает, что важные части сообщения подписаны доменным ключом и не были изменены после подписания. DMARC проверяет согласованность домена SPF или DKIM с доменом, который видит получатель в поле «От кого». Для прохождения DMARC достаточно успешной и согласованной проверки SPF или DKIM, но в рабочей конфигурации полезно настроить оба механизма.
| Механизм | Что проверяет | Чего не делает сам по себе |
|---|---|---|
| SPF | Разрешённый источник отправки | Не подписывает содержимое письма |
| DKIM | Доменную подпись и целостность подписанных полей | Не определяет политику для всех сбоев |
| DMARC | Согласованность доменов и результат SPF или DKIM | Не находит забытые легитимные сервисы автоматически |
| Отчёты | Какие источники используют домен и как проходят проверки | Не заменяют анализ и исправление конфигурации |
Шаг 1. Найдите все системы, которые отправляют письма
До изменения DNS составьте реестр отправителей. Помимо основной корпоративной почты, сообщения от домена могут отправлять сайт, CRM, 1С, система заявок, сервис электронных документов, платёжные уведомления, маркетинговая платформа, облачный мониторинг и оборудование. Отдельно проверьте подрядчиков: они нередко используют собственную инфраструктуру, но адрес вашей компании в поле отправителя.
Для каждого источника зафиксируйте владельца процесса, домен в поле «От кого», технический домен возврата, способ DKIM-подписи, тип сообщений и ожидаемый объём. Неизвестный источник нельзя автоматически считать атакой: это может быть забытая форма сайта. Но и добавлять его в разрешения до подтверждения владельца не следует. Реестр станет основой для SPF, ключей DKIM и анализа DMARC-отчётов.
Шаг 2. Соберите один корректный SPF
SPF публикуется как TXT-запись домена и перечисляет разрешённые источники. У домена не должно быть нескольких независимых SPF-записей: их объединяют в одну логическую политику. Добавляйте только подтверждённые почтовые платформы и серверы. Не включайте широкие диапазоны адресов «на всякий случай» и не копируйте чужую запись без понимания её состава.
У SPF есть ограничение на количество DNS-проверок во время вычисления. Длинная цепочка включений может превысить его и привести к постоянной ошибке. Удаляйте старые сервисы, проверяйте вложенные include-механизмы и назначьте ответственного за изменения. Учтите, что обычная пересылка может нарушить SPF: источник письма меняется, а домен возврата остаётся прежним. Поэтому SPF нельзя рассматривать отдельно от DKIM и DMARC.
Шаг 3. Включите DKIM для каждого отправителя
DKIM использует пару ключей. Закрытый ключ хранится у отправляющей системы и подписывает сообщение, а открытый публикуется в DNS под именем селектора. Получатель находит ключ по селектору и домену из подписи и проверяет её. Закрытый ключ нельзя размещать в DNS, документации общего доступа или конфигурации сайта.
Настройте DKIM отдельно в каждой платформе, которая поддерживает отправку от вашего домена. Проверьте, что подписывающий домен согласуется с адресом «От кого», а не принадлежит только поставщику сервиса. Используйте рекомендуемую платформой длину ключа и предусмотрите ротацию: новый селектор можно опубликовать заранее, переключить подпись, проверить доставку и затем убрать старый ключ. Такой переход снижает риск остановки отправки.
Шаг 4. Запустите DMARC с наблюдения
DMARC публикуется в DNS для домена и задаёт три ключевых элемента: политику обработки неуспешных сообщений, правила согласования и адрес для агрегированных отчётов. На первом этапе обычно используют политику наблюдения. Она не просит получателей блокировать сообщения, но позволяет увидеть, какие источники отправляют почту от имени домена и проходят ли они проверки.
Для отчётов заведите контролируемый адрес или специализированный процесс обработки: агрегированные файлы машинные и приходят регулярно. Они показывают источники, объём и результаты SPF, DKIM и DMARC, но не подтверждают законность сервиса сами по себе. Сопоставляйте данные с реестром отправителей. Источник, которого нет в реестре, нужно расследовать; известный источник с ошибкой — исправить.
Шаг 5. Проверьте согласование доменов
Успешный SPF или DKIM ещё не гарантирует прохождение DMARC. Проверяемый домен должен быть согласован с доменом в видимом адресе отправителя. Например, платформа рассылок может корректно авторизовать собственный технический домен, но показывать адрес компании. Без согласованной DKIM-подписи или правильно настроенного домена возврата такое письмо провалит DMARC.
Попросите поставщика описать поддерживаемую схему: пользовательский DKIM, собственный домен возврата, поддомены для отдельных потоков и действия при пересылке. Проверяйте заголовки тестового письма на стороне внешнего получателя, а не только статус «отправлено» в интерфейсе сервиса. Этот статус подтверждает передачу сообщения платформе, но не итоговую аутентификацию.
Разделите рабочую почту и массовые рассылки
Операционные письма сотрудников, чеки, системные уведомления и маркетинговые рассылки имеют разные владельцев, частоту и последствия сбоя. Для управляемости им полезно назначить отдельные поддомены или хотя бы отдельные потоки и DKIM-селекторы. Тогда проблема рекламной кампании не смешивается с доставляемостью счетов и переписки менеджеров.
Разделение не отменяет единых правил бренда и безопасности. Для каждого потока нужны подтверждённые отправители, аутентификация, корректная работа с отказами и понятный процесс остановки. Адрес «не отвечать» не освобождает компанию от требований к подписке и обработке жалоб. Аутентификация подтверждает источник, но не делает нежелательную рассылку полезной для получателя.
Переходите к карантину и отклонению постепенно
Строгая политика DMARC защищает домен только тогда, когда легитимные потоки уже проходят проверку. После периода наблюдения исправьте ошибки, отключите неизвестные и устаревшие источники, проведите тесты с основными почтовыми системами получателей. Затем можно применить карантин к части сообщений и увеличить охват после проверки результатов. Последний этап — политика отклонения для неуспешных сообщений.
Не оценивайте изменение только по общему проценту прохождения. Проверьте критические сценарии: письмо с сайта, счёт из учётной системы, уведомление из CRM, ответ менеджера, восстановление пароля и коммуникацию подрядчика. Для каждого должен быть контрольный получатель и ответственный, который подтвердит не только доставку, но и правильный адрес, подпись и отсутствие предупреждений.
Что проверять после запуска
Почтовая аутентификация требует сопровождения. Новый сервис, смена поставщика, перенос сайта, ротация ключей или забытый тестовый домен меняют картину. Еженедельно на этапе внедрения и затем по установленному графику просматривайте DMARC-отчёты, всплески ошибок, неизвестные IP-адреса и долю сообщений без согласования. Храните историю изменений DNS и контакты владельцев систем.
Также контролируйте срок действия договорённостей с подрядчиками и доступ к DNS. Изменять почтовые записи должны только назначенные администраторы с многофакторной аутентификацией. Ошибку конфигурации удобно обнаруживать автоматической проверкой, но решение об удалении отправителя должен принимать владелец процесса вместе с техническим специалистом.
Условный пример: сайт, CRM и сервис рассылок
Условная компания использует корпоративную почту, форму на сайте, CRM и отдельный сервис маркетинговых рассылок. Инвентаризация показывает четыре источника. Для почтовой платформы и рассылок включают собственные DKIM-подписи. Сайт перестаёт отправлять сообщения напрямую с неподтверждённого сервера и передаёт их через согласованный почтовый маршрут. CRM получает отдельный подтверждённый источник и владельца.
DMARC сначала работает в режиме наблюдения. Отчёты выявляют старый сервис, которым отдел уже не пользуется, и несколько писем сайта с несогласованным доменом. После исправления тестируют заявку, уведомление CRM, обычное письмо и рассылку. Затем политику усиливают поэтапно. Это условный сценарий, а не кейс клиента ZXC; он показывает порядок действий без риска выключить полезные сообщения одним изменением DNS.
План внедрения для бизнеса
Назначьте владельца домена и согласуйте окно для изменений. Перед каждой правкой сохраняйте текущее значение DNS и план возврата. Учитывайте время кэширования записей: разные получатели могут видеть старую и новую конфигурацию не одновременно. Не удаляйте старый DKIM-ключ сразу после переключения, пока письма с прежней подписью ещё могут находиться в очередях.
- Составьте реестр всех почтовых потоков и их владельцев.
- Уберите дубли и лишние источники из SPF, проверьте лимит DNS-проверок.
- Включите согласованный DKIM для каждой рабочей платформы.
- Опубликуйте DMARC в режиме наблюдения и настройте сбор отчётов.
- Исправьте неизвестные источники, пересылку и несогласованные домены.
- Протестируйте критические письма на внешних почтовых системах.
- Переходите к карантину и отклонению поэтапно, сохраняя план возврата.
Следующий шаг: проверьте домен до изменения политики
Начните с инвентаризации, а не с копирования готовой DNS-записи. Сопоставьте реальных отправителей с SPF, DKIM и DMARC-отчётами, выделите критические письма и назначьте владельцев. После этого можно безопасно устранить пробелы и усилить защиту домена без внезапной остановки заявок и уведомлений.
ZXC MAIL помогает выстроить корпоративную почту и рабочие коммуникации, а ZXC SECURE — проверить доступы, защиту домена, мониторинг и реакцию на подозрительную активность. Конкретная конфигурация зависит от вашей почтовой платформы, DNS-провайдера и подключённых сервисов.
Частый вопрос: SPF защищает от подмены домена без DKIM и DMARC?
Нет. SPF проверяет источник для технического домена возврата и может нарушаться при пересылке. DMARC добавляет проверку согласованности с видимым адресом отправителя и политику обработки, а DKIM даёт независимый путь подтверждения подписи.
Частый вопрос: можно ли сразу включить DMARC с отклонением?
Технически можно, но без полной инвентаризации это риск для легитимных писем. Сначала соберите отчёты, исправьте все рабочие источники, проверьте критические сценарии и предусмотрите возврат. Затем усиливайте политику поэтапно.
Частый вопрос: аутентификация гарантирует попадание во входящие?
Нет. Она подтверждает источник и помогает избежать отказов, связанных с отсутствием проверки, но получатель учитывает также репутацию, жалобы, содержание, частоту, настройки DNS и другие сигналы. SPF, DKIM и DMARC — обязательная техническая основа, а не гарантия размещения во входящих.