Фишинговые атаки и подделка корпоративных писем угрожают как бизнесу, так и пользователям. Проверять подлинность отправителей, защищать содержимое писем и блокировать мошеннические сообщения до их попадания во входящие позволяют механизмы SPF, DKIM и DMARC. Мы подготовили гайд по их настройке.
- Введение
- Почему подделка почты — угроза
- SPF: контроль отправителей
- DKIM: защита содержимого письма с помощью цифровой подписи
- DMARC: настройка политики обработки и отчётов для поддельных писем
- Пошаговая настройка SPF, DKIM и DMARC в DNS — инструкция для админов
- Типовые ошибки при настройке SPF, DKIM и DMARC и как их избежать
- Онлайн-инструменты для проверки SPF, DKIM и DMARC: что выбрать
- Выводы
Введение
Почта остаётся одним из самых уязвимых каналов в корпоративной ИТ-инфраструктуре. Фишинг, подделка отправителей, рассылка вредоносных вложений — эти методы стоят за большинством инцидентов с утечками данных и проникновениями в сети. При этом злоумышленники не ломают технические средства защиты — они обманывают пользователей. Один из главных способов — подделка адреса отправителя. А сами вредоносные программы чаще приходят в виде вложений.
К счастью, существуют простые, но мощные инструменты защиты: технологии SPF, DKIM и DMARC. Они позволяют проверять, действительно ли письмо пришло с авторизованного сервера, не было ли оно подменено и как следует поступать с сомнительными сообщениями. Есть и другие механизмы защиты, которые мы описывали ранее. При правильной настройке они защищают бренд, клиентов и сотрудников от поддельных писем.
Почему подделка почты — угроза
Киберпреступники давно используют электронную почту как главный канал для атак. Подделка отправителя (email spoofing) позволяет злоумышленнику отправить письмо, которое визуально выглядит легитимным — например, как сообщение от коллеги, клиента, банка или госоргана. Даже технически подкованный пользователь может не заметить подвоха, если домен и имя отправителя кажутся знакомыми.
Поддельные письма могут использоваться:
- Для фишинга. Получатель вводит логин и пароль на поддельной странице, думая, что это служба поддержки или корпоративный портал.
- Для распространения вредоносных программ. Вложения или ссылки ведут к установке троянов, шифровальщиков, кейлоггеров.
- Для выманивания денег. Атаки типа BEC (Business Email Compromise) заставляют сотрудников переводить средства «партнёрам» или «директорам».
- Для атаки на доверие. Если от имени вашей компании рассылаются поддельные письма, это бьёт по репутации и подрывает доверие клиентов.
Характерный пример — инцидент, произошедший в III квартале 2023 года с американским холдингом MGM Resorts International. Атакующие начали с фальшивого письма, отправленного в ответ на подтверждение бронирования в отеле. Далее, установив доверительный контакт с сотрудником, они прислали ссылку на вредоносный файл под видом документов. В результате им удалось проникнуть в инфраструктуру, похитить данные и получить доступ к системам бронирования. Ущерб оказался не только финансовым — скомпрометированы были и персональные профили клиентов, которые позже использовались для новых атак.
Этот случай иллюстрирует ключевую мотивацию фишинговых атак. Согласно исследованию SlashNext, во второй половине 2024 года количество атак, направленных на кражу учётных данных, увеличилось на 703%.
Рисунок 1. Рост атак с целью кражи данных
Источник: SlashNext
Без надлежащей защиты любой почтовый домен может быть подделан — особенно если не настроены SPF, DKIM и DMARC. Эти технологии не только делают подделку более сложной, но и позволяют другим серверам отклонять сомнительные письма.
SPF: контроль отправителей
SPF (Sender Policy Framework) — это технология, позволяющая владельцу домена указать, какие серверы имеют право отправлять почту с обратными адресами в этом домене. Она работает на уровне системы доменных имён (DNS) и помогает почтовым серверам принимать решение: стоит ли доверять письму или, наоборот, пометить его как подозрительное.
Смысл SPF прост: в доменной зоне прописывается перечень авторизованных IP-адресов или имён. При получении письма сервер получателя сверяет IP-адрес отправителя с этим списком. Если адрес не входит в список разрешённых — письмо может быть помечено как спам или вовсе отклонено.
Пример SPF-записи:
«v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all»
Здесь указано, что разрешается отправка с IP-адресов из диапазона «192.0.2.0/24», а также с серверов Google. Всё остальное — отклоняется («-all»).
Настройка SPF требует:
- указания SPF-записи в DNS домена с перечнем разрешённых почтовых серверов,
- включения в эту запись IP-адресов или доменов, которым разрешена отправка почты от имени домена,
- проверки получающим сервером соответствия IP-адреса отправителя данным в SPF-записи.
SPF защищает от подделки доменов на уровне DNS, но у него есть слабости. Он не защищает содержимое письма и может не сработать при пересылке через промежуточные серверы — в таких случаях SPF-проверка часто проваливается, даже если письмо отправлено с разрешённого домена.
Чтобы это обойти, используется технология SRS (Sender Rewriting Scheme), которая переписывает адрес отправителя так, чтобы SPF-проверка могла пройти успешно и после пересылки. Тем не менее, одной SPF-технологии недостаточно для полноценной защиты — она должна использоваться в сочетании с другими механизмами, такими как DKIM и DMARC.
DKIM: защита содержимого письма с помощью цифровой подписи
DKIM (DomainKeys Identified Mail) дополняет SPF и решает его ключевую проблему — защищает содержимое письма от подмены. Технология использует криптографическую подпись, которую отправляющий сервер добавляет в заголовки сообщения. Получатель сверяет подпись с открытым ключом в DNS-записи домена — и если всё сходится, письмо считается подлинным.
Вот как это работает: при отправке письма сервер использует приватный ключ для создания цифровой подписи. Эта подпись добавляется в заголовок письма, который обычно называется «DKIM-Signature». После получения письма сервер получателя обращается к DNS-записи домена, чтобы получить соответствующий открытый ключ, и с его помощью проверяет подлинность подписи.
Зачем нужен DKIM, если уже есть SPF? Потому что DKIM защищает именно содержимое письма, а не только факт отправки с «правильного» сервера. Если злоумышленник перехватит и изменит письмо, подпись больше не будет валидной, и письмо будет отклонено. Кроме того, DKIM успешно работает при пересылке — в отличие от SPF.
Пример DKIM-записи:
«default._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GC..."»
Здесь «default» — селектор (уникальный идентификатор), а «p=MIGfMA0GC...» — открытый ключ.
Настройка DKIM требует:
- генерации пары ключей (приватного и публичного),
- размещения публичного ключа в DNS-домене,
- настройки почтового сервера на подпись исходящих писем.
После внедрения DKIM каждое исходящее письмо будет снабжаться цифровой подписью, которую получатель сможет проверить. Это повышает доверие к письмам и снижает риск их блокировки или попадания в спам.
DMARC: настройка политики обработки и отчётов для поддельных писем
DMARC (Domain-based Message Authentication, Reporting and Conformance) — это технология, которая помогает домену не просто применять SPF и DKIM, но и управлять поведением почтовых серверов, если письмо не прошло эти проверки. Она создаёт слой политики и обратной связи, позволяя владельцам доменов увидеть, кто и как отправляет письма от их имени, и контролировать, что делать с сообщениями, не соответствующими критериям подлинности.
Принцип работы DMARC основан на синтезе результатов SPF и DKIM. Если хотя бы один из этих механизмов успешно срабатывает, а домен отправителя совпадает с доменом в записи, письмо считается легитимным. В противном случае DMARC-запись определяет дальнейшие действия: можно просто зафиксировать нарушение (режим «none»), поместить письмо в спам («quarantine») или отклонить его полностью («reject»). Такая гибкость позволяет постепенно вводить защиту: от мягкого мониторинга до жёсткой фильтрации подделок.
Важно, что DMARC не только защищает, но и даёт прозрачность. Благодаря отчётам, которые почтовые серверы присылают владельцу домена, можно узнать, кто ещё отправляет почту от имени домена, и какие письма не проходят проверку. Это особенно полезно для крупных организаций с несколькими поставщиками рассылок или сложной ИТ-инфраструктурой.
Для включения DMARC в DNS добавляется специальная текстовая запись. В ней указывается, как реагировать на письма с нарушениями, куда отправлять отчёты и какие параметры учитывать при проверке.
Такая запись может выглядеть так:
«v=DMARC1; p=quarantine; rua=mailto:dmarc@domain.com; adkim=s; aspf=s»
Политика «quarantine» в данном случае означает, что подозрительные письма должны быть перемещены в спам. Почтовый отчёт («rua») будет направлен по указанному адресу, а режимы «adkim» и «aspf» задают строгость сопоставления доменов для DKIM и SPF соответственно.
Настройка DMARC требует:
- наличия корректно настроенных SPF и DKIM для домена,
- создания DMARC-записи в DNS, в которой указывается политика обработки писем, не прошедших проверку (например, ничего не делать, пометить или отклонить),
- указания адреса для получения отчётов о проверках (RUA для агрегированных и RUF для форенсик-отчётов),
- выбора подходящего режима (none, quarantine или reject) в зависимости от степени готовности домена к строгой проверке.
Таким образом, DMARC становится финальным уровнем защиты, позволяя не только проверять техническую подлинность писем, но и отслеживать нарушения, усиливать контроль над доставкой и снижать риск фишинга.
Пошаговая настройка SPF, DKIM и DMARC в DNS — инструкция для админов
Все три технологии опираются на DNS-записи, и важно, чтобы они не только работали по отдельности, но и корректно взаимодействовали между собой.
Первый шаг — это создание SPF-записи.
Чтобы настроить SPF:
- Нужно перейти в настройки DNS вашего домена (например, у регистратора домена или в панели хостинга).
- Создать новую TXT-запись с именем «@» (или с вашим доменом).
- В поле значения указать SPF-запись. Вот пример для популярного сервиса Google Workspace:
«v=spf1 include:_spf.google.com ~all»
Часть «v=spf1» — указывает на версию SPF, «include:_spf.google.com» разрешает отправлять письма с серверов Google, а «~all» — обозначает мягкое отклонение (помещение в спам) для всех остальных отправителей.
Если используются несколько сервисов (например, почта + сервис рассылок), нужно включить их SPF-записи через дополнительные «include». Всего их может быть до 10 штук.
- Сохранить изменения и ждать, пока DNS обновится.
В SPF-записи указываются все разрешённые источники, которые могут отправлять письма от имени домена. Например, если компания использует почтовый сервер и сторонний сервис рассылок, обе платформы должны быть включены в запись. Ошибка на этом этапе может привести к тому, что легитимные письма начнут блокироваться. Запись размещается в DNS-зоне домена и действует как фильтр на стороне получателя, сравнивая IP-адрес отправителя с заданными параметрами.
Затем подключается DKIM. Возьмём для примера тот же Google Workspace. Нужно сделать следующее:
- Открыть админ-консоль почтового сервиса.
- Перейти в раздел: «Приложения → Google Workspace → Gmail → Аутентификация электронной почты».
- Создать новую запись для выбранного домена, выбрав параметры ключа и префикс селектора. Будет создана пара ключей DKIM.
- Скопировать значения DKIM (название записи и публичный ключ) из окна «Аутентификация электронной почты».
- Добавить TXT-запись в DNS, заполнив поля «Хост» (название записи) и «Значение» (длинная строка, начинающаяся с «v=DKIM1; k=rsa; p=...».
- После добавления записи — включить подпись писем в админ-консоли с помощью функции «Начать аутентификацию».
Этот механизм требует генерации пары криптографических ключей: приватный остаётся на почтовом сервере, а публичный указывается в DNS-зоне. При отправке письма содержимое «подписывается» приватным ключом, а получатель проверяет эту подпись через публичный ключ в DNS. Важно, чтобы DKIM был активен на всех платформах, с которых отправляется почта — иначе часть писем останется неподписанной.
Финальный этап — внедрение DMARC.
Чтобы настроить DMARC:
- Нужно создать DMARC-запись и добавить её в домен. DMARC, как и остальные механизмы, настраивается через добавление специальной TXT-записи в DNS. Пример такой записи мы приводили в разделе «DMARC: политика и контроль» выше. Первыми нужно указывать теги «v» (версия протокола) и «p» (политика, на начальном этапе можно использовать «none», чтобы только собирать отчёты), а остальные теги допускается расположить в произвольном порядке.
- Проверить правильность записи. После добавления записи подождите, пока обновятся DNS-серверы, и проверьте её через любой онлайн-инструмент (см. раздел «Инструменты для проверки SPF, DKIM и DMARC» далее).
- Проанализировать отчёты. В течение нескольких дней вы начнёте получать отчёты. В них будет указано, какие письма проходят проверку, а какие — нет. Это позволит выявить конфигурационные ошибки или попытки подделки.
- Ужесточить политику. Когда будете уверены, что всё работает корректно, можно сменить «p=none» на «p=quarantine» (помещать сомнительные письма в спам) или «p=reject» (отклонять такие письма полностью).
Это как настройка правил игры: указывается, как почтовые сервера должны обращаться с письмами, не прошедшими SPF и DKIM, и куда отправлять отчёты.
Рисунок 2. Как работают SPF, DKIM и DMARC
Источник: Cyberimpact
Настройка SPF, DKIM и DMARC требует координации между ИТ, безопасностью и, иногда, внешними подрядчиками. Но этот процесс стоит затраченных усилий: правильно настроенная система не только защищает от подделок, но и повышает доверие. Ранее мы также писали о том, как защитить корпоративную почту от кибератак.
Типовые ошибки при настройке SPF, DKIM и DMARC и как их избежать
Даже после активации SPF, DKIM и DMARC безопасность электронной почты может оставаться уязвимой. Причина — ошибки настройки, недоработки в сопровождении этих механизмов. Многие компании сталкиваются с одними и теми же проблемами, из-за которых защита либо не работает, либо даёт ложные срабатывания.
Одна из наиболее частых ошибок — конфликты в DNS-записях. Например, если в домене настроено несколько SPF-записей, это нарушает RFC-стандарты и приводит к тому, что проверка не проходит. Ещё одна типичная ситуация — рассогласование между серверами отправителя и получателя по части DKIM: письмо уходит, но не содержит действительной подписи, и получатель его отклоняет.
Не менее опасна слабая политика DMARC. Многие администраторы ограничиваются режимом «none», который лишь собирает отчёты, но не защищает от подделок. Такой подход может быть оправдан на этапе тестирования, но если политика остаётся в режиме мониторинга месяцами, злоумышленники могут продолжать использовать домен для фишинга без последствий.
Также нередко возникают сбои и ошибки при использовании сторонних сервисов (например, CRM-систем или рассыльщиков). Если их домены не добавлены в SPF или не согласованы с DMARC, они будут блокироваться.
Отдельная проблема — игнорирование DMARC-отчётов. Там содержатся данные о том, кто и с каких IP-адресов отправлял письма от имени домена, и как они прошли проверки. Без анализа этих отчётов администратор не узнает о попытках подделки или ошибках в настройке.
Все эти ошибки делают защиту неэффективной. Поэтому важно не просто настроить технологии, но и регулярно их проверять, особенно после изменений в инфраструктуре или добавления новых сервисов рассылки.
Онлайн-инструменты для проверки SPF, DKIM и DMARC: что выбрать
Даже при правильной настройке SPF, DKIM и DMARC важно регулярно проверять, что записи работают корректно, а письма проходят все проверки. Для этого существуют десятки инструментов, как от крупных вендоров, так и от независимых разработчиков. Они помогают быстро выявлять ошибки, конфликты и недочёты.
- MxToolbox SuperTool — один из самых популярных наборов инструментов. Он позволяет проверить записи SPF, DKIM и DMARC, увидеть, как они интерпретируются серверами, и даёт рекомендации по исправлению. Также сервис показывает, находится ли ваш домен в чёрных списках, что особенно важно для корпоративной почты.
- Google Postmaster Tools полезен тем, кто активно работает с Gmail. Сервис показывает, как Google оценивает репутацию домена, насколько письма соответствуют требованиям SPF и DKIM, и позволяет отследить уровень доставляемости.
- DMARC Analyzer — это инструмент, который специализируется на политиках DMARC. Он помогает собрать и визуализировать отчёты, разобраться в причинах отклонений, а также постепенно перейти из режима «none» в строгий «reject» без риска потерь.
- Mail Tester подойдёт тем, кто хочет быстро протестировать подготавливаемое к рассылке письмо. Сервис оценивает вероятность попадания в спам и указывает на технические проблемы в заголовках и теле письма.
- Дополнительно можно использовать DNSViz для визуального анализа DNS-записей и CheckTLS, если нужно проверить, как защищено соединение между серверами.
Использование этих инструментов не требует глубоких технических знаний, но даёт реальную картину состояния вашей почтовой безопасности. Регулярная проверка помогает избежать скрытых ошибок, которые могут стать причиной утери писем или компрометации домена.
Выводы
Защита корпоративной почты — не опция, а прямая необходимость в условиях растущей активности фишеров и спамеров. Домены, где не настроены SPF, DKIM и DMARC, остаются уязвимыми для подделки, а значит — под ударом клиенты и партнёры, налицо репутационные риски.
Хорошая новость в том, что настройка этих технологий доступна даже небольшим компаниям. Достаточно немного разобраться в логике работы DNS-записей, воспользоваться пошаговыми инструкциями и бесплатными инструментами проверки. Важно не только настроить SPF, DKIM и DMARC, но и регулярно контролировать их работу, анализировать отчёты и своевременно вносить правки.
Простой набор записей в DNS способен закрыть один из самых опасных векторов атак — подделку почтовых сообщений. Это — основа цифровой гигиены, от которой зависит не только информационная безопасность, но и доверие к бренду.
