SPF, DKIM, DMARC и BEC: как защитить корпоративную почту от фишинга и подмены счетов

Полное руководство по аутентификации email: от теории к работающей защите

Почему email по-прежнему главная дверь для мошенников

Электронная почта изобретена полвека назад, а её базовый протокол SMTP не предусматривал аутентификации отправителя: любой мог написать в поле «From» что угодно. Сегодня эта архитектурная дыра продолжает кормить целую индустрию киберпреступников.

Согласно данным Центра мониторинга Роскомнадзора, число фишинговых атак в России за 2024 год выросло на 425% по сравнению с 2023-м [1]. В апреле 2025 года ведомство заблокировало 14 115 фишинговых ресурсов за один месяц [6]. По оценке Bi.Zone, две трети — 68% — всех писем, приходящих на корпоративные адреса российских компаний, отправляются мошенниками, а каждое 137-е письмо в корпоративной почте оказывается фишинговым [2].

Чем занята большая часть этих писем? Либо кражей учётных данных, либо подменой счетов: преступник встраивается в деловую переписку, представляется директором или поставщиком и просит перевести деньги на новый расчётный счёт. Такая схема называется BEC — Business Email Compromise.

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

Масштаб угрозы: что такое BEC и почему это не просто фишинг

BEC расшифровывается как Business Email Compromise — компрометация корпоративной электронной почты. Это целевая атака, при которой злоумышленник выдаёт себя за руководителя, финансового директора, юриста или поставщика, чтобы заставить сотрудника перевести деньги или раскрыть конфиденциальную информацию.

Чем BEC отличается от обычного фишинга

Обычный фишинг — это массовая рассылка с расчётом на то, что кто-то из тысяч получателей кликнет по ссылке или введёт пароль на поддельном сайте. BEC — противоположность: мошенник проводит разведку, изучает структуру компании, имена сотрудников, стиль переписки, актуальные сделки. Письмо пишется под конкретного человека и конкретную ситуацию.

Главная коварность BEC в том, что такие письма, как правило, не содержат вредоносных вложений или ссылок. Это обычный текст. Традиционные антивирусные фильтры не видят в них угрозы, потому что технически письмо чистое. Единственный признак опасности — несоответствие домена отправителя. Но именно его и скрывает фишинговый домен [7].

Типичные сценарии BEC-атак:

1. Поддельный счёт от «поставщика» с просьбой сменить реквизиты для оплаты.
2. Письмо от «генерального директора» бухгалтеру с требованием срочно перевести деньги.
3. Внедрение в существующую цепочку переписки между двумя компаниями через похожий домен.
4. Запрос от «юридического отдела» передать персональные данные сотрудников или клиентов.
5. Голосовой дипфейк CEO с последующим письмом — новый тренд 2024–2025 годов [8].

Финансовый масштаб катастрофы

По данным ФБР (IC3), с 2013 по 2024 год мировой ущерб от BEC-атак превысил 55 млрд долларов, а только за 2022–2024 годы зафиксировано почти 8,5 млрд долларов потерь [9]. В 2024 году потери составили свыше 16,6 млрд долларов, что делает BEC-мошенничество более дорогостоящим, чем программы-вымогатели и утечки данных вместе взятые [3]. Среднестатистическая успешная атака обходится жертве примерно в 129 000 долларов [3].

В России и СНГ BEC-ущерб нарастает по отдельной динамике. По данным RTM Group, в 2023 году число BEC-атак на малые и средние предприятия в России выросло почти на 150% [10]. В ноябре 2024 года стало известно о волне атак на российских импортеров: мошенники создавали домены, отличающиеся от адресов поставщиков всего одним символом, и перехватывали платежи зарубежным контрагентам [2].

Для понимания механики: злоумышленники сначала рассылали фишинг обеим сторонам сделки, получали доступ к переписке, затем встраивались в неё через поддельные домены, контролируя оба конца канала. В нужный момент подменяли счёт — и деньги уходили на чужие счета. По данным Хабр, описывавшего реальные расследования таких атак в России, вся цепочка от первоначального взлома до получения денег может занимать меньше двух часов [11].

Три кита почтовой безопасности: SPF, DKIM, DMARC

Чтобы понять, как работают эти протоколы, нужно уяснить одну вещь: в электронном письме есть два «конверта» с адресами. Первый — технический, видимый только серверам (SMTP envelope). Второй — пользовательский, который человек видит в почтовом клиенте (поле From: в заголовке). Злоумышленники могут написать в видимом поле From что угодно — именно этим пользуются спуферы. SPF, DKIM и DMARC — это три разных механизма, которые вместе закрывают эту дыру.

SPF: список разрешённых отправителей

SPF (Sender Policy Framework) — стандарт, описанный в RFC 7208, — позволяет владельцу домена публично объявить в DNS: «Только вот эти серверы имеют право отправлять почту от имени моего домена» [12]. Когда сервер получателя принимает письмо, он смотрит в DNS домена из технического конверта и сверяет IP-адрес отправляющего сервера со списком.

Запись SPF выглядит примерно так:

v=spf1 ip4:203.0.113.1 include:_spf.google.com ~all

Здесь перечислены разрешённые серверы, а ~all в конце означает политику: письма с неразрешённых серверов принимать, но помечать как подозрительные. Более строгий вариант — -all — означает полный отказ.

Ограничения SPF. SPF проверяет технический конверт, а не то, что видит пользователь в поле «От кого». Это значит, что мошенник может указать в видимом поле From адрес вашей компании, а письмо технически отправить с другого домена — и SPF не поймает это несоответствие. Кроме того, SPF ломается при пересылке писем, когда IP-адрес промежуточного сервера не попадает в список разрешённых.

Важное техническое ограничение: RFC 7208 устанавливает лимит в 10 DNS-запросов при обработке SPF-записи [12]. Если их больше — возникает ошибка permerror, и защита перестаёт работать. Это частая проблема для компаний, использующих много сторонних почтовых сервисов [13].

DKIM: цифровая подпись письма

DKIM (DomainKeys Identified Mail), описанный в RFC 6376, использует криптографию с открытым ключом. Когда ваш почтовый сервер отправляет письмо, он подписывает его закрытым ключом, а публичный ключ публикует в DNS. Принимающий сервер проверяет подпись с помощью этого публичного ключа.

Преимущество DKIM перед SPF — его устойчивость к пересылке: цифровая подпись привязана к содержимому письма, а не к IP-адресу сервера, через который оно прошло. Если письмо перенаправили, подпись всё равно можно проверить.

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

Основные рекомендации по DKIM:

1. Используйте ключи длиной не менее 2048 бит — 1024-битные ключи считаются устаревшими и уязвимыми.
2. Ротируйте ключи регулярно — раз в год или раз в полгода.
3. При смене ключа не удаляйте старый немедленно: дайте время для доставки уже отправленных писем.

DMARC: политика и отчётность

DMARC (Domain-based Message Authentication, Reporting and Conformance), стандарт RFC 7489, решает ключевую проблему: он связывает SPF и DKIM с доменом, который видит пользователь в поле From:, и добавляет механизм отчётности [14].

DMARC вводит концепцию «выравнивания» (alignment): чтобы письмо прошло проверку DMARC, домен в видимом поле From: должен совпадать с доменом, проверенным SPF или DKIM (или обоими). Это закрывает лазейку, которую не закрывали SPF и DKIM по отдельности.

Три политики DMARC:

1. p=none — только мониторинг, письма доставляются без изменений. Начальная точка для наблюдения.
2. p=quarantine — подозрительные письма отправляются в папку «Спам».
3. p=reject — письма, не прошедшие проверку, отклоняются полностью.

Помимо политики, DMARC позволяет получать отчёты (RUA — агрегированные, RUF — детальные) о том, кто и что отправляет от имени вашего домена. Это самостоятельная ценность: даже на стадии p=none вы узнаёте обо всех попытках использовать ваш домен для рассылки.

Как три протокола работают вместе

Представьте, что SPF — это контроль на входе (проверка, что отправляющий сервер авторизован), DKIM — это пломба на конверте (подпись, подтверждающая целостность и источник), а DMARC — это инструкция охраннику: «Если пломба сорвана или отправитель не из списка — вот что делать».

По отдельности эти механизмы имеют уязвимости. Вместе они образуют замкнутый контур: злоумышленнику нужно одновременно подделать IP-адрес сервера (SPF), сломать криптографическую подпись (DKIM) и выдать домен за легитимный перед проверкой выравнивания (DMARC). Это практически невозможно без доступа к закрытым ключам и DNS-зоне владельца домена.

Реальность: кто настроен, а кто уязвим

Несмотря на очевидную ценность этих протоколов, их распространение остаётся недостаточным.

По данным EasyDMARC 2025 DMARC Adoption Report, глобальное внедрение DMARC среди топовых доменов выросло с 27,2% до 47,7% с 2023 по 2025 год — рост на 75%. Однако число доменов с политикой реального принуждения (quarantine или reject) выросло лишь на 50% [4]. Ещё острее проблема видна в исследовании Red Sift: из 73 миллионов доменов только 14,9% опубликовали хоть какую-то DMARC-запись, а политику p=reject применяют лишь 2,5% доменов [15].

По данным Fortra (Q2 2025), лишь 3,9% из 10 миллионов наиболее популярных доменов интернета применяют политику p=reject с учётом поддоменов [16]. При этом 83,9% всех доменов не имеют вообще никакой DMARC-записи [15].

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

EasyDMARC провёл сравнение стран с обязательным DMARC и без него: в США, где крупные провайдеры требуют DMARC от рассыльщиков, успешная доставка фишинговых писем снизилась с 69% до 14%. В странах без принудительного исполнения показатель уязвимости достигает 97% [4].

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

В 2023–2025 годах требования к почтовой аутентификации изменились радикально. Теперь это не рекомендация — это обязательное условие доставки.

Google и Yahoo (с февраля 2024 года)

С 1 февраля 2024 года Google и Yahoo ввели обязательные требования для «массовых отправителей» — тех, кто шлёт более 5000 писем в день [5]. Требования включают:

1. Аутентификацию через SPF или DKIM.
2. Наличие DMARC-записи с минимальной политикой p=none.
3. Выравнивание домена в поле From: с SPF или DKIM.
4. Поддержку отписки в один клик для коммерческих рассылок.
5. Соблюдение порога жалоб на спам ниже 0,1%.

В апреле 2024 года Google начал отклонять процент несоответствующего трафика, постепенно увеличивая долю. С ноября 2025 года Gmail перешёл к жёсткому применению: несоответствующие письма получают временные или постоянные отказы [17]. По данным Valimail, после внедрения требований: на 65% снизилось количество неаутентифицированных сообщений в Gmail, вдвое больше отправителей стали следовать лучшим практикам безопасности, а 265 миллиардов неаутентифицированных писем перестали доставляться в течение 2024 года [5].

Microsoft (с мая 2025 года)

Microsoft объявил аналогичные требования для Outlook.com, Hotmail и Live: с 5 мая 2025 года письма от доменов, отправляющих более 5000 сообщений в день и не соответствующих требованиям, отклоняются полностью с ошибкой 550 [18]. Microsoft сделал более жёсткий выбор, чем Google на старте: не «в спам», а сразу «reject».

Это означает, что сегодня четыре крупнейших провайдера — Google, Yahoo, Microsoft и Apple — покрывающие около 90% потребительских email-адресов, требуют аутентификации [5].

Практическое руководство: как настроить SPF, DKIM и DMARC

Шаг 1. Инвентаризация источников исходящей почты

Прежде чем что-либо настраивать, нужно ответить на вопрос: с каких серверов и сервисов компания сейчас отправляет почту? Это не всегда очевидно. Помимо основного почтового сервера могут быть:

1. CRM-система (например, Битрикс24, amoCRM).
2. Системы рассылок (UniSender, SendPulse и аналоги).
3. Корпоративная ERP/1С с модулем уведомлений.
4. Сервисы мониторинга, CI/CD, тикет-системы.
5. Подрядчики и партнёры, которым делегировано право отправлять письма от имени домена.

Пропустить хоть один источник — значит создать ложноположительные срабатывания при переходе к строгой политике DMARC.

Шаг 2. Настройка SPF

Опубликуйте TXT-запись в DNS вашего домена. Базовый синтаксис:

v=spf1 [механизмы] [политика]

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

v=spf1 include:_spf.yandex.net ip4:203.0.113.10 ~all

Рекомендации:

1. Используйте ~all (softfail) на начальном этапе, -all (hardfail) — после проверки что легитимные письма не блокируются.
2. Следите за лимитом в 10 DNS-запросов [12]. При превышении используйте SPF flattening или выносите часть потоков на поддомены.
3. Не используйте +all или ?all — это практически отключает защиту.
4. Домены, с которых почта не отправляется вообще, должны иметь запись v=spf1 -all.

Шаг 3. Настройка DKIM

Процесс состоит из двух частей. Первая — генерация пары ключей: закрытый ключ загружается на почтовый сервер, публичный ключ публикуется в DNS как TXT-запись.

Запись публикуется по адресу selector._domainkey.yourdomain.ru:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhk... [публичный ключ]

Рекомендации:

1. Минимальный размер ключа — 2048 бит. 1024-битные ключи следует заменить.
2. Давайте понятные имена селекторам: mail2025, google, exchange — чтобы отслеживать, что к чему относится.
3. Планируйте регулярную ротацию ключей.
4. Убедитесь, что все отправляющие сервисы настроены на подпись исходящих писем.

Шаг 4. Поэтапный переход к DMARC

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

Этап 1 — мониторинг:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.ru; ruf=mailto:dmarc-forensic@yourdomain.ru

Подождите 2–4 недели, изучайте отчёты. Ищите неизвестные источники писем, ошибки SPF/DKIM, чужие домены, отправляющие от вашего имени.

Этап 2 — карантин:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.ru

Параметр pct=10 означает «применяй политику только к 10% несоответствующих писем». Постепенно увеличивайте до 100%.

Этап 3 — отказ:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.ru

Полная защита. Ни одно письмо без валидного SPF/DKIM-выравнивания от вашего домена не будет доставлено.

Типичные ошибки и как их избежать

Ошибка 1. Политика p=none навсегда

Многие компании настраивают DMARC в режиме мониторинга и никогда не переходят к p=reject. По данным Fortra, 47,7% доменов с DMARC-записью вообще не включают тег rua — то есть даже не получают отчёты [16]. Такая «защита» — иллюзия. p=none не блокирует ни одного фишингового письма.

Ошибка 2. Забытые домены и поддомены

SPF и DMARC нужно настраивать не только для основного домена, но и для всех поддоменов, используемых для почты. Кроме того, домены, с которых почта никогда не отправляется (старые домены, домены партнёров, припаркованные домены), нужно «запечатать» запретительными записями — они тоже могут быть использованы для спуфинга [19].

Ошибка 3. Превышение лимита DNS-запросов в SPF

SPF разрешает не более 10 DNS-запросов при обработке. Типичная ошибка: компания добавляет один за другим include для всех сторонних сервисов и не замечает, что перешла лимит. Итог — ошибка permerror и письма в папку «Спам» или полный отказ [12].

Ошибка 4. Слабые ключи DKIM

1024-битные ключи DKIM считаются уязвимыми к современным атакам. Используйте 2048 бит — сегодня это минимальный приемлемый размер [20].

Ошибка 5. Отсутствие мониторинга после настройки

SPF и DKIM — «живые» конфигурации. Когда вы подключаете новый сервис рассылки или меняете почтовый провайдер, конфигурацию нужно обновлять. Без регулярного мониторинга вы не узнаете о нарушениях выравнивания, пока не начнутся проблемы с доставкой или инцидент безопасности.

Ошибка 6. Игнорирование DMARC-отчётов

DMARC-отчёты в формате XML сложно читать вручную. Используйте специализированные инструменты для их разбора. Игнорировать их — значит упускать информацию о попытках спуфинга вашего домена в реальном времени.

Ошибка 7. Доверие только техническим мерам

SPF, DKIM и DMARC блокируют прямой спуфинг домена, но не защищают от атак через похожие домены (тайпсквоттинг). Мошенник регистрирует sberbank-pay.ru вместо sberbank.ru — и такое письмо пройдёт все технические проверки [11]. Против этого нужны обучение сотрудников, проверка реквизитов по другому каналу и организационные процедуры.

Реальные кейсы: когда защита не сработала

Российские импортёры и подмена счетов (2024)

По данным «Ведомостей», в ноябре 2024 года была выявлена волна BEC-атак на российских импортёров. Злоумышленники создавали домены, отличающиеся от адресов реальных зарубежных поставщиков одним символом, и вклинивались в переписку. Деньги переводились за рубеж до того, как жертвы обнаруживали подмену [2]. Это классический пример атаки, которую остановил бы DMARC с политикой p=reject — если бы он был настроен у поставщика.

Orion S.A. — $60 млн через единственного сотрудника (2024)

В августе 2024 года производитель технического углерода Orion S.A. сообщил SEC, что рядовой сотрудник был обманут и перевёл несколько крупных платежей на счета злоумышленников. Ожидаемые потери — около 60 млн долларов. Атака типична: письма с реквизитами выглядели как обычная деловая переписка [3].

Сингапурская сырьевая компания — $41 млн за одно письмо (2024)

В июле 2024 года хакеры украли 41 млн долларов у сингапурской компании одним фишинговым письмом, имитирующим запрос от поставщика. Интерпол помог вернуть часть средств, задействовав глобальный механизм остановки платежей [2].

Bi.Zone: анализ реальной BEC-кампании (Россия)

Специалисты Bi.Zone описали многоэтапную BEC-атаку на российские компании: злоумышленники регистрировали фишинговые домены с идентичными DNS-записями, встраивались в переписку между компанией и её контрагентом, контролируя оба конца. Ключевая технологическая деталь: у фишинговых доменов не было ни SPF, ни DKIM, ни DMARC — но у жертв тоже не было DMARC с политикой отклонения [11].

Что не решают SPF, DKIM и DMARC: пределы технической защиты

Честный разговор о почтовой безопасности невозможен без перечня того, что эти протоколы не делают.

RFC 7489 явно указывает в разделе «Out of scope»: протокол не защищает от атак на поле отображаемого имени (display name attacks), не проверяет содержимое письма, не аутентифицирует физических лиц — только домены [14].

Практически это означает:

1. Атака через тайпсквоттинг: payme@sberбank.ru (с кириллической буквой) или payme@5berbank.ru успешно пройдёт все проверки.
2. Компрометация настоящего аккаунта: если у злоумышленника есть логин и пароль к реальному ящику, он будет отправлять письма как авторизованный пользователь.
3. Display name spoofing: письмо от Иван Иванов <random@gmail.com> с привычным именем в поле отправителя пройдёт DMARC для домена gmail.com.

Полноценная защита — это многоуровневая система: технические протоколы (SPF, DKIM, DMARC) + обучение сотрудников + организационные процедуры верификации (например, звонок поставщику для подтверждения смены реквизитов) + мониторинг аномалий в почтовом трафике.

Тренды 2025–2026: что меняется

ИИ на стороне атакующих

К середине 2024 года около 40% BEC-писем создавались с помощью генеративного ИИ [21]. ИИ-письма лишены грамматических ошибок, имитируют стиль конкретного человека, учитывают контекст переписки. В 2025 году эксперты фиксируют всплеск атак с синтезированным голосом директора: сначала звонок — «я CEO, переведи срочно», затем письмо с реквизитами [8]. Технические протоколы от этого не защищают — это война на поле социальной инженерии.

DMARCbis: обновление стандарта

В 2025–2026 годах IETF работает над обновлённой версией DMARC — DMARCbis. Ключевые изменения:

1. Новый тег t=y заменяет pct=0 для тестового режима.
2. Тег np= задаёт политику для несуществующих поддоменов, закрывая лазейку для спуфинга через random.nonexistent.company.com.
3. Обновлён алгоритм определения организационного домена (DNS Tree Walk вместо зависимости от Public Suffix List).
4. Форматы отчётности обновлены, использование RUF (детальных отчётов) ограничено из соображений конфиденциальности [22].

PCI DSS v4.0 и DMARC

С 31 марта 2025 года вступила в силу версия PCI DSS 4.0, которая требует от организаций, обрабатывающих платежи, наличия DMARC-политики на уровне не ниже p=quarantine [15]. Для российских компаний, работающих с международными платёжными системами, это дополнительный регуляторный стимул к настройке.

BIMI: бренд-идентификация в почтовом клиенте

BIMI (Brand Indicators for Message Identification) — следующий шаг после DMARC. При наличии p=reject и зарегистрированного логотипа компания может отображать свой логотип рядом с именем отправителя в почтовом клиенте. Gmail, Apple Mail и Yahoo поддерживают BIMI. Для пользователя это дополнительный визуальный сигнал доверия.

Чек-лист внедрения: пошаговый план для компании

Для начального этапа (первые 2 недели):

1. Провести инвентаризацию всех источников исходящей почты.
2. Убедиться, что SPF-запись существует и корректна. Проверить через nslookup -q=TXT yourdomain.ru или онлайн-инструментами (mxtoolbox.com, dmarcian.com).
3. Проверить наличие и корректность DKIM-подписи для каждого источника.
4. Опубликовать DMARC с политикой p=none и настроить получение отчётов.
5. Настроить разбор DMARC-отчётов (использовать специализированные инструменты).

Для среднего этапа (2–8 недель):

1. Проанализировать DMARC-отчёты: найти неизвестные источники, устранить ошибки выравнивания.
2. Убедиться, что все легитимные источники корректно подписаны DKIM.
3. Перейти к p=quarantine с pct=10, постепенно увеличивая процент.
4. Настроить поддомены: отдельные SPF-записи, политики DMARC.
5. «Запечатать» домены, не используемые для почты.

Для завершающего этапа (после 8 недель):

1. Перейти к p=reject для основного домена.
2. Настроить мониторинг и алертинг на аномалии в DMARC-отчётах.
3. Включить в регламент ИБ периодический аудит SPF/DKIM/DMARC.
4. Рассмотреть внедрение BIMI для усиления доверия к бренду.

Организационные меры:

1. Ввести правило: любые изменения банковских реквизитов подтверждать звонком по известному номеру.
2. Обучить сотрудников распознавать тайпсквоттинг и атаки на отображаемое имя.
3. Финансовым операциям на сумму выше порога назначить процедуру двойного подтверждения.
4. Провести тест: отправить сотрудникам учебные фишинговые письма и проверить реакцию.

«Пятый фактор»: как автоматизировать контроль над почтовой инфраструктурой и данными

Внедрение SPF, DKIM и DMARC — правильный первый шаг. Но у него есть ахиллесова пята: корпоративная инфраструктура непрерывно меняется. Появляются новые почтовые потоки, новые интеграции с подрядчиками, новые CRM и ERP-системы с почтовыми модулями. Без постоянного мониторинга конфигурация устаревает, а DMARC-отчёты сигнализируют о проблемах уже post factum.

Здесь на сцену выходит более широкий вопрос — контроль над данными и почтовой инфраструктурой как непрерывный процесс. Платформа «Пятый фактор» (5factor.ru) решает смежную задачу: автоматическое обнаружение, инвентаризация и контроль персональных данных в корпоративных системах — включая почтовые серверы, AD/LDAP, CRM, 1С и другие источники.

Ключевая особенность платформы — она работает с метаданными, структурой и агрегатами данных, не забирая и не сохраняя «сырые» персональные данные. Это значит, что само решение не становится дополнительным источником риска. Компания получает живую «карту данных»: где и какие данные есть, кто владелец, что изменилось.

Для задач почтовой безопасности это особенно актуально: «Пятый фактор» помогает видеть, какие системы получают доступ к корпоративной переписке, где хранятся персональные данные из писем (например, в CRM или в почтовых архивах), и своевременно обнаруживать новые интеграции — ещё до того, как они создают брешь в конфигурации аутентификации.

В условиях ужесточения российского законодательства (поправки к 152-ФЗ, Федеральный закон № 420-ФЗ, предусматривающий оборотные штрафы за утечки персональных данных до 500 млн рублей [23]) компании, не имеющие актуальной картины своей ИТ-инфраструктуры, рискуют «узнать» о проблеме только на этапе проверки или инцидента.

Заключение: техника плюс процесс плюс культура

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

Три вывода, которые стоит унести из этой статьи:

1. p=none — не защита. Единственный режим, реально блокирующий спуфинг вашего домена, — это p=reject. Путь к нему поэтапный, но он должен быть завершён.
2. Технические протоколы не заменяют обучение. BEC-атака через похожий домен или через скомпрометированный аккаунт пройдёт все проверки. Первая линия обороны — сотрудник, знающий, как выглядит подозрительный запрос на платёж.
3. Почтовая безопасность — это процесс, а не проект. Инфраструктура меняется, злоумышленники адаптируются. SPF, DKIM и DMARC требуют мониторинга и актуализации, а не однократной настройки.

Что делать прямо сейчас: проверьте домен вашей компании в любом DMARC-анализаторе (например, mxtoolbox.com, dmarcian.com, easydmarc.com). Если DMARC-записи нет или стоит p=none — у вас есть чёткий приоритет на ближайший месяц.

Источники

[1] Forbes.ru — «Пока взлом не грянет»: данные ЦМУ ССОП о росте фишинга в России на 425% — https://www.forbes.ru/tekhnologii/527262-poka-vzlom-ne-granet-kakim-dla-rynka-kiberbeza-byl-2024-god-i-kakim-budet-2025-j

[2] TAdviser — Мошенничество с электронной почтой (BEC, invoice fraud) в России — https://www.tadviser.ru/index.php/Статья:Мошенничество_с_электронной_почтой_(business_email_compromise,_BEC,_invoice_fraud)

[3] Valimail — The complete guide to BEC attacks in 2025 — https://www.valimail.com/blog/essential-guide-to-bec-attacks/

[4] EasyDMARC — 2025 DMARC Adoption Report — https://easydmarc.com/blog/ebook/easydmarc-dmarc-adoption-report-2025/

[5] Valimail — A complete guide to email compliance requirements from Microsoft, Google, Apple, and Yahoo — https://www.valimail.com/blog/email-sender-compliance/

[6] ComNews — Роскомнадзор заблокировал 14 115 фишинговых ресурсов в апреле 2025 — https://www.comnews.ru/content/239139/2025-05-12/2025-w20/1008/roskomnadzor-otrazil-941-ddos-ataku-kriticheski-vazhnye-sistemy

[7] Kaspersky — Что такое BEC-атака и как ей противостоять — https://www.kaspersky.ru/blog/what-is-bec-attack/27623/

[8] Passwork.ru — Кибератаки 2025: статистика, векторы атак и главные уязвимости — https://passwork.ru/blog/kiberataki-2026/

[9] Nacha / FBI IC3 — Almost $8.5 Billion Lost to BEC in Last Three Years — https://www.nacha.org/news/fbis-ic3-finds-almost-85-billion-lost-business-email-compromise-last-three-years

[10] Известия — Фишинга через электронную почту компаний стало больше — https://iz.ru/1528916/dmitrii-alekseev/tiazhelaia-inzheneriia-kompanii-stali-chashche-popadatsia-na-mnogokhodovyi-pochtovyi-fishing

[11] Habr / Bi.Zone — История одной кампании Business Email Compromise — https://habr.com/ru/company/bizone/blog/571512/

[12] IETF RFC 7208 — Sender Policy Framework (SPF) — https://www.rfc-editor.org/rfc/rfc7208

[13] AutoSPF — SPF DNS lookup limits: exploits, mitigations, and best practices — https://autospf.com/blog/spf-dns-lookup-limits-exploits-mitigations-and-best-practices/

[14] IETF RFC 7489 — DMARC Specification — https://www.rfc-editor.org/rfc/rfc7489

[15] Red Sift — Global DMARC Adoption Trends — https://redsift.com/guides/red-sifts-guide-to-global-dmarc-adoption

[16] Fortra — The State of Email Trust: Global DMARC Adoption Trends Q2 2025 — https://emailsecurity.fortra.com/blog/dmarc-adoption-trends-q2-2025

[17] Proofpoint — Stricter email authentication enforcements for Google starting November 2025 — https://www.proofpoint.com/us/blog/email-and-cloud-threats/clock-ticking-stricter-email-authentication-enforcements-google-start

[18] Dmarcian — Understanding Gmail and Yahoo DMARC Requirements — https://dmarcian.com/yahoo-and-google-dmarc-required/

[19] Dmarcian — SPF Best Practices — https://dmarcian.com/spf-best-practices/

[20] Anti-Malware.ru — Как настроить SPF, DKIM и DMARC для защиты корпоративной почты — https://www.anti-malware.ru/practice/methods/SPF-DKIM-DMARC-email-protection

[21] Hoxhunt — Business Email Compromise Statistics 2026 — https://hoxhunt.com/blog/business-email-compromise-statistics

[22] DmarcDkim.com — DMARCbis Adoption Data — https://dmarcdkim.com/data-room/dmarcbis-adoption-dmarc2

[23] Passwork.ru / Федеральный закон № 420-ФЗ — Кибератаки 2025: штрафы за утечки персональных данных — https://passwork.ru/blog/kiberataki-2026/