Переадресация и ARC: почему пересылка ломает SPF и что с этим делать

1. Короткий ответ: почему переадресация ломает SPF

SPF проверяет одно: разрешено ли серверу, который установил SMTP-соединение, отправлять почту от домена в envelope sender (MAIL FROM). Когда сотрудник компании настраивает пересылку со служебного ящика на личный Gmail, или когда письмо проходит через список рассылки, дальше письмо едет уже с сервера пересыльщика. Его IP нет в вашей SPF-записи, и конечный получатель честно фиксирует spf=fail для вашего домена.

Это не ошибка конфигурации с вашей стороны и не повод добавлять чужие IP в SPF. Так устроен протокол: SPF описан как проверка соединения и envelope, а не сквозная аутентификация письма (RFC 7208). Любая пересылка с сохранением envelope sender дает fail, и это ожидаемое поведение, а не аномалия.

Часть пересыльщиков вместо этого использует Sender Rewriting Scheme (SRS): переписывает envelope sender на собственный домен, закодировав в него исходный адрес, чтобы сообщения о недоставке по-прежнему доходили до автора. В этом случае SPF формально проходит, но уже для домена пересыльщика, а не вашего, и DMARC это не засчитывает: выравнивание проверяется по домену в заголовке From, который SRS не трогает. Итог для DMARC один и тот же в обоих случаях (сохранил ли пересыльщик envelope sender или переписал его через SRS): SPF сам по себе выравнивание не дает, и остается DKIM.

Практический вывод: смотреть нужно не на SPF в одиночку, а на связку SPF + DKIM + DMARC в заголовке Authentication-Results конечного получателя. Один spf=fail при пересылке сам по себе ничего не решает, если есть валидная DKIM-подпись вашего домена.

2. Что происходит с DKIM и DMARC при пересылке

DKIM-подпись считается по выбранным заголовкам и телу письма. Если пересыльщик просто передал письмо дальше без изменений, подпись остается валидной: dkim=pass, header.d=ваш домен. DMARC проходит, потому что для него достаточно прохождения хотя бы одного механизма с совпадением домена (alignment): DKIM с d= равным домену в From, или SPF с совпадающим envelope sender.

Проблема начинается, когда посредник письмо меняет. Классический сценарий: список рассылки (mailing list) добавляет префикс в тему, дописывает подвал с ссылкой отписки от списка или пересобирает MIME-структуру. Любое изменение подписанных заголовков или тела делает DKIM-подпись недействительной, и в заголовках конечного получателя появляется dkim=fail. Это и есть ситуация "dkim mailing list fail", с которой сталкиваются отправители B2B-рассылок.

Если список рассылки при этом не подменяет envelope sender на свой, падает и SPF. Итог: dmarc=fail по обоим механизмам. При политике p=quarantine такое письмо уходит в спам, при p=reject отклоняется, хотя отправитель сделал все правильно. Именно для разрыва этой проблемы и придуман ARC.

3. Дерево диагностики: что означают комбинации результатов

Возьмите пересланное письмо у конечного получателя (в Gmail: "Показать оригинал", в Outlook: просмотр источника сообщения) и найдите Authentication-Results. Сверьтесь с таблицей:

4. ARC: что это и как устроено

ARC (Authenticated Received Chain, RFC 8617) решает задачу посредника: сохранить результат аутентификации письма на момент, когда оно пришло к нему, и подписать это своей подписью. Когда ваш клиент пересылает рассылку через корпоративный шлюз или список рассылки меняет письмо, посредник фиксирует: "когда письмо пришло ко мне, SPF, DKIM и DMARC проходили".

Каждый посредник добавляет набор из трех заголовков с номером экземпляра i= (1, 2, 3 и так далее по цепочке):

ARC-Authentication-Results: i=1; mx.forwarder.example; spf=pass smtp.mailfrom=sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example

ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.example; s=arc; c=relaxed/relaxed; h=...; b=...

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc; cv=none; b=...

ARC-Message-Signature подписывает копию письма на момент прохождения посредника, ARC-Seal подписывает всю предыдущую цепочку ARC. Конечный получатель (например, Gmail или Microsoft 365) проверяет цепочку подписей и, если доверяет пересыльщику, может учесть сохраненные результаты вместо "сломанных" текущих. Вот что означает запись "arc authentication results" в исходнике письма: это зафиксированный снимок проверки на узле пересылки.

ARC-Seal, строго говоря, это подпись целостности цепочки, а не аутентификация автора письма. Поле cv= (chain validation) у первого звена равно none, у следующих pass, если цепочка валидна, или fail, если нет.

5. Ограничения ARC: почему это не универсальное лекарство

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

Второе: конечный получатель сам решает, кому из пересыльщиков доверять. Microsoft 365 в своем руководстве для администраторов прямо описывает механизм доверенных ARC-подписывающих (trusted ARC sealers): администратор ведет список доменов, чьим ARC-подписям система верит. Без доверия цепочка является просто данными, а не основанием пропустить письмо.

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

6. Что делать отправителю: практические шаги

Со стороны отправителя вы не управляете тем, как получатели пересылают письма. Но вы управляете тем, что ломается, а что выживает:

1. Убедитесь, что DKIM-подпись вашего домена стабильна и подписывает все исходящие потоки. При пересылке без изменений валидный DKIM полностью закрывает вопрос: DMARC пройдет по DKIM даже при spf=fail. Проверьте подпись на тестовом письме и состояние DNS-записи селектора.

2. Настройте DMARC и собирайте агрегированные отчеты. В отчетах вы увидите IP пересыльщиков со статусом fail и сможете отличить пересылку (редкие IP, единичные письма, DKIM проходит) от подделки (массовый трафик, оба механизма fail). Это критично перед переходом на p=quarantine или p=reject.

3. Если вы сами администрируете список рассылки или корпоративную пересылку: включите ARC на шлюзе (готовые реализации есть для распространенных MTA). Учтите, что одной подмены envelope sender (SRS) и переподписи своим DKIM недостаточно для DMARC pass исходного домена автора: DMARC проверяет выравнивание с доменом в заголовке From, а его SRS и чужой DKIM не меняют. Рабочие варианты для списка рассылки - переписывать сам заголовок From на домен списка (так делает механизм dmarc_moderation_action в Mailman, кладя исходный адрес в Reply-To или Cc) либо оборачивать письмо в новое сообщение от имени списка, либо рассчитывать на то, что получатель доверяет ARC-подписи вашего сервера и учтет исходный результат аутентификации.

4. Если вы получаете жалобы "ваша рассылка у клиентов в спаме после пересылки": попросите у клиента исходник письма и разберите Authentication-Results по дереву из раздела 3. Часто оказывается, что корпоративный шлюз клиента перепаковывает письма, и это его локальная настройка, а не ваша проблема.

7. Как проверить результат

Проверка занимает несколько минут и не требует доступа к серверам. Найдите реального получателя, который пересылает ваши письма (коллега с пересылкой на личный ящик подойдет), и попросите исходник пересланного письма.

Вставьте заголовки в анализатор и посмотрите: проходит ли dkim=pass с header.d вашего домена, есть ли цепочка ARC, какой вердикт DMARC зафиксировал конечный получатель. Параллельно проверьте DNS: SPF-запись должна быть одна и без лишних include, DMARC-запись должна иметь rua для сбора отчетов.

На дистанции следите за долями SPF, DKIM и DMARC в Google Postmaster Tools: устойчивый провал доли DKIM без изменений с вашей стороны часто указывает на то, что заметная часть потока проходит через меняющих письма посредников. Мониторинг этих долей по дням позволяет заметить проблему до жалоб пользователей.