Сотруднику приходит письмо от генерального директора с просьбой срочно оплатить счёт. Имя знакомое, корпоративный адрес на месте, подпись выглядит убедительно. Через несколько минут деньги могут уйти мошенникам. Но как проверить, действительно ли сообщение отправила компания, а не злоумышленник, который просто подставил чужой адрес?
Для защиты от подделки отправителя существуют три механизма электронной почты, SPF, DKIM и DMARC. Первый проверяет, имеет ли почтовый сервер право отправлять сообщения от определённого домена. Второй подтверждает криптографическую подпись письма. Третий сопоставляет результаты проверок с адресом, который видит получатель, и позволяет владельцу домена задать правила обработки подозрительной корреспонденции.
Но есть неприятная особенность. Письмо может успешно пройти все три проверки и всё равно оказаться фишинговым. А совершенно законное сообщение иногда получает DMARC fail и попадает в спам. Поэтому разберём реальные сценарии, научимся читать служебные заголовки и настроим защиту без риска заблокировать собственную почту.
Все адреса и IP-адреса в технических примерах условные. Проверять публичные DNS-записи разрешается без доступа к чужой почтовой инфраструктуре. Тестировать подмену отправителя следует только на собственных доменах или с разрешения владельца. Не загружайте корпоративные письма в публичные анализаторы без согласования, поскольку заголовки могут раскрывать служебные адреса, маршруты доставки и другую внутреннюю информацию.
Как проверить подозрительное письмо по заголовкам
Обычный почтовый клиент показывает лишь небольшую часть информации. Имя отправителя, адрес, тему, дату и текст сообщения. Для технической проверки нужен полный исходник письма, включая служебные заголовки.
В Gmail откройте сообщение в браузере, нажмите на три точки рядом с кнопкой ответа и выберите «Показать оригинал». Откроется страница с исходным сообщением и результатами аутентификации.
В новом Outlook и Outlook в браузере откройте меню дополнительных действий и выберите «Просмотр», затем «Просмотр сведений о сообщении» (View message details). В классическом Outlook для Windows откройте письмо отдельным окном, перейдите в «Файл», затем в «Свойства». Заголовки находятся в поле «Заголовки Интернета» (Internet headers).
Ищите четыре основных поля.
- From показывает адрес предполагаемого автора письма. Именно на него обычно ориентируется получатель.
- Return-Path обычно содержит адрес возврата недоставленных сообщений, связанный с SMTP-конвертом. Его домен может отличаться от видимого отправителя.
- DKIM-Signature содержит данные цифровой подписи, включая домен, селектор ключа и подписанные части сообщения.
- Authentication-Results сообщает, как почтовая система оценила SPF, DKIM и DMARC.
Предположим, сотрудник получил письмо якобы от бухгалтерии company.example. В исходном сообщении обнаружились такие строки.
From: "Бухгалтерия" <billing@company.example>
Return-Path: <bounce@mailer.example>
Authentication-Results: mx.recipient.example;
spf=pass smtp.mailfrom=mailer.example;
dkim=pass header.d=mailer.example;
dmarc=fail header.from=company.exampleСразу бросаются в глаза два успешных результата. SPF пройден, DKIM тоже. Можно подумать, что отправитель подтверждён. На практике обе проверки подтвердили только домен mailer.example.
SPF установил, что сервер имеет право отправлять сообщения от имени mailer.example. DKIM подтвердил цифровую подпись того же домена. Но сотрудник видит адрес billing@company.example.
Ни одна успешная проверка не подтверждает право использовать домен company.example. Поэтому DMARC, при условии что для домена действует соответствующая политика, возвращает fail.
Перед нами подозрительная ситуация, но не безусловное доказательство мошенничества. Компания могла поручить рассылку стороннему сервису и забыть согласовать домены. Технически результат будет таким же.
Теперь посмотрим на другую версию сообщения.
From: "Бухгалтерия" <billing@company.example>
Return-Path: <bounce@mailer.example>
Authentication-Results: mx.recipient.example;
spf=pass smtp.mailfrom=mailer.example;
dkim=pass header.d=company.example;
dmarc=pass header.from=company.exampleПисьмо по-прежнему отправлено через сторонний сервис. SPF подтверждает домен сервиса, зато DKIM теперь проверяет подпись company.example. DMARC успешно проходит проверку.
Важнейший принцип работы DMARC заключается в том, что SPF и DKIM не обязаны проходить одновременно. Достаточно, чтобы хотя бы один механизм успешно проверил домен, согласованный с адресом в поле From.
Для быстрой диагностики удобно использовать следующую таблицу.
| SPF | DKIM | DMARC | Интерпретация |
|---|---|---|---|
| pass | pass | pass | Аутентификация прошла, минимум один механизм согласован с видимым доменом отправителя. Безопасность содержимого не гарантируется. |
| pass | pass | fail | Технические домены подтверждены, но ни один не согласован с доменом From. |
| fail | pass | pass | Возможный результат при пересылке, когда SPF перестал работать, а согласованная подпись DKIM сохранилась. |
| pass | none | pass | DKIM отсутствует, но успешного согласованного SPF достаточно. |
| fail | fail | fail | Ни один механизм не подтвердил использование домена From. Возможны подделка и ошибки настройки. |
Таблица отражает типичные ситуации, а не все возможные комбинации. Результат none означает отсутствие соответствующей проверки или применимой политики, temperror обычно связан с временной ошибкой, а permerror указывает на ошибку, которая вряд ли исчезнет без исправления настроек.
Есть дополнительная ловушка. Заголовок Authentication-Results сам по себе не защищён от подделки. Отправитель способен заранее вписать туда любые значения, включая три pass. Поэтому доверять следует результатам собственного принимающего сервера или доверенного почтового шлюза. Для обычного пользователя надёжнее смотреть встроенную проверку почтового провайдера, чем самостоятельно считать каждую найденную строку подлинной.
Как работают SPF, DKIM и DMARC
SPF проверяет отправляющий сервер
Sender Policy Framework позволяет владельцу домена через DNS указать, какие серверы вправе отправлять почту с использованием его домена в SMTP-конверте.
Представим компанию с собственным почтовым сервером и внешней платформой рассылок. Администратор публикует TXT-запись.
v=spf1 ip4:192.0.2.10 include:_spf.mailer.example -allЗдесь v=spf1 обозначает формат записи. Механизм ip4 разрешает указанный IP-адрес. Механизм include позволяет использовать правила стороннего почтового провайдера. Завершающее -all обозначает, что остальные источники не авторизованы.
Вместо -all часто встречается ~all, который возвращает более мягкий результат softfail. Ни один вариант сам по себе не гарантирует, что принимающий сервер отклонит сообщение. SPF возвращает результат аутентификации, а окончательное решение остаётся за получателем.
Проверка использует IP-адрес сервера, подключившегося по SMTP, и домен из команды MAIL FROM. При пустом обратном адресе применяется специальное правило с идентификатором HELO/EHLO. При этом SPF не обязан проверять домен, указанный в видимом поле From.
Вторая проблема связана с пересылкой. Сообщение первоначально отправлено авторизованным сервером, но затем проходит через другой узел. Получатель видит IP-адрес пересылающего сервера, которого может не быть в SPF-записи исходного домена. Результат SPF становится отрицательным, хотя отправитель ничего не подделывал.
Некоторые системы решают проблему с помощью Sender Rewriting Scheme, сокращённо SRS, меняя обратный адрес при пересылке. Но после такого изменения SPF подтверждает уже домен пересылающего сервера, поэтому одного SPF недостаточно для подтверждения исходного домена в DMARC.
DKIM проверяет цифровую подпись письма
DomainKeys Identified Mail работает иначе. Почтовая система подписывает содержимое и выбранные заголовки сообщения закрытым криптографическим ключом. Получатель берёт открытый ключ из DNS и проверяет подпись.
В исходнике письма можно встретить такой сокращённый заголовок.
DKIM-Signature: v=1; a=rsa-sha256;
d=company.example;
s=mail;
c=relaxed/relaxed;
h=from:to:subject:date;
bh=...;
b=...Параметр d= указывает домен подписанта, s= задаёт селектор для поиска ключа. Параметр h= перечисляет подписанные заголовки, bh= содержит хеш тела письма, а b= цифровую подпись.
Параметр c=relaxed/relaxed задаёт способ нормализации заголовков и тела сообщения перед проверкой. Такой режим допускает определённые изменения пробелов и форматирования, не нарушающие подпись. Однако существенное изменение подписанного содержимого обычно приводит к ошибке DKIM.
Для приведённого примера открытый ключ ищут в DNS по адресу mail._domainkey.company.example. В зависимости от почтового провайдера там может находиться TXT-запись с ключом или CNAME, указывающий на обслуживаемый провайдером домен.
DKIM не подтверждает личность конкретного человека. Успешная подпись означает, что определённый домен взял криптографическую ответственность за подписанные данные. Если злоумышленник получил доступ к действующей корпоративной учётной записи, почтовая система вполне может подписать его вредоносное письмо легальным ключом.
Для RSA-подписей рекомендуется ключ длиной не менее 2048 бит, если почтовая инфраструктура поддерживает такой вариант. Подписи RSA с ключами короче 1024 бит не должны считаться действительными, а алгоритм rsa-sha1 исключён из допустимых способов подписи.
DMARC связывает результаты с видимым отправителем
Domain-based Message Authentication, Reporting, and Conformance решает проблему, которую SPF и DKIM по отдельности не закрывают.
DMARC сравнивает домен из поля From с доменом, успешно проверенным через SPF или DKIM. Такое соответствие называется alignment, или согласованием идентификаторов.
По умолчанию действует мягкое согласование relaxed. Например, при обычной структуре доменов news.company.example и company.example считаются согласованными, поскольку относятся к одному организационному домену.
Строгое согласование strict требует точного совпадения доменов. Режимы управляются параметрами aspf=s для SPF и adkim=s для DKIM.
Владелец домена публикует DMARC-политику в TXT-записи по адресу _dmarc.company.example.
v=DMARC1; p=none; rua=mailto:dmarc-reports@company.exampleПараметр p= определяет, как владелец домена предлагает обрабатывать сообщения, не прошедшие DMARC.
| Политика | Практический смысл |
|---|---|
| p=none | Режим наблюдения. Владелец домена не запрашивает особую обработку писем с ошибкой DMARC. |
| p=quarantine | Рекомендация считать такие письма подозрительными, например помещать в спам. |
| p=reject | Рекомендация отклонять сообщения, не прошедшие проверку. |
Параметр rua= задаёт адрес агрегированных отчётов. Принимающие серверы, которые поддерживают отправку таких отчётов, могут передавать статистику по источникам писем, результатам SPF и DKIM, согласованию доменов и количеству сообщений.
Почтовые провайдеры не обязаны безусловно выполнять политику DMARC. Проверки отправителя работают вместе с фильтрацией спама, анализом репутации и другими правилами. Поэтому p=reject не превращает домен в неприступную крепость, а p=none не гарантирует доставку всех поддельных сообщений.
В мае 2026 года обновили стандарт DMARC. RFC 9989 заменил прежний RFC 7489, сохранив знакомый формат v=DMARC1. Обновление изменило алгоритм поиска организационного домена, ввело параметр np для политики несуществующих поддоменов и параметр t для тестового режима. Старый параметр pct, которым пытались применять политику к определённому проценту сообщений, исключён. Старые инструкции с pct=10 больше не стоит использовать как образец новой настройки.
Новые параметры могут игнорироваться реализациями, которые ещё работают по прежней спецификации. Поэтому надёжнее начинать развёртывание с настоящего p=none, а не рассчитывать, что все получатели одинаково обработают t=y.
Почему фишинговые письма иногда проходят все проверки
SPF, DKIM и DMARC способны выявлять несанкционированное использование почтового домена. Но технологии не проверяют, правдив ли текст письма, безопасна ли ссылка и действительно ли распоряжение исходит от руководителя.
Сценарий первый. Мошенник зарегистрировал похожий домен
Настоящая организация использует company.example, а злоумышленник регистрирует визуально похожий домен. Например, меняет одну букву, добавляет слово или использует похожие символы другого алфавита.
После регистрации мошенник самостоятельно настраивает SPF, DKIM и DMARC. Письма проходят все проверки, поскольку злоумышленник действительно контролирует собственный домен.
Почтовый сервер не обязан определять, что company-payments.example пытается выдать себя за company.example. Для DMARC перед нами два независимых домена.
Поэтому при подозрении на подмену нужно сравнивать полный адрес отправителя с известным корпоративным адресом, а не только смотреть на результаты аутентификации.
Сценарий второй. Фишинг отправлен через настоящий сервис
Некоторые атаки вообще обходятся без технической подделки адреса. Злоумышленник регистрируется в легальном облачном сервисе, создаёт документ или приглашение и просит платформу отправить уведомление потенциальной жертве.
Летом 2026 года такую схему использовали против корпоративных пользователей Notion. Мошенники создавали бесплатные аккаунты, представлялись руководителями компаний и отправляли сотрудникам уведомления о якобы предоставленном доступе к документу. Далее жертву вели к поддельной странице, предназначенной для кражи токенов доступа.
Письма проходили SPF, DKIM и DMARC, поскольку уведомления действительно отправляла инфраструктура Notion. Подробности атаки через Notion хорошо показывают границу возможностей почтовой аутентификации. Проверки подтверждали платформу отправки, а не правдивость приглашения.
Аналогичный принцип работает при злоупотреблении другими легальными сервисами документов, приглашений или совместной работы. Почтовая аутентификация не заменяет проверку действий пользователя и адресов, на которые ведут ссылки.
Сценарий третий. Взломали настоящий почтовый ящик
Злоумышленник получил доступ к корпоративной почте через украденный пароль, сеансовый токен или другое нарушение защиты учётной записи. Затем отправил письмо от имени владельца ящика.
Сообщение проходит через разрешённый почтовый сервер и получает корректную DKIM-подпись. Все три проверки могут закончиться успехом, хотя письмо написано преступником.
Особенно опасен такой вариант при мошенничестве с платежами и реквизитами. Получатель видит прежнюю переписку, знакомый адрес и правильную цифровую подпись. Ни SPF, ни DKIM, ни DMARC не умеют определять, кто физически нажал кнопку отправки после успешной авторизации.
Против такого сценария нужны дополнительные меры. Многофакторная аутентификация, контроль подозрительных входов, защита сессий, анализ необычной переписки и независимое подтверждение финансовых распоряжений.
Сценарий четвёртый. Законное письмо потеряло аутентификацию при пересылке
Теперь противоположная ситуация. Компания отправила настоящее письмо с правильными SPF и DKIM. Сообщение попало в список рассылки, который добавил служебный текст в тему, изменил тело письма или дописал собственный блок в конце.
Изменение подписанных частей может нарушить DKIM. Пересылающий сервер одновременно изменяет маршрут доставки, из-за чего SPF исходного домена перестаёт проходить проверку.
В результате получатель видит DMARC fail, хотя первоначальный отправитель не был мошенником.
Для подобных ситуаций существует механизм Authenticated Received Chain, или ARC. Промежуточные серверы могут сохранять сведения о предыдущих проверках в подписанной цепочке. Конечный получатель использует такие данные при оценке письма, если доверяет соответствующим участникам доставки.
ARC не гарантирует успешной доставки и не подтверждает безопасность сообщения. Поддержка и доверие к цепочке зависят от конкретной почтовой инфраструктуры. Поэтому для важных рассылок лучше обеспечить устойчивую DKIM-подпись и заранее проверить доставку через используемые пересылки и списки рассылки.
Отдельного внимания заслуживает поле Reply-To. Оно задаёт адрес для ответа и может отличаться от From даже в законной корреспонденции. Но если письмо от бухгалтерии требует отправить платёжные документы на неизвестный внешний домен, такой адрес нужно проверить независимо. Успешный DMARC не делает любой адрес ответа доверенным.
Как настроить SPF, DKIM и DMARC и проверить результат
Публикация трёх DNS-записей ещё не означает, что почтовая система правильно настроена. Администратор должен учесть все источники отправки, включая корпоративную почту, CRM, сайт, мониторинг серверов, технические уведомления и внешние рассылки.
Начните с проверки уже опубликованных записей.
В Windows откройте PowerShell и выполните команды, заменив company.example собственным доменом.
Resolve-DnsName -Name company.example -Type TXT
Resolve-DnsName -Name _dmarc.company.example -Type TXT
Resolve-DnsName -Name mail._domainkey.company.example -Type TXTДля Linux и macOS удобна утилита dig, если установлена.
dig +short TXT company.example
dig +short TXT _dmarc.company.example
dig +short TXT mail._domainkey.company.exampleВ последней команде mail обозначает селектор DKIM. Настоящее значение нужно искать в параметре s= заголовка DKIM-Signature. Если провайдер использует CNAME, потребуется проверить и целевой домен.
При просмотре результатов обращайте внимание на следующие проблемы.
Несколько SPF-записей. У одного DNS-имени должна быть только одна SPF-политика формата v=spf1. Если администратор добавил отдельную запись для корпоративной почты и ещё одну для рассылок, принимающая система получит permerror. Разрешённые источники необходимо объединить в одну SPF-запись. Прочие TXT-записи, не относящиеся к SPF, могут находиться рядом.
Слишком много DNS-проверок. SPF ограничивает число механизмов и модификаторов, требующих DNS-поиска, десятью за одну проверку политики. В лимит входят в том числе include, a, mx, exists и redirect, включая вложенные вызовы. Механизмы ip4 и ip6 такой лимит не расходуют. Превышение приводит к permerror. Простое подсчитывание слов include в одной строке не заменяет проверки всей цепочки.
DKIM подписывает чужим доменом. Сторонний сервис может успешно подписывать рассылку своим ключом, но такая подпись не будет согласована с корпоративным доменом. Нужно включить подпись от имени домена компании или его допустимого поддомена через настройки почтового провайдера.
DMARC есть, но работает только наблюдение. Запись с p=none подходит для диагностики. Однако она не запрашивает карантин или отклонение писем с ошибкой аутентификации. Наличие записи не равнозначно включённой защите от прямой подделки.
Забыли поддомены. Политика организационного домена может распространяться на поддомены, а параметр sp позволяет задать для существующих поддоменов отдельный режим. В обновлённом стандарте параметр np предназначен для несуществующих поддоменов. Но на поддержку новых параметров всеми принимающими системами рассчитывать нельзя. Для критичных отправляющих поддоменов полезно публиковать собственные DMARC-записи.
С чего начать настройку собственного домена
Сначала составьте полный список систем, которые действительно отправляют почту. Для каждой выясните домен SMTP-конверта, используемый DKIM-домен и адрес в поле From. Проверьте соответствие доменов, а не просто наличие SPF и DKIM.
Затем настройте DKIM для корпоративного домена и убедитесь, что новые письма успешно проходят проверку у внешнего получателя. Удостоверьтесь, что SPF включает все разрешённые источники и не превышает ограничение DNS-поисков.
После этого опубликуйте DMARC в режиме наблюдения.
v=DMARC1; p=none; rua=mailto:dmarc-reports@company.exampleАдрес для отчётов должен существовать и принимать почту. Агрегированные отчёты обычно приходят в машиночитаемом формате XML, нередко в сжатом архиве. По ним можно определить IP-адреса источников, количество писем, результаты аутентификации и проблемы согласования доменов.
Не ждите, что отчёты покажут полный текст каждого поддельного письма или перечень всех злоумышленников. Получатели отправляют данные добровольно, а статистика отражает только наблюдаемую ими почту.
Отдельный параметр ruf может запрашивать подробные отчёты об отдельных неудачных проверках, но крупные провайдеры часто ограничивают такую функцию из-за риска раскрытия персональных данных и содержимого сообщений. Для обычного внедрения DMARC агрегированных отчётов достаточно.
После сбора статистики исправьте ошибки легальной почты. Если сотрудники отправляют сообщения в интернет-списки рассылки, отдельно проверьте доставку через такие списки. Слишком ранний переход к p=reject способен привести к потере законной корреспонденции.
Для доменов с обычными пользовательскими почтовыми ящиками разумно наблюдать за результатами p=none не меньше месяца, затем примерно столько же проверять режим p=quarantine. Переход к p=reject оправдан прежде всего там, где администратор хорошо контролирует все источники отправки и последствия пересылки. Для доменов, пользователи которых регулярно участвуют в публичных списках рассылки, строгая политика может оказаться проблемной даже при корректном DKIM.
У доменов, которые вообще не должны отправлять почту, ситуация проще. Если отправка действительно отсутствует, можно опубликовать запрещающую SPF-политику и строгую DMARC-политику.
company.example TXT "v=spf1 -all"
_dmarc.company.example TXT "v=DMARC1; p=reject; sp=reject"Такой вариант нельзя бездумно переносить на рабочий домен, где отправляют письма сотрудники, сайт или сторонние приложения. Также нужно учитывать, что принимающие системы самостоятельно решают, как учитывать опубликованные политики.
Для массовой почты проверки стали обязательной частью нормальной доставки. Gmail и Outlook.com предъявляют отправителям крупных объёмов требования к SPF, DKIM и DMARC. Для массовых рассылок в Gmail действуют также требования к репутации отправителя, частоте жалоб и механизму отказа от подписки. Одних правильных DNS-записей недостаточно, чтобы письма гарантированно попадали во входящие.
Завершить настройку стоит реальным тестом. Отправьте письмо из каждой корпоративной системы на внешний почтовый ящик, откройте оригинал и проверьте домены в результатах SPF и DKIM. Убедитесь, что DMARC показывает pass. Затем проверьте доставку через используемые пересылки и платформы рассылок. Успешная DNS-проверка без реального письма не даёт полной картины.
Частые вопросы
Почему письмо с DMARC fail всё равно попало во входящие?
Почтовый сервис может не выполнять политику отправителя буквально. При p=none владелец домена вообще не запрашивает особой обработки. Даже при p=reject получатель учитывает собственные правила, репутацию и другие сигналы. Попадание во входящие не доказывает успешную аутентификацию.
Что означает dmarc=none и чем отличается от dmarc=fail?
DMARC none обычно означает, что для домена не найдена применимая DMARC-политика. DMARC fail означает, что политика существует, но сообщение не прошло требуемую проверку согласования доменов. Отсутствие политики нельзя считать доказательством подделки.
Почему в одном письме встречаются несколько DKIM-Signature?
Сообщение могут подписывать несколько систем, например корпоративный почтовый сервер и платформа рассылки. Каждая подпись проверяется отдельно. Для успешного DMARC достаточно хотя бы одной действительной DKIM-подписи с согласованным доменом, даже если другие подписи не прошли проверку.
Наследуют ли поддомены SPF-запись основного домена?
Нет. SPF проверяется для конкретного домена SMTP-конверта. Запись основного домена автоматически не становится SPF-политикой его поддоменов. Для используемых поддоменов нужно проверить собственные записи или предусмотренную архитектурой почтового сервиса настройку.
Может ли DKIM-подпись быть правильной, если адреса отправителя не существует?
Да. DKIM подтверждает право подписывающей системы использовать домен и целостность подписанных данных, но не проверяет существование конкретного почтового ящика до символа @. DMARC также работает с доменом, а не с индивидуальной личностью автора.
Чем SPF, DKIM и DMARC отличаются от S/MIME и PGP?
SPF, DKIM и DMARC предназначены прежде всего для аутентификации почтовых доменов и управления обработкой сообщений. S/MIME и OpenPGP могут обеспечивать подпись на уровне отправителя и шифрование содержимого письма при соответствующей настройке и управлении ключами. DKIM не заменяет сквозное шифрование переписки.
Можно ли защитить домен от всех поддельных писем с помощью p=reject?
Нет. Строгая политика снижает риск прямой подделки домена у получателей, которые правильно применяют DMARC, но не защищает от похожих доменов, компрометации почтовых ящиков и мошеннических сообщений, отправленных через легальные сервисы. Кроме того, строгая политика может затронуть законные письма при пересылке.
Вывод. SPF, DKIM и DMARC действительно помогают бороться с подделкой электронной почты, но решают задачу аутентификации домена, а не проверки добросовестности человека. Для администратора лучший первый шаг заключается в анализе реальных писем и DMARC-отчётов, затем в исправлении согласования доменов и осторожном усилении политики. Для обычного пользователя полезнее всего научиться смотреть полный адрес отправителя и результаты аутентификации, не принимая три pass за гарантию безопасности. Если письмо требует перевести деньги, изменить реквизиты или передать доступ, распоряжение нужно подтвердить через независимый канал связи, даже когда все технические проверки успешны.
