SPF, DKIM и DMARC: как защитить почту компании от подделки

Бухгалтер получает письмо от директора: «Срочно оплати счёт поставщику, реквизиты во вложении». Адрес отправителя — тот же домен компании, подпись знакомая, тон привычный. Платёж уходит. Позже выясняется, что директор ничего не писал. Протокол электронной почты изначально не проверяет, имеет ли отправитель право писать от имени домена: поле «От кого» заполняется так же свободно, как обратный адрес на бумажном конверте. Закрывают эту дыру три записи в DNS — SPF, DKIM и DMARC. Ниже — что каждая делает, как их настроить по шагам и какие ошибки чаще всего ломают доставку собственных писем.

Почему подделать письмо так просто

Когда почтовый сервер отправляет письмо, он сам сообщает получателю, от кого оно. Проверки, встроенной в базовый протокол SMTP, нет — поэтому подделка адреса отправителя (спуфинг) не требует взлома вашего ящика или сервера. Злоумышленнику достаточно любого сервера, который согласится отправить письмо. Получатель видит в почтовом клиенте ваш домен и доверяет ему. Отсюда типичные сценарии атак на бизнес:

• Письмо «от руководителя» с просьбой срочно оплатить счёт или сменить реквизиты контрагента.
• Письмо клиентам «от вашей компании» со ссылкой на поддельную страницу оплаты или входа в личный кабинет.
• Письмо сотрудникам «от IT-отдела» с просьбой подтвердить пароль от почты или CRM.
• Рассылка спама с вашего домена — после неё почтовые сервисы начинают хуже доставлять уже ваши настоящие письма.

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

SPF: список серверов, которым разрешено отправлять

SPF (Sender Policy Framework) — это TXT-запись в DNS домена, в которой перечислено, с каких серверов разрешено отправлять почту от его имени. Принимающий сервер смотрит, откуда пришло письмо, и сверяет адрес со списком. Запись выглядит примерно так: v=spf1 include:_spf.почтовый-сервис ip4:203.0.113.10 ~all. Здесь include подключает список серверов вашего почтового провайдера, ip4 добавляет отдельный адрес (например, сервер сайта, который шлёт уведомления), а окончание определяет, что делать с остальными: ~all — «помечать как подозрительное», -all — «отклонять».

• У домена должна быть ровно одна SPF-запись. Две отдельные записи v=spf1 — частая ошибка, после которой проверка не проходит вовсе.
• В записи допускается не больше 10 DNS-запросов (каждый include, a, mx считается). При превышении проверка завершается ошибкой. Если сервисов много — уберите лишние include или замените их конкретными IP-адресами.
• SPF проверяет адрес из технического конверта письма (Return-Path), а не тот, что видит человек в поле «От кого». Поэтому сам по себе SPF подделку видимого отправителя не останавливает — для этого нужен DMARC.
• При пересылке письма (переадресация с одного ящика на другой) SPF обычно ломается: письмо приходит уже с чужого сервера. Это нормально и компенсируется DKIM.

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

DKIM (DomainKeys Identified Mail) решает другую задачу: доказывает, что письмо действительно отправлено от имени домена и не было изменено по дороге. Сервер-отправитель подписывает заголовки и тело письма закрытым ключом, а открытый ключ публикуется в DNS в записи вида selector._domainkey.ваш-домен. Получатель берёт ключ из DNS и проверяет подпись. Подделать её без закрытого ключа невозможно.

• Ключ генерирует почтовый сервис или ваш почтовый сервер; вам остаётся опубликовать TXT-запись, которую он выдаст.
• Селектор (часть имени перед _domainkey) позволяет держать несколько ключей: отдельный для корпоративной почты, отдельный для сервиса рассылок, отдельный для уведомлений сайта.
• Используйте ключи длиной не меньше 2048 бит, если сервис это поддерживает. Короткие ключи считаются устаревшими.
• DKIM переживает пересылку письма, поскольку подпись привязана к содержимому, а не к серверу. Поэтому он надёжнее SPF в реальной жизни.

DMARC: правило, что делать с подделкой, и отчёты

DMARC связывает SPF и DKIM с тем адресом, который видит человек. Письмо проходит DMARC, если хотя бы одна из проверок (SPF или DKIM) прошла успешно и при этом домен в ней совпадает с доменом в поле «От кого» — это называется выравниванием (alignment). Запись публикуется в DNS как TXT для _dmarc.ваш-домен и выглядит так: v=DMARC1; p=none; rua=mailto:dmarc@ваш-домен.

• p=none — только наблюдать: письма доставляются как обычно, а вы получаете отчёты.
• p=quarantine — письма, не прошедшие проверку, отправлять в спам.
• p=reject — отклонять такие письма полностью.
• rua — адрес для агрегированных отчётов: почтовые сервисы присылают сводки, с каких серверов от имени вашего домена шли письма и прошли ли они проверку.
• pct — доля писем, к которой применяется политика. Позволяет ужесточать правило постепенно, например сначала на 25% потока.
• sp — отдельная политика для поддоменов. Злоумышленники любят поддомены вида billing.ваш-домен, если для них ничего не настроено.

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

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

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

• Шаг 1. Инвентаризация. Составьте список всего, что отправляет письма от имени домена: корпоративная почта, сайт (формы, восстановление пароля), CRM, сервис рассылок, онлайн-касса, бухгалтерия, служба поддержки.
• Шаг 2. SPF. Соберите одну запись, включающую все легальные источники. Проверьте, что лимит в 10 DNS-запросов не превышен.
• Шаг 3. DKIM. Включите подпись в каждом сервисе, который это умеет, и опубликуйте ключи. Отправьте тестовые письма и посмотрите в заголовках, что подпись проходит (dkim=pass).
• Шаг 4. DMARC в режиме наблюдения: p=none с адресом для отчётов. Подождите несколько недель, чтобы в отчёты попали все регулярные отправки, включая ежемесячные.
• Шаг 5. Разбор отчётов. Каждый легальный источник, который не проходит проверку, добавьте в SPF или настройте для него DKIM.
• Шаг 6. Ужесточение: p=quarantine, при необходимости сначала с pct ниже 100, затем p=reject. Между шагами снова смотрите отчёты.

Условный пример: компания с сайтом, CRM и рассылкой

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

• Корпоративная почта: SPF и DKIM проходят — провайдер настроен корректно.
• Сайт: SPF не проходит, потому что IP сервера сайта не добавлен в запись; DKIM не настроен. Решение — добавить ip4 сервера в SPF и включить подпись в почтовом модуле сайта, либо отправлять уведомления через корпоративный почтовый сервис.
• CRM: письма идут от имени домена компании, но через серверы CRM. Нужно добавить include CRM в SPF и опубликовать её DKIM-ключ, если она это поддерживает.
• Сервис рассылок: подписывает письма своим доменом, а не вашим, поэтому выравнивание не проходит. Решение — настроить в сервисе подпись вашим доменом (обычно это раздел про аутентификацию домена).
• Неизвестный IP из другой страны, который шлёт письма «от бухгалтерии». Это и есть подделка — после перехода на p=reject такие письма перестанут доходить.

В этом примере без режима наблюдения компания при немедленном включении p=reject потеряла бы уведомления сайта, письма CRM и рассылку — три канала из четырёх. Именно поэтому шаг с отчётами нельзя пропускать.

Как читать отчёты DMARC без боли

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

• Список IP-адресов и доменов, от которых шли письма, и объём писем от каждого.
• Для каждого источника — прошёл ли SPF, прошёл ли DKIM и было ли выравнивание с вашим доменом.
• Новые источники, которых не было в прошлом отчёте. Это либо новый сервис, подключённый коллегами без согласования, либо попытка подделки.
• Долю писем, не прошедших проверку. Пока она заметна у легальных источников, ужесточать политику рано.

Типичные ошибки

• Две SPF-записи вместо одной объединённой.
• SPF с окончанием +all — фактически разрешает отправлять кому угодно и сводит смысл записи к нулю.
• Опечатка в имени DKIM-записи: ключ опубликован, но не по тому адресу, где его ищет получатель.
• DMARC годами висит в p=none. Отчёты приходят, но никто их не читает, и защиты от подделки по сути нет.
• Защищён основной домен, но не защищены поддомены и неиспользуемые домены компании. Для домена, с которого почта не отправляется вообще, правильная конфигурация — SPF v=spf1 -all и DMARC p=reject.
• Отчёты DMARC приходят на личный ящик сотрудника, который давно уволился.
• После смены почтового провайдера или CRM старые записи не удалены, а новые не добавлены.

Что ещё влияет на доставку писем

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

• MX-записи указывают, куда доставлять входящую почту. Ошибка в них не мешает отправке, но ломает получение ответов и отчётов DMARC.
• Обратная DNS-запись (PTR) для IP-адреса сервера должна указывать на осмысленное имя хоста, которое, в свою очередь, указывает обратно на этот же IP. Сервер без PTR многие получатели считают подозрительным. Настраивается она у владельца IP — обычно у хостинг-провайдера.
• Репутация IP-адреса: если адрес раньше использовался для спама, письма с него могут блокироваться. Проверьте адрес по открытым спискам блокировок.
• Содержимое и поведение: резкие всплески объёма писем, рассылка по старой неподтверждённой базе и большое число жалоб снижают доверие к домену даже при идеальных DNS-записях.

Кто в компании должен за это отвечать

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

Чего эти записи не делают

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

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

• Есть ли у домена одна, а не несколько SPF-записей, и перечислены ли в ней все сервисы, которые отправляют письма.
• Не превышен ли лимит в 10 DNS-запросов в SPF.
• Подписывает ли DKIM письма корпоративной почты, CRM, сайта и сервиса рассылок вашим доменом.
• Есть ли запись _dmarc и указан ли в ней рабочий адрес для отчётов, который кто-то читает.
• Какая сейчас политика DMARC и сколько времени она не менялась.
• Настроена ли защита поддоменов (параметр sp) и доменов, с которых почта не отправляется.
• Включена ли двухфакторная аутентификация на почтовых ящиках руководства и бухгалтерии.
• Есть ли правило подтверждать изменение реквизитов и срочные платежи по телефону.

Проверить текущее состояние записей можно бесплатными онлайн-сервисами проверки DNS или командой nslookup -type=txt для домена, его _dmarc и DKIM-селектора. Отправьте себе письмо на ящик у крупного почтового сервиса и откройте исходный текст письма: в заголовке Authentication-Results будет видно, прошли ли spf, dkim и dmarc.

Вывод и следующий шаг

Подделать письмо от имени домена без SPF, DKIM и DMARC может кто угодно, а настроить все три записи — задача на несколько часов работы и несколько недель наблюдения. Начните с инвентаризации отправителей и DMARC в режиме p=none: это ничего не сломает и уже через пару недель покажет реальную картину. Если хотите, чтобы почтовый периметр проверили вместе с сайтом, поддоменами и доступами, это входит в наш аудит безопасности — после него вы получите список находок с приоритетами и перепроверку после исправлений.