#Что происходит и когда применима инструкция
DMARC-отчёты показывают неожиданные отказы аутентификации. Это может быть реальный поддельный отправитель, забытая легальная система рассылок или неверное выравнивание домена SPF/DKIM с адресом From. Разбирать нужно распределение источников, а не немедленно ослаблять политику.
#Основные причины и их признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Легальный сервис не выровнен по доменуSPF может проходить для чужого Return-Path, а DKIM подписываться доменом провайдера. | IP принадлежит CRM или рассылке, но DMARC fail | Настройте собственный домен подписи/возврата. |
| Поддельные письма от чужого сервераДомен подделывают злоумышленники; отдельные SPF/DKIM fail здесь ожидаемы. | В отчёте IP не принадлежит вашим системам | Отслеживайте источники и не разрешайте лишние IP. |
| Проблемы подписи при пересылкеПересылка меняет источник, а модификация письма может нарушать подпись. | SPF fail после форвардинга, а DKIM тоже не проходит | Проверьте маршруты и правила изменения сообщений. |
#Пошаговая диагностика и устранение
- Уточните назначение отчётаОткройте DNS TXT
_dmarc.example.comи найдитеp=,rua=,aspf=,adkim=. Сохраните текущую политику; изменение сrejectнаnoneлишь скрывает часть последствий и снижает защиту, а не исправляет письма.
- Получите отчет только доверенным способомИспользуйте отчётные XML-файлы, поступающие на специально настроенный почтовый адрес или в защищённый анализатор. В агрегированном отчёте найдите IP источника, количества сообщений, результаты SPF/DKIM и политику получателя. Не отправляйте отчёт с адресами пользователей случайному сервису.
- Сопоставьте IP и свои отправляющие системыСоставьте актуальный перечень SMTP-провайдера, сайта, CRM, рассылки и технических уведомлений. Каждую строку отчёта отнесите к известной службе либо оставьте как неизвестную — имя обратного DNS само по себе не гарантирует принадлежность сервису.
- Проверьте не только pass, но и alignmentDMARC требует выравнивания хотя бы одного успешного механизма SPF или DKIM с видимым доменом From. Поэтому
spf=passдля почтового домена провайдера без alignment не обязательно даётdmarc=pass. Сопоставьте домен MAIL FROM иd=подписи.
- Проверьте DNS без изменения политикиЗапросите текущую DMARC-запись и связанные SPF и DKIM. Обнаружив несколько конфликтующих записей либо отсутствие селектора, исправляйте техническую ошибку в отдельном порядке. Не публикуйте два независимых TXT, начинающихся с
v=DMARC1, под одним именем. - Терминал с dig; подставьте доменLinux · Терминал (Bash)КомандаТерминал с dig; подставьте домен. Для SPF и DKIM требуются собственные имена запросов.
dig +short TXT _dmarc.example.com
- Исправьте легального отправителяЕсли CRM или рассылка использует свой домен подписи, настройте custom DKIM либо согласованный Return-Path по документации провайдера. Сначала испытайте одно письмо и его технические заголовки; массовую отправку возобновляйте после проверки.
- Отдельно оцените неизвестные источникиДля IP, которого нет в вашем списке, не добавляйте его в SPF ради исчезновения fail. Рассмотрите его как возможную подделку. Сравните долю и направление изменения, но не пытайтесь идентифицировать человека по одному IP в агрегированном отчёте.
- Наблюдайте отчёты после исправленияПодождите несколько циклов поступления отчётов и проверьте, что легальные источники проходят DMARC, а неизвестные не получили разрешений. Если меняете политику
p=, делайте это в рамках отдельного согласованного плана защиты домена.
#Проверка результата
В агрегированных отчётах легальные источники показывают DMARC pass за счёт выровненного SPF либо DKIM; неизвестные источники не объявлены разрешёнными. Реальная доставка тестовых писем остаётся штатной.
#Если решить проблему не удалось
Если источник известен и SPF/DKIM проходят отдельно, проверьте выравнивание домена, правило пересылки и точное значение From. DMARC failure — не всегда доказательство компрометации: это результат конкретной проверки получателя.