SPF, DKIM и DMARC в корпоративной почте: как защитить домен от подмены

Адрес на корпоративном домене подтверждает принадлежность письма компании только визуально. Поле «От кого» можно подделать, а письмо — отправить через посторонний сервер. Получателю нужен технический способ проверить, имеет ли сервер право отправлять сообщения от имени домена и не изменилось ли письмо после отправки.

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

Коротко

SPF, DKIM и DMARC — это не три варианта одной настройки.

• SPF перечисляет серверы, которым разрешено отправлять письма от имени домена.
• DKIM добавляет к исходящему письму криптографическую подпись, которую получатель проверяет по открытому ключу в DNS.
• DMARC определяет, как получатель должен поступать с письмом, если проверки не прошли, и куда отправлять отчёты.

Для работы корпоративной почты также нужна MX-запись. Она направляет входящие письма на почтовый сервер, но сама по себе не защищает исходящую почту от подмены.

SPF определяет разрешённые источники отправки

Компания может отправлять письма не только с основного почтового сервера. Уведомления поступают из CRM, системы заявок, сайта, сервиса рассылок или других корпоративных приложений. Если эти источники не учтены, часть легитимных сообщений не пройдёт проверку.

SPF-политика публикуется в DNS домена в виде TXT-записи. В ней указываются серверы и сервисы, которым разрешена отправка. Получающий сервер сравнивает источник письма с этой политикой и фиксирует результат проверки.

Перед настройкой полезно составить реестр всех отправителей:

• основной почтовый сервер;
• резервные узлы;
• сайты и формы обратной связи;
• CRM и сервис-деск;
• системы документооборота;
• платформы массовых и транзакционных рассылок;
• внутренние приложения, которые отправляют уведомления.

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

DKIM подтверждает целостность письма

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

Успешная проверка показывает, что письмо было подписано системой, которая владеет закрытым ключом, а подписанные части сообщения не изменились по дороге. DKIM не оценивает содержание и не заменяет антиспам. Он подтверждает происхождение подписи и целостность сообщения.

Для домена может использоваться несколько ключей с разными селекторами. Это позволяет разделять источники отправки и менять ключи без одновременной остановки всех почтовых потоков. Названия селекторов, владельцев и даты обновления стоит хранить в административной документации.

DMARC связывает проверки с видимым отправителем

SPF и DKIM могут пройти техническую проверку для служебных доменов, которые не совпадают с адресом в поле «От кого». DMARC добавляет требование согласованности доменов и задаёт правило обработки писем, не прошедших проверку.

Политика DMARC также публикуется в DNS. В зависимости от выбранного режима получателю предлагается наблюдать за нарушениями, помещать подозрительные письма в спам или отклонять их. Отчёты DMARC помогают увидеть, какие системы отправляют сообщения от имени компании и как часто проверки завершаются ошибкой.

Без анализа отчётов строгая политика может заблокировать легитимный источник, о котором не знала ИТ-команда. Поэтому переход к ограничительным действиям должен опираться на реестр отправителей и результаты наблюдения.

В каком порядке настраивать защиту домена

Работа начинается не с копирования готовых строк, а с карты почтовых потоков.

1. Соберите все системы, которые отправляют письма от имени корпоративного домена.
2. Определите владельца каждого источника и способ его авторизации.
3. Настройте SPF так, чтобы политика включала только действующие источники.
4. Включите DKIM-подписание и опубликуйте открытые ключи.
5. Добавьте DMARC в режиме наблюдения и настройте получение отчётов.
6. Устраните неизвестные и ошибочно настроенные источники.
7. После стабилизации потока переходите к более строгой политике обработки.

Если компания использует несколько доменов и поддоменов, их следует учитывать отдельно. Политика основного домена не всегда автоматически описывает все технические поддомены и внешние сервисы.

Частые ошибки

В SPF не учтены корпоративные приложения

Основная почта работает штатно, но письма из CRM или с сайта не проходят проверку. Причина часто заключается в том, что приложение отправляет сообщения через другой сервер.

В DNS опубликовано несколько SPF-записей

Разрозненные записи не складываются автоматически в одну политику. Источники нужно объединить в корректную конфигурацию, а устаревшие значения удалить.

DKIM-ключ опубликован не для того селектора

Получатель ищет открытый ключ по селектору из подписи. Ошибка в имени или размещении записи делает проверку невозможной, даже если сам ключ создан правильно.

Строгая DMARC-политика включена до инвентаризации

Легитимные рассылки начинают отклоняться, потому что один из отправителей не настроен. Сначала нужно увидеть фактический поток и исправить источники.

Настройку считают завершённой после публикации DNS

Почтовая инфраструктура меняется. Компания подключает новые сервисы, выводит старые, обновляет ключи и добавляет домены. Записи и отчёты требуют регулярного контроля.

Как связать настройки с рабочими процессами

У каждого источника отправки должен быть владелец. ИТ-служба отвечает за техническую конфигурацию, а владелец системы сообщает об изменениях: новом сервере, смене подрядчика, добавлении домена или прекращении отправки.

Полезно вести единый реестр с полями «система», «домен», «адрес отправителя», «сервер», «SPF», «DKIM», «ответственный» и «дата последней проверки». При подключении нового сервиса команда сначала добавляет его в реестр и только затем разрешает отправку от имени компании.

Так защита домена становится частью управления изменениями, а не разовой настройкой при запуске почты.

SPF, DKIM и DMARC в IVA360 Почте

MX-, SPF-, DKIM- и DMARC-записи публикуются в DNS-зоне домена, доступ к которой предоставляет сама организация. В форматах IVA360 Почты SMTP-сервер можно настроить на проверку SPF, DKIM и DMARC для входящих сообщений. Для исходящей почты поддерживается настройка DKIM-подписи домена через веб-интерфейс или CLI.

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

SPF, DKIM и DMARC не гарантируют, что каждое письмо безопасно. Они решают конкретную задачу — помогают получателю проверить источник, подпись и политику домена. За анализ вложений, ссылок и содержания отвечают другие уровни защиты.