Безопасность электронной почты

13 мин чтения·Для руководителя и лидера безопасности

Коротко

• SPF, DKIM и DMARC работают только вместе. Пока политика DMARC не доведена до p=reject, письмо от вашего домена может отправить кто угодно.
• BEC-мошенничество останавливает не техника, а процесс: платёж выше порога подтверждается по второму каналу связи.
• Компрометация почтового ящика не заканчивается сменой пароля — проверьте правила пересылки, OAuth-приложения и пароли приложений.

Генеральный директор получает письмо с адреса buhgalteriya@vashakompaniya.ru — просьба срочно перевести 800 тысяч рублей поставщику. Письмо выглядит легитимно: ваш домен, привычная подпись. Только письмо отправил не ваш бухгалтер, а мошенник. Потому что никто не настроил почтовую аутентификацию, и отправить письмо от имени вашего домена не составило труда.

Такие атаки — Business Email Compromise (BEC), компрометация корпоративной переписки — фиксируются по всему миру. Технически они элементарны: бесплатные инструменты позволяют подделать отправителя за несколько минут. Без SPF, DKIM и DMARC любой может отправить письмо, которое выглядит как письмо от вашей компании.

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

Почему почта — главный вектор атак

Почта — точка входа для большинства инцидентов. Не потому что почтовые системы уязвимы, а потому что цель атак — люди.

• Подделка (spoofing) — письмо, которое выглядит как отправленное с вашего домена. Используется для CEO-fraud, подделки счетов и фишинга. Без аутентификации — любой может отправить письмо «от вас».

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

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

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

Три протокола, которые работают вместе

SPF (Sender Policy Framework)

SPF — это DNS TXT-запись, которая перечисляет серверы, которым разрешено отправлять почту от имени вашего домена. Когда почтовый сервер получателя принимает письмо, якобы отправленное с вашего домена, он проверяет SPF-запись: входит ли IP-адрес сервера-отправителя в список разрешённых? Если нет — проверка провалена.

Что закрывает SPF: отправку письма с произвольного сервера от имени вашего домена.

Чего не закрывает: подделку заголовка From:, который видит пользователь. SPF проверяет технический адрес отправителя (Return-Path), а не то, что отображается в почтовом клиенте. Поэтому нужен DMARC.

Пример SPF-записи для Яндекс 360 для бизнеса:

v=spf1 include:_spf.yandex.ru ~all

Если вы дополнительно используете сервисы рассылки (транзакционная почта, CRM), их серверы тоже включаются в запись через include:.

DKIM (DomainKeys Identified Mail)

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

Что закрывает DKIM: подтверждает подлинность отправителя и целостность письма.

Чего не закрывает: само по себе не говорит получателю, что делать с письмами, которые DKIM не прошли.

Пример DKIM-записи в DNS (публикуется автоматически при настройке через панель вашего почтового провайдера):

mail._domainkey.example.ru TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Настройка DKIM делается через панель вашего почтового сервиса — Яндекс 360, VK WorkSpace, МойОфис или другой. Не нужно разбираться в криптографии: провайдер генерирует ключи и даёт вам готовую DNS-запись для вставки.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

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

Пример DMARC-записи:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.ru

Это значит: «Письма, провалившие проверку SPF и DKIM, — отклонять. То же применять к поддоменам. Агрегированные отчёты слать на dmarc@example.ru».

Уровни политики:

• p=none — мониторинг без блокировки. Начинать нужно с этого.
• p=quarantine — отправлять провалившие проверку письма в спам.
• p=reject — отклонять. Это цель.

Что закрывает DMARC: реальное применение аутентификации и видимость угроз.

Пошаговое внедрение

Шаг 1. Аудит текущего состояния

Прежде чем что-то менять — проверьте, что у вас есть сейчас. Онлайн-инструменты:

• MXToolbox (mxtoolbox.com) — проверяет SPF, DKIM, DMARC в одном месте.
• mail-tester.com — отправьте тестовое письмо и получите подробный анализ.

Многие компании имеют частичные конфигурации, которые никто не обновлял годами. Сначала — инвентаризация.

Шаг 2. Реестр почтовых отправителей

Составьте список всех сервисов, которые отправляют почту от имени вашего домена:

• Основная корпоративная почта (Яндекс 360, VK WorkSpace, МойОфис, Communigate Pro и др.)
• Маркетинговые рассылки
• Транзакционная почта (уведомления из приложения)
• CRM, HelpDesk, HR-системы

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

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

Добавьте или обновите TXT-запись в DNS вашего домена. Начните с мягкой политикой (~all), а не жёсткой (-all) — это позволит отлаживать конфигурацию без риска потерять легитимную почту.

Важные ограничения SPF:

• Максимум 10 DNS-запросов в одной записи. Если у вас много почтовых сервисов с include:, легко превысить лимит. MXToolbox покажет текущее количество.
• Только одна SPF-запись на домен. Наличие двух — ломает обе.
• Если используете несколько почтовых сервисов, рассмотрите разделение по поддоменам: уведомления из приложения отправляются с notify.example.ru, маркетинг — с mail.example.ru, у каждого своя SPF-запись с отдельным лимитом.

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

Настраивается через панель управления вашего почтового провайдера:

• Яндекс 360: настройки домена → DKIM → сгенерировать ключ → добавить DNS-запись.
• VK WorkSpace, МойОфис, Communigate Pro: аналогично — через панель администратора.
• Для сторонних сервисов рассылки — через их раздел аутентификации домена.

Сохраните DNS-запись и проверьте через MXToolbox после распространения (обычно от 15 минут до нескольких часов).

Шаг 5. Поэтапное внедрение DMARC

Торопиться здесь нельзя. Резкий переход на p=reject без подготовки может заблокировать собственную почту.

Этап 1 (первые 2 недели) — мониторинг без блокировки:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.ru

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

Этап 2 (недели 3–4) — анализ отчётов:

XML-отчёты неудобочитаемы вручную. Используйте бесплатные сервисы-агрегаторы:

• DMARC Analyzer (dmarcanalyzer.com) — есть бесплатный тариф.
• Postmark DMARC (dmarc.postmarkapp.com) — бесплатные еженедельные дайджесты.
• dmarcian.com — бесплатный тариф с подробной аналитикой.

Цель анализа: убедиться, что все легитимные отправители проходят проверку. Найти и исправить тех, кто проваливает SPF или DKIM. Обнаружить попытки подделки.

Этап 3 (с 5-й недели) — постепенное усиление:

Когда убедились, что легитимная почта проходит стабильно:

v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@example.ru

Ещё несколько недель мониторинга — затем переход на p=reject. Весь процесс занимает 4–8 недель, но предотвращает потери от самостоятельно заблокированной почты.

Дополнительные стандарты

MTA-STS (Mail Transfer Agent Strict Transport Security)

Заставляет другие почтовые серверы использовать зашифрованные соединения (TLS) при отправке почты на ваш домен. Без этого злоумышленник может понизить уровень соединения до незашифрованного и перехватить письма.

Настройка требует создания файла политики на веб-сервере mta-sts.example.ru и DNS-записи. Это разовая работа на час, которую можно поручить DevOps.

BIMI (Brand Indicators for Message Identification)

Отображает логотип вашей компании рядом с письмами в поддерживающих клиентах (Gmail, Apple Mail). Требует DMARC с p=quarantine или p=reject. Для ряда почтовых провайдеров также нужен VMC-сертификат (Verified Mark Certificate) — платный документ, подтверждающий права на логотип.

BIMI — скорее имиджевая история, чем первостепенная защита. Внедряйте после того, как базовые протоколы настроены и стабильно работают.

Почтовые шлюзы безопасности

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

Российские решения:

• Kaspersky Security для почтовых серверов — антивирус, антиспам, проверка вложений.
• Dr.Web Mail Security — аналогично, с сертификатами ФСТЭК.
• UserGate — российский UTM с функцией почтового шлюза.
• Ideco UTM — почтовый шлюз в составе комплексного решения.

Когда стоит задуматься о шлюзе:

• Значительное количество фишинговых писем продолжает проходить несмотря на DMARC.
• Требования комплаенса предполагают архивирование почты или шифрование.
• Нужна централизованная политика для нескольких доменов.

Для большинства небольших компаний правильно настроенный DMARC в сочетании со встроенными защитными функциями Яндекс 360 или аналога — достаточная база. Шлюз добавляет сложность и стоимость.

BEC: процессная защита против финансового мошенничества

Технические меры защищают от подделки домена. Но BEC-атака может прийти с корректно аутентифицированного адреса — если злоумышленник скомпрометировал реальный аккаунт через фишинг.

Единственная надёжная защита здесь — процессная.

Политика верификации платежей

Напишите и введите в действие письменную политику:

Для банковских переводов и смены реквизитов:

1. Любой запрос на смену платёжных реквизитов — верификация по телефону.
2. Звонить по заранее известному номеру из справочника компании, а не по номеру из письма.
3. Переводы выше установленного порога — подтверждение двух уполномоченных лиц.
4. Новый контрагент — верификация до первого платежа.

Для чувствительных данных:

1. Запрос персональных данных сотрудников (паспортные данные, СНИЛС) — только при личном контакте или по телефону.
2. Чувствительные документы — только через защищённый обмен, не почтой.

Процедура верификации (экономит миллионы)

При получении запроса на перевод:

1. Не отвечать на письмо.
2. Найти номер отправителя в корпоративном справочнике или предыдущей переписке.
3. Позвонить напрямую.
4. Подтвердить сумму, реквизиты, назначение.
5. Зафиксировать факт верификации.

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

Специальный инструктаж финансовой службы

Финансовая служба — главная мишень BEC. Ей нужно:

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

Защита от похожих доменов (lookalike domains)

SPF/DKIM/DMARC защищают ваш домен. Но злоумышленники регистрируют похожие:

• vashakompaniya.co — другой TLD
• vаshakompaniya.ru — кириллическая «а» вместо латинской
• vasha-kompaniya.ru — с дефисом
• vashakompaniyа-support.ru — с добавлением слова

Защитная регистрация

Зарегистрируйте очевидные вариации вашего домена — особенно популярные TLD (.com, .net, .org, .рф) и распространённые опечатки. Это расходы на хостинг, но они предотвращают простое мошенничество.

Мониторинг похожих доменов

Попросите лидера безопасности периодически проверять, не регистрирует ли кто-то домены, похожие на ваш. Инструмент dnstwist (open-source) генерирует перестановки и проверяет, какие зарегистрированы.

Если нашли мошеннический домен:

1. Проверить, активен ли он (сайт, почта).
2. Подать жалобу регистратору домена.
3. Если домен используется для фишинга — уведомить НКЦКИ (Национальный координационный центр по компьютерным инцидентам, cert.gov.ru) и направить жалобу в антиспам-базы.

Компрометация почтового аккаунта: что делать

Признаки компрометации

• Неожиданная смена пароля.
• Вход с незнакомого устройства или из другой страны (проверяйте историю входов).
• Коллеги получают странные письма «от» сотрудника.
• Обнаружены неизвестные правила переадресации.
• Пользователь заблокирован в собственном аккаунте.

Первые 30 минут

1. Сменить пароль — через консоль администратора, если пользователь заблокирован.
2. Завершить все сессии — принудительный выход на всех устройствах.
3. Проверить и удалить правила переадресации — злоумышленники настраивают их для получения копий писем даже после смены пароля.
4. Проверить OAuth-приложения — отозвать подозрительный или неизвестный доступ.
5. Включить MFA, если не была включена.

Расследование (следующие часы)

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

Уведомления

• Внутри компании: оповестить сотрудников, если фишинговые письма рассылались с аккаунта.
• Контрагентам и клиентам: если они получили мошеннические письма «от» вашей компании.
• Регуляторам: если были доступны персональные данные — в соответствии с требованиями 152-ФЗ уведомление об утечке ПДн направляется в Роскомнадзор (срок: 24 часа с момента обнаружения факта, 72 часа — с результатами расследования).

OAuth и пароли приложений: скрытый доступ к почте

Компрометация аккаунта — не всегда кража пароля. OAuth-токены и пароли приложений дают доступ, который сохраняется даже после смены пароля.

Схема OAuth-атаки:

1. Пользователь получает фишинговое письмо: «Просмотрите документ».
2. Переходит на поддельную страницу авторизации OAuth.
3. Разрешает «приложению» доступ к своей почте.
4. Приложение принадлежит злоумышленнику — теперь у него доступ к почте.
5. Смена пароля не отзывает OAuth-токен.

Что делать: аудит подключённых OAuth-приложений в панели администратора Яндекс 360, VK WorkSpace или другого провайдера. Отозвать неизвестное или давно не используемое. Рассмотрите запрет пользовательских авторизаций сторонних приложений — допускайте только приложения из корпоративного реестра.

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

✓Управленческий чек-лист

Почтовая аутентификация

• SPF настроен для всех доменов компании.
• SPF включает всех легитимных отправителей (нет сервисов «за бортом»).
• DKIM настроен для основного почтового провайдера и ключевых сторонних сервисов.
• DMARC опубликован — хотя бы на уровне p=none с адресом для получения отчётов.
• Получение и анализ DMARC-отчётов настроено (агрегатор подключён).
• Цель — переход на p=reject — зафиксирована с датой.

Защита от мошенничества

• Политика верификации платёжных запросов написана и введена в действие.
• Финансовая служба прошла специальный инструктаж по BEC.
• Процедура «при сомнении — звонок» закреплена как норма, а не исключение.

Мониторинг и реагирование

• Внешние письма помечаются предупреждением в почтовом клиенте.
• Сотрудники знают, как сообщить о подозрительном письме (кнопка или адрес).
• Лидер безопасности знает процедуру реагирования на компрометацию аккаунта.
• Квартальный аудит: DMARC-отчёты, OAuth-приложения, правила переадресации.

Смежные вопросы

• Рассмотрена регистрация защитных вариаций домена.
• Для руководителей и финансовой службы настроено усиленное MFA.

См. также

• Антифишинговое обучение — человеческий рубеж защиты
• Плейбуки реагирования — что делать при компрометации ящика

Что дальше

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

Следующая глава: гигиена email и обучение сотрудников — как выстроить антифишинговую культуру, которая действительно работает.