Основные выводы
В течение 24–72 часов после публикации записи DMARC приходит первый сводный отчет, который немедленно выявляет все легитимные и неавторизованные серверы, отправлявшие электронные письма от имени вашего домена в течение этого периода. Подвох, как описано в… DMARC.orgСогласно спецификации протокола, эти отчеты представляют собой XML-файлы машинного формата, предназначенные для автоматизированных анализаторов, а не для чтения людьми.
Умение читать отчеты DMARC превращает необработанные данные в оперативную информацию. Такая прозрачность действительно ценна, но только после того, как XML-данные будут расшифрованы и пригодны для принятия мер. Текущий статистика спама по электронной почте Покажите, почему такая прозрачность важна: подмена и выдача себя за другое лицо распространены, поэтому вам необходимы отчеты DMARC для определения того, какие источники отправляют электронные письма от имени вашего домена.
Первое прочтение занимает 15–30 минут. Последующие прочтения от тех же отправителей занимают 2–3 минуты, как только шаблон станет известен. Ниже описаны шаги по созданию полного сводного отчета DMARC от начала до конца.
Вот анонимизированный XML-фрагмент, иллюстрирующий структуру отчета, используемую на этапах проверки, описанных ниже:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email>
<report_id>10296513920663916120</report_id>
<date_range>
<begin>1716768000</begin>
<end>1716854400</end>
</date_range>
</report_metadata>
<policy_published>
<domain>yourdomain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>847</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>yourdomain.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>yourdomain.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>198.51.100.23</source_ip>
<count>312</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>unknownsender.net</domain>
<result>fail</result>
</dkim>
<spf>
<domain>unknownsender.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
</feedback>Убедитесь, что выделенный почтовый ящик собирает отчеты по адресу, указанному в теге rua= вашей записи DMARC (например, [электронная почта защищена]Почтовые провайдеры ежедневно отправляют сводные отчеты, поэтому даже домен с низкой загрузкой накапливает десятки XML-файлов в месяц; таким образом, общий почтовый ящик быстро становится неуправляемым.
Для небольших доменов, требующих периодической проверки, вполне подойдет выделенный почтовый ящик. Для чего-либо, кроме нескольких отчетов в неделю, или для организаций, управляющих несколькими доменами, укажите в теге rua= адрес для приема данных анализатором DMARC для автоматического анализа.
Загрузите прикрепленный файл из электронного письма с отчетом. Большинство отчетов приходят в виде архивов .xml.gz или .zip, которые необходимо предварительно распаковать (в macOS и Linux дважды щелкните по файлу или используйте gunzip; в Windows щелкните правой кнопкой мыши и выберите «Извлечь»).
Откройте полученный XML-файл в любом текстовом редакторе, например, VS Code, Sublime Text или Notepad++. Вы также можете открыть его в браузере, что часто упрощает просмотр XML-кода, поскольку разделы отображаются в виде сворачиваемых узлов, а не в виде одного длинного блока текста.
Для периодической проверки одного отчета вполне достаточно открыть XML-файл вручную. Если вы получаете больше нескольких отчетов в неделю, используйте автоматический парсер. Отчеты DMARC имеют согласованную структуру, поэтому инструменты могут преобразовывать XML-файл в таблицы и сводки гораздо быстрее.
Найдите Блок в верхней части файла. Он идентифицирует организацию, предоставляющую отчет (Google, Microsoft, Yahoo, Mail.ru или другие), и метки времени Unix для начала и конца окна отчета. Преобразование этих меток времени в читаемые даты подтверждает, какой 24-часовой период охватывает отчет.
Найдите Сразу после этого отображается блок. Он показывает политику DMARC, которая была активна в течение периода отображения отчета (p=нет, p=карантин или p=отклонить), а также режимы выравнивания для SPF (aspf) и DKIM (adkim). Значение r означает ослабленное выравнивание; s означает строгое.
Убедитесь, что политика, отображаемая в отчете, соответствует текущей записи DNS. Несоответствие означает, что отчет охватывает период до недавнего распространения изменений в политике, что является ожидаемым и не представляет проблемы, а лишь контекстом для интерпретации результатов.
Прокрутите до блоки. Каждая запись представляет собой один отправляющий IP-адрес и его результаты, сгруппированные по количеству сообщений. В приведенном выше фрагменте 209.85.220.41 отправил 847 сообщений и прошел проверку DMARC; 198.51.100.23 отправил 312 сообщений и не прошел проверку SPF и DKIM.
Для каждой записи зафиксируйте следующее: и IP-адрес определяет, какой сервер утверждал, что отправляет сообщения от имени вашего домена, а счетчик показывает, сколько сообщений поступило с этого сервера за время отображения отчета.
Выполните обратный DNS-запрос для каждого незнакомого IP-адреса источника. Легитимные отправители разрешаются в узнаваемые имена хостов (mail-sor-f41.google.com для Gmail, sendgrid.net для SendGrid и amazonses.com для AWS SES). Неузнаваемые IP-адреса требуют проверки, прежде чем считать их легитимными.
Внутри каждой записи найдите Этот блок содержит результаты SPF и DKIM для данного исходного IP-адреса, а также домен, который был оценен каждым методом аутентификации.
Для прохождения проверки DMARC достаточно, чтобы в целом сообщение прошло проверку DMARC хотя бы по одному из протоколов: SPF или DKIM, работающих в выровненном режиме. В этом поле отображается окончательный вердикт (нет, карантин или отказ) на основе политики, действовавшей в течение отчетного периода.
Помечайте любую запись, где и SPF, и DKIM показывают ошибку, хотя отправитель должен быть легитимным. Это означает неправильную настройку отправителя, которую необходимо исправить, прежде чем можно будет безопасно ужесточить политику. Запись, показывающая spf=fail, но dkim=pass, обычно считается допустимой, поскольку сообщение в целом проходит проверку DMARC.
Сводные отчеты DMARC соответствуют RFC 7489. Все соответствующие требованиям отчеты используют одинаковую структуру независимо от того, какой почтовый провайдер их отправил. Используйте эту ссылку на поле при проверке любого отчета:
Зная эти четыре шаблона, вы значительно упростите чтение отчетов DMARC. Вместо того чтобы просматривать огромный массив XML-данных, вы сможете отсортировать каждую запись по четко обозначенной категории.
Если в отчете указан известный отправитель, например, ваш поставщик услуг электронной почты, маркетинговая платформа, служба поддержки или CRM, и в обоих случаях присутствует dkim=pass и spf=pass, это означает, что настройка для этого источника работает корректно.
Проверьте, принадлежит ли исходный IP-адрес ожидаемому провайдеру, используя обратное DNS-запрос, особенно для большого количества записей. Ожидается большой объем почты с известного IP-адреса с параметром dmarc=pass. Подтвердите это один раз, а затем используйте в качестве базового показателя для будущих отчетов.
Отправка сотен или тысяч сообщений с dmarc=fail через незнакомые IP-адреса попадает в одну из двух категорий: неавторизованные отправители, активно подделывающие ваш домен, или забытый легитимный отправитель (старый маркетинговый инструмент, теневая ИТ-интеграция), который никогда не проходил надлежащую аутентификацию.
Для расследования проверьте записи WHOIS по IP-адресу и обратные DNS-записи. Известный спам-IP-адрес обычно указывает на подделку, в то время как забытая SaaS-платформа обычно указывает на проблему с аутентификацией. В этих двух случаях необходимы разные меры: блокировка или отклонение поддельных писем, но исправление выравнивания SPF или DKIM для легитимных отправителей.
Сообщение, не прошедшее проверку SPF, но прошедшее проверку DKIM, часто указывает на пересылку электронной почты. Сервер пересылки не указан в записи SPF отправителя, поэтому проверка SPF завершается неудачей. Но DKIM работает иначе. Он подписывает заголовки сообщения, и эта подпись часто остается неизменной при пересылке письма. Именно поэтому DKIM может пройти проверку, даже если проверка SPF не удалась.
В целом, DMARC проходит проверку, если совпадают SPF или DKIM, поэтому эти записи не представляют проблемы. Для доменов с получателями, использующими пересылку почты, это ожидаемое поведение. В отчете показано, как пересылка влияет на аутентификацию, а не сбой в настройке DMARC.
Классическим примером подделки IP-адреса является ситуация, когда ранее неизвестный IP-адрес внезапно начинает отправлять большой объем сообщений, при этом SPF и DKIM не срабатывают. Кто-то отправляет электронные письма, выдавая себя за отправителя с вашего домена, используя собственную инфраструктуру и пытаясь обойти спам-фильтры, заимствуя сигналы доверия вашего домена.
Проверьте IP-адрес в инструментах анализа угроз, таких как AbuseIPDB или Cisco Talos. Если IP-адрес связан со спамом или злоупотреблениями, всплеск активности, скорее всего, носит вредоносный характер. В этом случае переход к механизму p=reject становится важным. После того, как все легитимные отправители будут согласованы, полное принудительное применение мер помогает блокировать поддельные письма до того, как они смогут нанести ущерб вашим данным. репутация отправителя электронной почты.
Большинство команд переходят от ручного анализа XML-файлов к автоматизированному парсеру в течение первой недели после получения отчетов. Выбор зависит от объема работы, бюджета, а также от глубины необходимого анализа.
Для большинства начинающих команд практичным бесплатным решением является MXToolbox для периодических ручных проверок и Postmark DMARC Digests для пассивного мониторинга. Переход к специализированному анализатору, такому как DMARCian, возможен, когда количество доменов или объем ежедневных отчетов делают ручной анализ нецелесообразным.
Чтение отчетов DMARC полезно только в том случае, если вы используете их для принятия решений. Процесс прост: идентифицировать каждого отправителя, устранить проблемы с согласованием, а затем перейти к принудительному применению.
Укрепление связей в сочетании с тщательной очисткой списков рассылки. Аутентификация подтверждает, что электронное письмо отправлено именно вами, а чистые списки предотвращают высокий процент отказов, который негативно влияет на репутацию независимо от состояния аутентификации. Проверка списков перед крупными рассылками позволяет контролировать процент отказов. очистка вашего списка адресов электронной почты Удаление устаревших или недействительных контактов защищает репутационные сигналы, поддерживающие каждый этап продвижения политики.
Сводные отчеты DMARC — это оперативные данные. Суть не в том, чтобы читать их в теории, а в том, чтобы действовать на основе полученной информации. Исправляйте ошибки, связанные с легитимными отправителями, которые не соответствуют требованиям. Расследуйте незнакомые IP-адреса. Переходите к принудительному применению, когда ваши доверенные источники начнут стабильно проходить проверку.
Цель — получить скучный отчёт: известные источники, стабильный процент успешных проверок и отсутствие внезапных всплесков активности с неизвестных IP-адресов. Именно эта предсказуемость делает p=reject безопасным, а p=reject защищает ваш домен от подмены личности.
В рамках этапа согласования проверьте списки рассылки с помощью DeBounce. Проверка списка адресов электронной почты Удаляет недействительные, одноразовые и высокорисковые адреса из списков, используемых для отправки аутентифицированных сообщений, что снижает процент отказов и защищает репутацию, которую вы создаете с помощью аутентификации. Загрузите свой список, удалите ненужные адреса и отправляйте сообщения с уверенностью, что чистая аутентификация и чистые данные работают вместе.
Агрегированные отчеты представляют собой ежедневные XML-сводки, охватывающие все результаты аутентификации за отчетный период; аналитические отчеты — это оповещения в режиме реального времени об отдельных сообщениях, в которых произошла ошибка. Аналитические отчеты стали редкостью из-за соображений конфиденциальности: большинство поставщиков больше их не отправляют, и большинство команд полагаются исключительно на агрегированные отчеты.
Как правило, сводные отчеты рассылаются каждой организацией один раз в день за предыдущие 24 часа. Крупные поставщики, такие как Google и Microsoft, отправляют отчеты ежедневно; более мелкие поставщики могут отправлять их реже или не отправлять вовсе.
Либо в течение периода формирования отчета с домена не было отправлено ни одного электронного письма, либо адрес rua= настроен неправильно, и отчеты не попадают во входящие. Убедитесь, что тег rua= в записи DNS указан правильно, и почтовый ящик существует и принимает внешние письма.
В течение первых двух недель просматривайте несколько ежедневных отчетов, чтобы изучить закономерности поведения конкретных отправителей. После этого автоматизированные инструменты должны выявлять аномалии. Читайте полные отчеты только тогда, когда в сводной панели появляется что-то необычное.
Минимум 2–4 недели при p=none для инвентаризации всех отправителей, плюс еще 2–4 недели для подтверждения согласованности перед переходом к p=quarantine. Затем 2–4 недели при p=quarantine перед переходом к p=reject. Ужесточение требований только тогда, когда отчеты показывают стабильный процент успешного прохождения проверки в течение нескольких последовательных циклов отчетности.
Найдите быстрые ответы на ваши вопросы о наших ценах и планах.
Спам-ловушки — это реальные почтовые ящики, созданные или повторно используемые для выявления недобросовестных методов работы со списками рассылки. Попадание в них может нанести ущерб репутации отправителя и улучшить попадание писем в папку «Входящие». Электронная почта...
Лимит на отправку писем варьируется в зависимости от хостинга: от минутного до почасового и даже суточного. Знание точных лимитов в случае...
Список исключений — это база данных «не отправлять», которая предотвращает доставку электронных писем на определенные адреса. Список исключений играет важную роль...
Атаки BEC (Business Email Compromise) осуществляются исключительно за счет подмены личности и социальной инженерии, обходя большинство технических средств защиты, направленных на обнаружение вредоносного кода или подозрительных ссылок...
Динамическое содержимое электронных писем заменяет статичные, универсальные сообщения персонализированными блоками контента, которые адаптируются для каждого получателя на основе данных, поведения или сигналов в реальном времени. Вовлеченность...
Многие маркетологи электронной коммерции очень заинтересованы в инвестициях в email-маркетинг. Они расширяют свои списки, отправляя увлекательные email-кампании, чтобы привлечь посетителей или, что ещё лучше...
