ARC (Authenticated Received Chain) при пересылке писем: как сохранить SPF/DKIM и доставляемость

Почему пересылка ломает аутентификацию и доставляемость

В нормальной схеме отправитель подписывает письмо DKIM, публикует SPF (какие IP имеют право отправлять от домена), а получатель проверяет это и, опираясь на DMARC, решает: принять, пометить или отклонить. Как только между ними появляется форвардер (переадресация) — например, вы пересылаете почту с user@old-domain на user@gmail.com через свой сервер — картина часто «рассыпается».

SPF ломается почти всегда, потому что SPF проверяет IP последнего SMTP-отправителя в момент доставки. При пересылке последним отправителем становится форвардер, а его IP обычно не включён в SPF домена исходного отправителя.

DKIM может выжить, если форвардер не меняет тело и заголовки, которые подписаны. Но на практике пересылка и фильтры нередко добавляют предупреждения, перепаковывают MIME, меняют кодировки и переносы строк, дописывают префиксы в тему — и подпись перестаёт сходиться.

Дальше включается DMARC: если видно SPF=fail и/или DKIM=fail, выравнивание (alignment) не проходит — и доставляемость (deliverability) проседает: письмо уходит в спам или отклоняется.

Что такое ARC (Authenticated Received Chain)

ARC (Authenticated Received Chain) — механизм, который позволяет промежуточному узлу (форвардеру, шлюзу безопасности, списку рассылки) «засвидетельствовать» результаты проверок SPF/DKIM/DMARC, которые он видел на входе, и передать этот контекст дальше по цепочке доставки.

Практический смысл: конечный получатель может учесть, что до пересылки письмо было валидным, даже если после пересылки базовые проверки уже не сходятся. Это и есть arc validation: оценка, можно ли доверять цепочке свидетельств.

ARC не «чинит» SPF/DKIM магией. Он фиксирует: что именно увидел форвардер на входе, и криптографически связывает это с дальнейшей пересылкой.

Из чего состоит ARC: AAR, AMS и AS

ARC добавляет к письму набор заголовков с инстансами i=1, i=2 и т.д. по мере прохождения через узлы, поддерживающие ARC:

• ARC-Authentication-Results (AAR) — снимок результатов проверок (SPF/DKIM/DMARC и др.), выполненных узлом на входе.
• ARC-Message-Signature (AMS) — подпись содержимого письма (похожа на DKIM по идее, но относится к ARC-цепочке).
• ARC-Seal (AS) — «печать», которая связывает текущий шаг с предыдущими и защищает цепочку от подделки и вырезания.

Ключевой элемент для понимания — ARC-Seal: именно он превращает отдельные «факты» (AAR) в проверяемую цепочку доверия.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

ARC и SRS: не конкуренты, а разные задачи

В теме «пересылка ломает SPF/DKIM» обычно всплывают два подхода, и они решают разные проблемы:

• SRS (Sender Rewriting Scheme) — форвардер переписывает envelope-from (Return-Path) на свой домен, чтобы SPF проходил для пересланного письма. Это поднимает шанс прохождения SPF, но не лечит DKIM и меняет адрес для возвратов (bounce).
• ARC — форвардер фиксирует результаты аутентификации, увиденные на входе, и передаёт их дальше. Это помогает получателю принять более точное решение, особенно если письмо было изменено по пути.

В реальном продакшене их часто комбинируют: SRS — чтобы не «убивать» SPF на ровном месте, ARC — чтобы у получателя был дополнительный сигнал, если DKIM/DMARC развалились после пересылки.

Если вы держите почтовую инфраструктуру на своём сервере, ARC и SRS обычно удобнее контролировать на собственном VDS, где можно управлять MTA, фильтрами и DNS без ограничений панелей «переадресации в один клик».

Когда ARC реально помогает (и когда нет)

Сценарии, где ARC полезен

• Почтовые форвардеры домена: переадресация на внешний ящик, миграции, алиасы, catch-all.
• Шлюзы безопасности (антивирус/антиспам/DLP), которые могут модифицировать письмо (добавить предупреждение, карантинный баннер).
• Списки рассылки, которые добавляют футер, правят Subject и часто ломают DKIM.

Когда ARC не спасёт

• Если форвардер принимает письмо уже с dkim=fail или dmarc=fail, ARC честно это зафиксирует, но «чуда» не сделает.
• Если получатель вообще не учитывает ARC в своей политике/антиспаме, эффект будет минимальным.
• Если у форвардера плохая репутация домена/IP, цепочка ARC не станет индульгенцией.

Как устроена arc validation у получателя

Проверка ARC на стороне получателя обычно укладывается в четыре шага:

1. Проверить криптографию: сходятся ли ARC-Message-Signature и ARC-Seal для каждого i=....
2. Оценить целостность цепочки: нет ли «дыр», корректен ли порядок инстансов, не вырезаны ли части.
3. Прочитать ARC-Authentication-Results: какие результаты (SPF/DKIM/DMARC) видел форвардер на входе.
4. Применить локальную политику: доверять ли этому узлу/домену и учитывать ли ARC при DMARC-решении.

Важно: ARC не отменяет DMARC. Он лишь добавляет контекст, а финальное решение всегда за получателем.

Практика: что включать на форвардере

ARC включают именно на том узле, который принимает письмо и затем пересылает дальше. Минимальный набор возможностей у этого узла:

• делать проверки SPF/DKIM/DMARC на входе и формировать Authentication-Results;
• подписывать исходящий поток ARC-заголовками (AAR/AMS/AS);
• публиковать DNS-запись с публичным ключом (по принципу DKIM: селектор + TXT).

По реализации это обычно связка MTA (Postfix/Exim) и фильтра/мильтера (например, Rspamd с ARC, либо OpenARC). Важно не название софта, а порядок обработки: сначала входная аутентификация, затем (при пересылке) ARC-подпись, затем любые изменения, которые вы не контролируете, лучше не допускать.

Если вы используете Rspamd как основной фильтр, пригодится отдельный разбор практической схемы: настройка ARC при связке Postfix и Rspamd для пересылки.

DNS для ARC: ключевые моменты

ARC-ключ публикуется в DNS домена, которым подписывает посредник (форвардер). Типичная ошибка — пытаться разместить ключ «в домене отправителя»: ARC не про отправителя, а про доверяемую фиксацию фактов посредником.

Если у вас домены обслуживаются отдельно от почты и вы делаете «красивую переадресацию», заранее убедитесь, что у вас есть полный контроль DNS (TXT-записи для селекторов). При необходимости домен удобно держать там, где простая панель управления DNS и быстрые правки — например, через регистрацию доменов с управляемой зоной.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Диагностика: как понять, что ARC работает

1) Проверяем заголовки письма

Откройте «показать оригинал» у получателя и найдите:

• ARC-Authentication-Results:
• ARC-Message-Signature:
• ARC-Seal:

Если заголовков нет — форвардер ARC не добавляет. Если есть — смотрите на i=: цепочка должна быть последовательной. Для простого форварда через один узел обычно будет i=1.

2) Сопоставляем «на входе» и «на выходе»

Смысл ARC — показать, что до изменений письмо проходило аутентификацию. Сравните:

• что записано в ARC-Authentication-Results (вход на форвардер);
• что видит конечный получатель в своих Authentication-Results.

Нормальная для пересылки картина: у получателя spf=fail, иногда dkim=fail, но ARC сообщает, что на входе у форвардера было dmarc=pass и/или dkim=pass.

3) Ищем в логах, что ломает DKIM

ARC может смягчить последствия, но если DKIM ломается регулярно, лучше убрать первопричину. Типовые причины:

• фильтр добавляет баннер/футер и меняет тело письма;
• перекодирование или пересборка MIME (в том числе вложений);
• неаккуратная нормализация пробелов и переносов строк;
• добавление/изменение заголовков, которые включены отправителем в DKIM-подпись.

Для общей картины по DKIM/спаму полезно держать под рукой настройки и диагностику фильтра: как читать скоринг Rspamd и не «перекрутить» антиспам.

Частые ошибки при внедрении ARC

• ARC включили без входной аутентификации: если узел не проверяет SPF/DKIM/DMARC на входе, в AAR нечего «засвидетельствовать».
• Неверный DNS-ключ/селектор: подписи не сходятся, arc validation проваливается.
• Подписывает не тот узел: если письмо модифицируется после ARC-подписи (ещё одним фильтром ниже по цепочке), AMS/AS перестают сходиться.
• Нарушен порядок обработки: сначала модификации, потом «результаты входных проверок» — цепочка перестаёт отражать реальность.
• Слишком агрессивные модификации контента: некоторые получатели осторожно относятся к цепочкам, где посредник выглядит как источник переписывания сообщения.

Мини-пример: как выглядят ARC-заголовки

Пример ниже нужен только для ориентира по форме. Значения уникальны для каждого письма и ключа, копировать их бессмысленно.

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=arc1;
  bh=...; b=...;

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

Смотрите на i=1 и на домен d=forwarder.example: ARC подписывает посредник, а не исходный отправитель.

Итоги и практический чек-лист

1. Точно определите, где происходит пересылка: MTA, панель домена, внешний провайдер, клиентское правило.
2. Включите и проверьте входные проверки SPF/DKIM/DMARC на форвардере.
3. Настройте добавление ARC-заголовков на исходящем (пересылаемом) потоке.
4. Опубликуйте ARC-ключи в DNS домена форвардера и убедитесь, что подписи валидируются.
5. По возможности включите SRS, чтобы уменьшить количество spf=fail у конечного получателя.
6. Протестируйте доставку на популярные ящики и сравните заголовки/вердикты до и после ARC.
7. Проверьте, какие именно модификации контента делает ваш фильтр, и минимизируйте те, что ломают DKIM.

ARC — не гарант «инбокса везде», но это один из самых практичных инструментов, чтобы пересылка перестала быть постоянной лотереей при жёстких DMARC-политиках у отправителей.