Защита от спуфинга электронной почты: SPF, DKIM и DMARC

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

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

Разберём, как работают проверки, как читать DNS-записи и заголовки и как внедрять защиту, сохраняя доставку из CRM, сайта и сервисов рассылок. Примеры используют зарезервированные домены и IP-адреса: их нужно заменить данными своей инфраструктуры.

1. Что такое спуфинг и чем он отличается от фишинга

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

В корпоративной почте различают три ситуации:

• Подмена своего домена. В From указан адрес компании, хотя она письмо не отправляла. Здесь особенно важны SPF, DKIM и DMARC.
• Подмена отображаемого имени. Имя — «Генеральный директор», а адрес принадлежит постороннему. Аутентификация такого адреса может успешно пройти.
• Похожий домен. В названии заменена буква или добавлено слово. Мошенник может корректно настроить аутентификацию собственного домена.

Поэтому почтовая защита должна проверять аутентификацию и выявлять имитацию сотрудников, подозрительные ссылки и вложения. Эти задачи разделены и в документации Microsoft по антифишинговым политикам.

2. Какие адреса проверяются при получении письма

У письма несколько идентификаторов:

• From — адрес, который обычно видит получатель. DMARC проверяет его домен.
• MAIL FROM — адрес SMTP-конверта для возврата ошибок. Обычно его отражает Return-Path. Этот домен проверяет SPF; в отдельных ситуациях, например при пустом MAIL FROM, используется HELO.
• DKIM d= — домен подписанта в DKIM-Signature. Он может отличаться от домена From.
• Reply-To — адрес для ответа. Он может быть другим даже у настоящего письма, но неожиданное расхождение требует проверки.

Имя отправителя и один только Return-Path не доказывают подлинность. Связь видимого From с аутентификацией объясняется в руководстве Microsoft по DMARC.

3. Как работает SPF и как прочитать запись

SPF перечисляет источники, которым разрешено отправлять почту с определённым доменом SMTP-конверта. Получатель сопоставляет IP подключившегося сервера с политикой домена. Видимый From SPF непосредственно не проверяет.

Учебный пример: example.com отправляет почту только с двух собственных адресов.

example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.25 ip6:2001:db8::25 -all"

• v=spf1 обозначает SPF-политику.
• ip4: и ip6: перечисляют разрешённые адреса.
• -all даёт SPF fail для остальных источников. Это результат проверки, а не обещание отклонения каждым получателем.
• ~all означает softfail и также не является успешной SPF-аутентификацией.

Для облачного сервиса используйте include:, указанный в его документации. Не добавляйте сервис только потому, что он принимает входящую почту: MX и источники исходящей отправки решают разные задачи.

Для одного имени нужна одна SPF-запись с началом v=spf1. Несколько отдельных SPF-записей вызывают ошибку. Вложенные include учитываются в лимите DNS-обращений: стандарт допускает не более 10 механизмов и модификаторов, выполняющих такие обращения, за проверку; это не лимит всех TXT-записей домена. Правила определены в RFC 7208.

Перед изменением соберите всех отправителей: почтовую платформу, CRM, сайт, бухгалтерскую систему, принтеры со scan-to-email и рассылки. Порядок объединения источников разобран в инструкции Google по SPF.

4. Как работает DKIM и где хранится ключ

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

Приватный ключ не прикрепляется к письму и не размещается в DNS. Подпись не шифрует текст. Успешный результат означает, что подпись подписанных данных проверена публичным ключом домена подписанта. Безопасность вложения он не подтверждает. Механизм описан в RFC 6376.

Для поиска ключа нужны d= и s= из DKIM-Signature. При d=example.com и s=selector1 проверяют:

selector1._domainkey.example.com

Провайдер может выдать TXT с публичным ключом или CNAME на управляемый им ключ. Используйте выданные значения целиком: запись с выдуманным или обрезанным p= работать не будет.

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

5. Что проверяет DMARC и зачем нужно согласование доменов

Для DMARC pass достаточно одного согласованного успешного механизма: SPF или DKIM. Не требуется, чтобы оба обязательно прошли проверку.

Согласование, или alignment, означает соответствие домена SPF либо DKIM домену From. В relaxed-режиме допускаются домены одной организационной области, в strict-режиме требуется точное совпадение. Например, bounce.example.com и example.com могут согласоваться в relaxed-режиме, а mailer.example.net и example.com — нет.

SPF pass для стороннего сервиса ещё не означает DMARC pass для компании. Если сервис подписывает письмо согласованным доменом вашей компании, успешный DKIM может обеспечить DMARC pass даже при SPF fail. Примеры разбираются в документации Microsoft.

Актуальная спецификация — RFC 9989, опубликованный в мае 2026 года. Он заменил RFC 7489 и RFC 9091. Параметр pct, встречающийся в старых инструкциях, удалён из новой спецификации. Ниже используются базовые политики без него; особенности реализации проверяйте у своего провайдера.

6. Как настроить DMARC и не потерять легитимную почту

DMARC публикуют как TXT по имени _dmarc. Начните с наблюдения и сбора отчётов:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Адрес отчётов должен существовать. p=none не просит блокировать письма из-за DMARC fail. Это этап выявления источников и ошибок, а не завершённая защита от подделки домена.

После проверки штатных потоков переходят к более строгой политике:

• p=quarantine — запросить обработку не прошедших проверку сообщений как подозрительных.
• p=reject — запросить отклонение таких сообщений.

Пример после исправления легитимных отправителей:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Конечное решение принимает получатель с учётом своих правил. Для поддоменов отдельно проверьте собственные DMARC-записи и наследование политики, включая sp, если используете его.

Проверьте письма сотрудников, заявки сайта, CRM, мониторинг, рассылки и маршруты пересылки. После пересылки SPF может перестать проходить; сохранённая согласованная DKIM-подпись может помочь. Изменение содержимого посредником способно нарушить подпись. Проверять такие маршруты нужно до ужесточения политики. Порядок внедрения приведён в инструкции Google по DMARC.

7. Как проверить SPF, DKIM и DMARC через nslookup

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

nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com
nslookup -type=CNAME selector1._domainkey.example.com
nslookup -type=TXT selector1._domainkey.example.com

Для DKIM подставьте реальный селектор из настроек или DKIM-Signature. Универсального selector1 нет. CNAME и TXT здесь — варианты диагностики: создавать оба типа по одному имени не нужно. Если опубликован CNAME и инструмент не показывает ключ, отдельно запросите TXT имени, на которое он указывает.

После правки учитывайте TTL и кэш DNS. При разных ответах сравните результат рекурсивного резолвера с ответом авторитетного сервера. Подробный разбор команд есть в нашей статье «DNS-записи и nslookup».

MX указывает, куда приходит почта. SPF описывает разрешённую отправку. Найденный публичный ключ тоже не доказывает, что им подписываются все потоки: это проверяют по полученным письмам.

8. Как прочитать заголовки подозрительного письма

Откройте оригинал или полные заголовки. В Gmail используется пункт «Показать оригинал»; порядок для разных клиентов приведён в справке Google.

Ищите Authentication-Results, сформированный доверенным принимающим сервером. Не доверяйте любой строке с pass: отправитель может добавить похожий заголовок. При работе через шлюз нужно понимать, какой узел выполняет проверку и какие результаты следующий сервер считает доверенными. Граница доверия описана в RFC 8601.

Условный успешный результат:

Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=bounce.example.com;
 dkim=pass header.d=example.com header.s=selector1;
 dmarc=pass header.from=example.com

Проверьте домены, а не только слово pass. Затем сравните From, Reply-To, адрес сайта в ссылке и содержание просьбы. mx.example.net здесь — учебное имя проверяющего сервера, а не готовый доверенный узел для вашей системы.

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

9. Как использовать отчёты DMARC

Агрегированные отчёты помогают увидеть IP источников, объёмы сообщений, результаты SPF/DKIM и согласование доменов. Они нужны для анализа потоков, а не чтения каждого письма. Формат определён в RFC 9990.

Рабочий цикл:

• Сопоставьте известные источники с ответственными: почтовая платформа, CRM, сайт, рассылки.
• Для штатного источника с ошибками проверьте SPF, DKIM, пользовательский домен отправителя и маршрут доставки.
• Незнакомый источник исследуйте: это может быть атака, забытый сервис или пересылка. Не добавляйте его в SPF автоматически.
• После исправления проверьте новые отчёты и доставку контрольных сообщений.

Отсутствие отчётов не подтверждает отсутствие атак: не все получатели их отправляют. Для внешнего адреса rua может понадобиться разрешение владельца домена назначения. Ограничьте доступ к техническим сведениям в отчётах и определите срок хранения. Отчёты о сбоях, включающие содержимое писем, требуют отдельного внимания к конфиденциальности; для стартовой настройки этой статьи они не нужны.

10. Что делать при подозрении на поддельное письмо

Сотруднику не нужно самостоятельно разбирать все SMTP-заголовки. Его задача — остановить опасное действие и передать сообщение ответственным.

• Не открывайте неожиданное вложение и не вводите пароль по ссылке из подозрительного письма.
• Смену банковских реквизитов и срочный перевод подтверждайте по заранее известному номеру или утверждённому процессу согласования.
• Передайте письмо через функцию сообщения о фишинге либо сохраните оригинал для администратора. Обычная пересылка может изменить заголовки.
• Если пароль уже введён, немедленно сообщите об инциденте. Администратор должен сменить скомпрометированный пароль, отозвать сеансы, проверить MFA, правила пересылки и входы.

Компании нужны антифишинговые политики, защита учётных записей и проверка вложений. Для финансов, руководителей и администраторов полезна отдельная защита от имитации личности. Возможности и лицензирование проверяют в документации почтовой платформы.

Общие правила доступа и корпоративной инфраструктуры разобраны в нашей статье «Правила информационной безопасности компании».

11. Чек-лист внедрения защиты домена

• Перечислены домены и поддомены, с которых отправляется почта.
• Для каждого отправителя понятны MAIL FROM, From и домен DKIM-подписи.
• SPF объединён в одну корректную запись для каждого имени; учтены облачные сервисы и лимиты обращений.
• DKIM включён на отправляющих системах; публичные ключи доступны по нужным селекторам.
• DMARC проверен в режиме наблюдения; штатные источники исправлены, выбран момент перехода к строгой политике.
• Проверены сообщения сайта, CRM, рассылок, принтеров и маршруты пересылки.
• Назначен ответственный за отчёты, DNS и проверку при подключении новых сервисов.
• Сотрудники знают, как сообщить о подозрительном письме и подтвердить платёж вне переписки.

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

Для помощи с инвентаризацией отправителей и аутентификацией свяжитесь с АВАНГАРД ИТ. Проверку стоит начинать с реальных маршрутов писем и настроек провайдеров.

12. Ответы на частые вопросы

Можно ли защититься только SPF? SPF проверяет источник для домена конверта. Для защиты видимого From настройте DKIM и DMARC и проверьте согласование.

Нужен ли DKIM, если SPF проходит? Его стоит настроить: он даёт независимый способ аутентификации, который может сохраняться при пересылке, если подписанное содержимое не изменилось.

Достаточно ли p=none? Для наблюдения — да. Для запроса строгой обработки не прошедших DMARC писем — нет. К quarantine или reject переходят после проверки штатных потоков.

Почему DMARC pass у мошеннического письма? Проверка относится к использованию домена. Она не подтверждает полномочия человека, безопасность ссылки или правомерность платежа.

Защищает ли логотип рядом с письмом? Сам по себе логотип не является достаточным доказательством. BIMI — отдельный механизм отображения бренда с требованиями конкретных провайдеров; он не заменяет аутентификацию и проверку запроса.

Это инструкция против ARP- и IP-спуфинга? Здесь разобрана почта. Подмена адресов в сети требует других механизмов. SPF, DKIM и DMARC такие сетевые атаки не останавливают.