Как пересылка email ломает аутентификацию

Вы настроили SPF, DKIM и DMARC, всё проходит проверки. Потом один получатель пересылает ваше письмо на другой ящик, и аутентификация ломается. Письмо уходит в спам или вовсе отклоняется. Это не ошибка в вашей настройке. Так устроена пересылка, и проблему эту знают с тех пор, как придумали сами протоколы аутентификации.

Что происходит при пересылке письма

Вы настроили SPF, DKIM, DMARC. Всё проходит проверки. Потом получатель пересылает ваше письмо на другой ящик - и аутентификация ломается. Письмо попадает в спам или отклоняется. Это не баг вашей настройки. Так работает пересылка, и это известная проблема со времён появления протоколов аутентификации.

Есть два типа пересылки. Серверный редирект — промежуточный сервер принимает письмо и отправляет дальше, не меняя заголовок From. Конверт (MAIL FROM) меняется на адрес пересылающего сервера. Тело может быть изменено: добавлены подписи, перекодированы MIME-части, переписаны ссылки. Ручная пересылка — пользователь нажимает «Переслать» в почтовом клиенте. Создаётся новое письмо с новым конвертом. С точки зрения аутентификации это совершенно другое сообщение. Проблему создаёт именно серверный редирект.

SPF: ломается первым

SPF проверяет IP отправителя по DNS-записи домена конвертного адреса. Когда сервер B пересылает письмо, отправленное сервером A, получающий сервер C видит подключение с IP сервера B. Этого IP нет в SPF-записи исходного домена. Результат: SPF fail.

Некоторые пересылающие серверы используют SRS (Sender Rewriting Scheme) - перезаписывают конвертный адрес на свой домен. Это решает проблему SPF, но ломает alignment для DMARC: SPF теперь проходит для домена пересылателя, а не для домена в заголовке From.

DKIM: выживает, но не всегда

DKIM подписывает заголовки и тело сообщения. Подпись привязана к содержимому, а не к IP. Если письмо не было изменено при пересылке, подпись остаётся валидной. Принимающий сервер проверяет её через DNS исходного домена - проходит.

Но «не было изменено» - сильное допущение. На практике пересылающие серверы часто модифицируют письмо: списки рассылки добавляют префикс в тему и футер в тело, корпоративные шлюзы дописывают юридические дисклеймеры, системы безопасности перезаписывают ссылки для проверки при клике. Любое такое изменение инвалидирует хеш тела в DKIM-подписи.

DMARC: каскадный отказ

DMARC требует, чтобы хотя бы один протокол (SPF или DKIM) прошёл проверку и совпал с доменом в заголовке From. После пересылки SPF провален или совпадает с чужим доменом (SRS). DKIM - либо прошёл (если тело не трогали), либо провален.

Если DKIM проходит, DMARC тоже проходит - домен в подписи (d=) совпадает с From. Это единственный сценарий, где пересылка не ломает аутентификацию. Во всех остальных случаях - DMARC fail. При политике p=reject письмо будет отброшено, и вы как отправитель можете об этом не узнать.

ARC: протокол для решения проблемы

Authenticated Received Chain (ARC, RFC 8617) создан специально для пересылки. Каждый промежуточный сервер записывает состояние аутентификации на момент получения и подписывает эту запись. Формируется цепочка доверия.

ARC добавляет три заголовка на каждом хопе: ARC-Authentication-Results (результаты проверки), ARC-Message-Signature (DKIM-подобная подпись сообщения) и ARC-Seal (подпись поверх всех предыдущих ARC-заголовков).

Gmail, Microsoft 365 и Yahoo учитывают ARC при принятии решений о доставке пересланных писем. Но ARC - не гарантия. Принимающий сервер сам решает, доверять ли промежуточному узлу. И не каждый пересылатель поддерживает ARC.

Списки рассылки: самый тяжёлый случай

Mailman, Google Groups, LISTSERV - самые агрессивные пересылатели. Они добавляют префикс в тему, меняют Reply-To, дописывают футер с инструкцией по отписке, иногда полностью перезаписывают From. Это ломает и DKIM (тело изменено), и SPF (другой IP), и DMARC (оба протокола провалены).

Типичное решение: софт списка рассылки перезаписывает From на свой домен, а оригинального отправителя помещает в Reply-To. Mailman 3 и Google Groups делают это по умолчанию, когда у домена отправителя строгая политика DMARC. Работает, но получатели видят не тот адрес, который ожидают.

Что может сделать отправитель

Вы не контролируете, что происходит с письмом после отправки. Но можно снизить ущерб.

• Правильно подписывайте DKIM. Ключ 2048 бит. Подписывайте заголовки From, To, Subject, Date, MIME-Version, Content-Type. Не подписывайте заголовки, которые промежуточные серверы часто меняют.
• Не используйте тег l= в DKIM без острой необходимости. Он позволяет добавлять контент в конец тела без поломки подписи, но создаёт дыру для атакующих.
• Анализируйте DMARC-отчёты. Aggregate-отчёты показывают, с каких IP идут отправки и прошла ли аутентификация. Постоянные failure с IP известных пересылающих сервисов - это пересылка, а не спуфинг.
• Повышайте политику DMARC постепенно. От p=none к p=quarantine; pct=10, затем увеличивайте pct неделями. Это ограничивает радиус поражения при проблемах с пересылкой.

Как диагностировать сбой при пересылке

Когда получатель жалуется на пропавшие письма, попросите его открыть исходные заголовки. Смотреть надо вот на что.

# Смотрим результаты аутентификации
Authentication-Results: ...
  spf=fail ...
  dkim=fail (body hash did not verify) ...
  dmarc=fail ...

# Ищем ARC-заголовки: если они есть, промежуточный узел
# пытался сохранить результат проверки
ARC-Authentication-Results: i=1; ...
  spf=pass ...
  dkim=pass ...

# По Received-заголовкам восстанавливаем маршрут
Received: from forwarder.net (203.0.113.50) by mx.destination.com ...
Received: from mta.original-sender.com (198.51.100.25) by forwarder.net ...

Если ARC-заголовки есть, на первом переходе всё прошло, а у адресата провалилось, пересылающий сервер свою часть работы сделал. Принимающая сторона не доверилась цепочке ARC или не поддерживает её вовсе.

Если ARC-заголовков нет, пересылающий сервер про ARC не знает. Результат проверки с первого перехода потерян целиком.

Насколько это массовая история

Пересылка встречается сплошь и рядом. Выпускники вузов держат университетский адрес с переадресацией на личный Gmail или Outlook. Малый бизнес заводит почту на домене, которая уходит в общий ящик. Люди настраивают автопересылку между своими аккаунтами. Системные администраторы прописывают правила ретрансляции на шлюзе.

Google в своём разборе внедрения DMARC писал, что пересылка это главная причина ложных провалов DMARC. Если вы пишете B2B-аудитории в вузах или в корпоративной среде, рассчитывайте, что от 5 до 15% получателей увидят ваше письмо минимум через один переход пересылки.

Для отправителя со строгой политикой DMARC это значит, что заметная доля законных получателей может писем не увидеть. Спасает только целый DKIM и маршрут, который не переписывает тело письма.

Что происходит с протоколами после пересылки

Главное отсюда: DKIM это единственная реальная защита от срыва аутентификации при пересылке. Держится DKIM, значит DMARC проходит по выравниванию через него. Сломался DKIM, и вы целиком зависите от того, доверится ли принимающий сервер цепочке ARC, а на это вы повлиять не можете.