Почему Mail.ru пропустил DMARC reject tinkoff.ru

Mail.ru мог не применить политику p=reject либо потому, что проверка DMARC фактически не запускалась (в заголовке x-mailru-dmarc стоит «not checked»), либо потому, что SPF/DKIM прошли за домен tinkoff.ceo и система посчитала письмо «достаточно аутентичным» (или же оно прошло через доверенный ретранслятор/ARC/whitelist). Чтобы понять, почему именно произошло исключение, обязательно последовательно проверить выравнивание SPF/DKIM с полем From, цепочку Received/ARC, DNS‑запись _dmarc.tinkoff.ru и логи Mailgun/MTА — эти шаги быстро выявляют главные причины обхода DMARC.

Содержание

• Проверка DMARC Mail.ru: возможные причины пропуска
• Проверка выравнивания SPF/DKIM с полем From
• ARC, пересылки и доверенные партнёры (whitelist)
• Баги парсинга заголовков, кеширование DNS и другие технические причины
• Пошаговое расследование и отладка (checklist)
• Источники
• Заключение

Проверка DMARC Mail.ru: возможные причины пропуска

Коротко — реальная причина обычно одна из трёх: DMARC не был выполнен/не обнаружен, проверка была «переадресована» через доверенный путь (ARC / партнёр / whitelist), или же аутентификация прошла, но подписи были от другого домена (misalignment). Ниже — разбивка по возможным сценариям и что это значит.

• DMARC действительно не запускался (x-mailru-dmarc: not checked).
  Пустой или помеченный как «not checked» X‑заголовок означает, что на этапе финального принятия Mail.ru не выполнил/не сохранил результат DMARC. Это может быть следствием внутреннего решения сервера не проверять для определённых потоков или сбоя в парсинге заголовков.

• Доверенный ретранслятор / whitelist.
  Некоторые крупные почтовые хранилища допускают «особые» маршруты для партнёров и крупных отправителей: в таких случаях сообщения из этих источников могут не проходить стандартную блокировку по DMARC. Подробнее о путях обхода и защите от них — в обзоре техник bypass у специалиста по DMARC: https://sendmarc.com/dmarc/bypass-techniques/.

• ARC / пересылка.
  При пересылке SPF ломается; ARC позволяет промежуточному хосту подписать результаты аутентификации и «перенести» доверие дальше. Если сообщение несёт корректную ARC‑цепочку и Mail.ru принимает эту цепочку, кажется, что DMARC уже «прошёл». Mailgun и другие сервисы описывают поведение при пересылках и роль ARC в доставке: https://help.mailgun.com/hc/en-us/articles/13285772266011-DMARC.

• Misalignment (SPF/DKIM pass, но для tinkoff.ceo).
  Если SPF/DKIM прошли для tinkoff.ceo, а в поле From — tinkoff.ru, DMARC должен был упасть (требуется выравнивание). Но на практике возможны варианты: неправильное вычисление организационного домена, relaxed alignment (aspf/adkim=r) или наличие дополнительной проходящей DKIM‑подписи с d=tinkoff.ru. Примеры таких ситуаций описаны в разборе: https://www.duocircle.com/dmarc/why-email-from-third-party-vendor-pass-spf-dkim-but-fail-dmarc и в обсуждении на security.stackexchange: https://security.stackexchange.com/questions/215635/why-is-dmarc-failing-when-spf-and-dkim-are-passing.

• Проблемы с DNS / парсинг DMARC.
  Если Mail.ru не смог получить TXT‑запись _dmarc.tinkoff.ru (DNSSEC, CNAME, множественные TXT, кеширование), он может не применить политику. На практике при ошибке резолва многие мейл‑провайдеры ведут себя по-разному — кто-то доставляет, а кто-то отвергает.

Что проверить первым делом? Сохраните raw‑заголовки сообщения и начните с анализа Authentication‑Results и Received — это даст ключ к дальнейшим шагам.

Проверка выравнивания SPF/DKIM с полем From

DMARC требует alignment: либо SPF (envelope-from) совпадает с From, либо DKIM (d= в подписи) совпадает с From (в зависимости от adkim/aspf — strict/relaxed). Что делать и как проверить на практике.

1. Найдите в сыром письме эти строки:

• From: (header.from)
• Return-Path: (envelope-from)
• DKIM-Signature: в ней — d=<домен>
• Authentication-Results: spf=…, dkim=…, dmarc=…

Примерные команды:

grep -i "From:" headers.eml
grep -i "Return-Path:" headers.eml
grep -i "DKIM-Signature" headers.eml
grep -i "Authentication-Results" headers.eml

2. Что искать в результатах:

• Если в Authentication-Results видно spf=pass smtp.mailfrom=tinkoff.ceo и dkim=pass header.d=tinkoff.ceo, а From — tinkoff.ru, то DKIM/SPF прошли, но они не выровнены с header.from = dmarc fail (обычно).
• Если есть дополнительная DKIM‑подпись header.d=tinkoff.ru и она pass — DMARC может пройти.

3. Проверка политики DMARC и режимов выравнивания:

dig TXT _dmarc.tinkoff.ru +short

В записи смотрите tеги p=, aspf=, adkim=. Пример: v=DMARC1; p=reject; rua=mailto:dmarc@tinkoff.ru; aspf=r; adkim=r;.

4. Частые источники misalignment и исправления:

• Подписи от Mailgun (или другого ESP) по умолчанию могут иметь d= у домена ESP. Решение — настроить кастомный DKIM (подписывать вашим доменом) и/или использовать subdomain (mg.tinkoff.ru) с соответствующим DMARC.
• SPF: Return-Path должен быть на контролируемом домене или использовать SRS при пересылке.
  Подробнее о том, почему pass SPF/DKIM не равен pass DMARC и как это фиксить, описано в статье Mailgun: https://www.mailgun.com/blog/deliverability/email-authentication-your-id-card-sending/.

ARC, пересылки и доверенные партнёры (whitelist)

Пересылка ломает SPF, DKIM может быть повреждён; ARC — способ «передать» результаты аутентификации через промежуточные узлы. Что проверить:

• Есть ли в заголовках ARC‑поля? Ищите ARC-Seal:, ARC-Message-Signature:, ARC-Authentication-Results:.
  Команда:

grep -i "^ARC-" headers.eml

• Если присутствует корректная ARC‑цепочка, Mail.ru мог принять утверждение предыдущего хоста о том, что письмо было проверено. Но поддержка ARC у приёмников неодинакова — Mail.ru может принимать или игнорировать ARC в зависимости от доверия к промежуточному узлу.

• Forwarding через крупных релейных операторов (или через корпоративные шлюзы) иногда приводит к тому, что письмо проходит несмотря на DMARC, если промежуточный хост считается доверенным.

Что делать:
Проверьте Received‑цепочку, сопоставьте IP‑адрес ближайшего к Mail.ru хоста с IP Mailgun (или с IP‑адресом стороннего ретранслятора). Смотрите, кто добавил ARC‑заголовки и можно ли доверить этому узлу. Если пересылка предполагается, настройте SRS на пересылающем узле.

Баги парсинга заголовков, кеширование DNS и другие технические причины

Множество «тонких» ошибок приводят к тому, что p=reject не срабатывает:

• Неправильная/несколько TXT‑записей DMARC. Наличие более одной TXT записи для _dmarc домена или неправильный синтаксис (пропущен v=DMARC1 и т.д.) может сломать парсер у приёмника. Проверяйте строго:

dig TXT _dmarc.tinkoff.ru +short
dig +trace _dmarc.tinkoff.ru

• Кеширование DNS / задержка обновления. Если запись недавно изменилась, часть resolver‑ов (включая у Mail.ru) может видеть старую версию или вообще ничего. Смотрите TTL и тестируйте с разных резолверов (8.8.8.8, 1.1.1.1 и т.д.).

• DNSSEC или CNAME‑цепочки. Если _dmarc записан через CNAME или есть проблемы DNSSEC, резолв может быть ошибочным.

• Парсинг заголовка From—особенности кодировок или наличие Resent‑From / Sender. Иногда приёмник берёт не тот From (например, Resent‑From) и проверяет DMARC относительно него.

• Множественные DKIM‑подписи: одна подпись может быть от ESP (tinkoff.ceo), другая — от вашего домена. Убедитесь, какую именно подпись принял Mail.ru.

• Внутренние баги Mail.ru по парсингу (встречаются в реальности). Если все проверки на вашей стороне в порядке, соберите свежие raw‑заголовки и обращайтесь в поддержку Mail.ru с подробностями — без них разобраться будет сложно.

Пошаговое расследование и отладка (checklist)

Ниже — практический чеклист для инженера, чтобы локализовать проблему и исправить её.

1. Сохраните полный raw‑eml (включая все Received и Authentication‑Results). Это главный артефакт для разбирательств.

2. Найдите ключевые поля в заголовках:

• From: (header.from)
• Return-Path: (envelope-from)
• Authentication-Results: (spf/dkim/dmarc)
• X‑MailRu‑Dmarc или похожие внутр. заголовки
• ARC‑заголовки (если есть)

3. Проанализируйте SPF/DKIM:

• grep на DKIM‑подписи: grep -i "DKIM-Signature" headers.eml
• Посмотрите d= у каждой подписи и какая из них pass (в Authentication‑Results).

4. Проверка DMARC записи:

dig TXT _dmarc.tinkoff.ru +short

• Убедитесь, что p=reject действительно виден с разных резолверов. Используйте dig @8.8.8.8 и dig @1.1.1.1.

5. Проверьте выравнивание:

• Совпадает ли envelope‑from (Return‑Path) с header.from? Совпадает ли d= в DKIM с header.from? Если нет — misalignment.

6. Проанализируйте Received‑цепочку:

• Кто передал письмо Mail.ru (IP и PTR)? Это Mailgun, сторонний ретранслятор или пересылка от конечного пользователя? Найдите ближайший к Mail.ru hop и проверьте, не является ли он доверенным.

7. Проверьте ARC:

• Есть ли ARC-Seal: и ARC-Authentication-Results:? Если есть — смотрите, от кого и какие результаты он утверждает.

8. Посмотрите логи Mailgun / ESP:

• Mailgun покажет, с каким d= и с каким Return‑Path отправлялось письмо. Это ключ к тому, почему SPF/DKIM pass относятся к tinkoff.ceo.

9. Попробуйте воспроизвести:

• Отправьте тестовые письма с 3 вариантами:
  a) DKIM подписан d=тinkoff.ru (ваш домен);
  b) DKIM подписан d=tinkoff.ceo (ESP);
  c) без DKIM, но с SPF для tinkoff.ru.
• Сравните поведение Mail.ru (какие заголовки и x‑mailru‑dmarc появляются).

10. Проверка DNS‑кешей Mail.ru:

• В отчётах rua вы увидите, как Mail.ru видел вашу политику. Настройте rua в DMARC, если ещё не настроено, и анализируйте отчёты.

11. Проверьте, нет ли синтаксических ошибок в _dmarc записи (лишние кавычки, несколько TXT и т.д.). Если есть — поправьте.

12. Если всё на вашей стороне корректно — готовьте тикет в поддержку Mail.ru:

• Приложите raw‑header, Message‑ID, время доставки, IP‑адреса из Received, краткое описание (например: “x-mailru-dmarc: not checked; spf/dkim passed for tinkoff.ceo, From=tinkoff.ru”). Ссылка на их документацию может помочь: https://help.mail.ru/developers/notes/dmarc/.

13. Исправления и профилактика:

• Настройте DKIM, чтобы подписывать header.from домен (или используйте subdomain, который вы контролируете и для которого есть DMARC).
• SPF должен явно включать все IP/ESP.
• Включите rua для агрегированных отчётов и начните мониторить.
• Плавный переход на p=reject: сначала p=none → p=quarantine → p=reject, пока отчёты не покажут исправность.

14. Если используете Mailgun — проверьте их инструкции по аутентификации и DMARC: https://help.mailgun.com/hc/en-us/articles/13285772266011-DMARC и обзор по аутентификации: https://www.mailgun.com/blog/deliverability/email-authentication-your-id-card-sending/.

Короткие команды для быстрой проверки:

# DMARC запись
dig TXT _dmarc.tinkoff.ru +short

# Посмотреть Authentication-Results в headers
grep -i "Authentication-Results" headers.eml

# Найти DKIM d= значение
grep -i "DKIM-Signature" headers.eml | sed -n '1,3p'

Источники

1. https://help.mail.ru/developers/notes/dmarc/
2. https://mailganer.com/ru/explanation/reject-v-dmarc-politike
3. https://qna.habr.com/q/1218056
4. https://sendmarc.com/dmarc/bypass-techniques/
5. https://www.duocircle.com/dmarc/why-email-from-third-party-vendor-pass-spf-dkim-but-fail-dmarc
6. https://security.stackexchange.com/questions/215635/why-is-dmarc-failing-when-spf-and-dkim-are-passing
7. https://www.mailgun.com/blog/deliverability/email-authentication-your-id-card-sending/
8. https://help.mailgun.com/hc/en-us/articles/13285772266011-DMARC

Заключение

Скорее всего причина — либо отсутствие реальной проверки DMARC у Mail.ru в конкретном потоке (x-mailru-dmarc: not checked), либо выравнивание SPF/DKIM не соответствует header.From (подписи/Return‑Path от tinkoff.ceo), либо сообщение прошло через доверенный ретранслятор/ARC или было в whitelist. Действуйте по чеклисту: сохраните raw‑заголовки, проверьте выравнивание SPF/DKIM, подтвердите корректность записи _dmarc.tinkoff.ru и логи Mailgun, затем при необходимости откройте запрос в поддержку Mail.ru. Главное — настроить подписи так, чтобы DKIM/SPF были выровнены с вашим From и начать собирать отчёты DMARC (rua) перед окончательным применением p=reject.