ARC (Authenticated Received Chain) решает давнюю боль форвардинга: пересылая письма, мы меняем маршрут и иногда заголовки так, что проверка SPF/DMARC у конечного получателя срывается. В результате легитимные письма уходят в спам или отклоняются. В этой статье — практическая схема включения ARC в продакшене на связке Postfix+Rspamd: генерация ключей, настройка подписи и верификации, политики отбора, тестирование и отладка.
Зачем ARC и в чем боль форвардинга
Классическая связка SPF+DKIM+DMARC хорошо работает, пока письмо идет напрямую от исходного домена к получателю. Но при форвардинге SPF почти гарантированно ломается (меняется источник, а SPF — это проверка IP-адреса отправителя), а DMARC из-за несоответствия SPF и/или отсутствия выровненного DKIM часто переходит в fail.
ARC добавляет поверх DKIM цепочку, в которой каждый солидный пересылщик (forwarder) оставляет свою «печать» с зафиксированными результатами аутентификации на своем этапе. Конечный провайдер может доверять этой цепочке и принимать решение, опираясь на исходные результаты проверки у первого звена.
Ключевая идея: если на вашем узле письмо прошло DMARC, вы «упаковываете» этот факт в ARC и пересылаете дальше. Получатель видит, что модификации внесены доверенным промежуточным сервером, и не наказывает письмо за сломанный SPF.
Как работает ARC (коротко и по делу)
ARC — это набор заголовков: ARC-Seal, ARC-Message-Signature (AMS) и ARC-Authentication-Results (AAR). Каждый пересылщик добавляет новый набор с увеличенным индексом i=. Подписи сделаны по схожей с DKIM логике, но включают результаты аутентификации (AAR) и «сшивают» всю историю.
На практике вам нужно два блока работы:
- Подписывать исходящую и пересылаемую корреспонденцию (генерация ключей, настройка DKIM и включение ARC-сигнинга).
- Проверять входящую корреспонденцию на «валидную цепочку ARC» и учитывать это при принятии решения (скоринг в антиспаме).
Где ARC уместен, а где нет
ARC необходим на узлах, которые пересылают почту дальше: корпоративные шлюзы, доменные алиасы и виртуальные домены, списки рассылки, MTA, выполняющий автоматические редиректы. Если вы просто отправляете почту напрямую от своих сервисов — достаточно DKIM+DMARC, а ARC имеет смысл как дополнительный плюс к deliverability.
Важно понимать, что ARC — не панацея. Он не «исправляет» полностью проваленный антиспам у получателя и не легализует токсичный контент. Это сигнал доверия к тому, что письмо не было испорчено на промежуточном шаге.
Предварительные условия
Перед включением ARC убедитесь, что базовая аутентификация настроена:
- DKIM-подпись исходящей почты стабильна (ключи актуальны, селектор в DNS, длина ключа 2048+). Для плановой ротации ключей пригодится материал «Ротация DKIM-селекторов и TTL» — см. статью о ротации селекторов DKIM и TTL.
- DMARC-политика определена и домен получает отчеты, чтобы наблюдать за доставляемостью. Полезно почитать «Как разбирать DMARC-отчеты» — см. разбор DMARC-отчетов и метрик доставляемости.
- Postfix работает с Rspamd через milter и модули DKIM, DMARC корректно отрабатывают.
Подключаем Rspamd к Postfix
Если у вас уже есть живой Rspamd, проверьте, что Postfix передает почту через milter до постановки в очередь. Минимальная конфигурация в Postfix:
# /etc/postfix/main.cf
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332
# /etc/postfix/master.cf (фрагмент, обычно без изменений под milter)
smtp inet n - y - - smtpd
В Rspamd проверьте включение добавления заголовков milter:
# /etc/rspamd/local.d/milter_headers.conf
enabled = true;
Если вы поднимаете почтовую инфраструктуру на собственном сервере, удобнее делать это на управляемом VDS с достаточным объемом памяти и гарантированным CPU. Это ускоряет диагностику и изоляцию нагрузки от веб-проектов.
Генерируем DKIM-ключи и публикуем в DNS
ARC использует DKIM-ключи вашего домена. Генерируем ключ и выкладываем TXT-запись с публичной частью:
# Генерация 2048-битного DKIM ключа
rspamadm dkim_keygen -b 2048 -s arc1 -d example.ru -k /var/lib/rspamd/dkim/example.ru.arc1.key -p > /var/lib/rspamd/dkim/example.ru.arc1.pub
# Пример содержимого TXT для DNS (selector arc1):
arc1._domainkey.example.ru. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"
Права на приватный ключ должны позволять чтение пользователем, под которым работает Rspamd. Добавляйте запись в DNS зоны домена; если вы управляете зонами через нашу регистрацию доменов, публикация TXT и ротация селекторов выполняются в пару кликов.
Настройка DKIM-подписи в Rspamd
Опишем, где лежат ключи, какой селектор использовать и когда подписывать:
# /etc/rspamd/local.d/dkim_signing.conf
path = "/var/lib/rspamd/dkim/$domain.$selector.key";
selector = "arc1";
use_domain = "header"; # использовать домен из From
use_esld = true; # подстраивать подпись к eSLD
allow_hdrfrom_mismatch = true;
allow_hdrfrom_multiple = true;
sign_authenticated = true; # подписывать письма аутентифицированных пользователей
sign_local = true; # и локально сгенерированные письма (форвард)
min_key_size = 2048;
Этого достаточно, чтобы DKIM стал стабильной базой для последующей ARC-подписи. Убедитесь, что исходящие письма с ваших сервисов имеют DKIM-Signature.
Включаем ARC в Rspamd
Модуль ARC в Rspamd использует ту же инфраструктуру ключей, что и DKIM. Для форвардинга нам нужно подписывать письма, которые приходят извне и уходят дальше (то есть «входящие для нас, но исходящие для следующего хопа»). Базовая настройка:
# /etc/rspamd/local.d/arc.conf
enabled = true;
sign_authenticated = true; # для MSA-сценариев
sign_inbound = true; # чтобы запечатывать входящие перед форвардингом
Как правило, этого достаточно: Rspamd добавит ARC-Authentication-Results с результатами SPF/DKIM/DMARC у вас на сервере и запечатает их через ARC-Message-Signature и ARC-Seal. Важно, чтобы модули spf, dkim и dmarc были включены и отрабатывали до этапа подписания.
Гибкое включение ARC только для нужных доменов
Если вы обслуживаете множество доменов и хотите управлять, для кого выполнять ARC, используйте settings в Rspamd:
# /etc/rspamd/local.d/settings.conf
ARC_FORWARDER {
id = "arc_forwarder";
priority = 10;
from = "*@example.ru";
apply {
ARC_ENABLED = 1;
}
}
Далее в local.d/arc.conf можно ориентироваться на наличие символа ARC_ENABLED и подписывать только такие сообщения. Это удобно, если вы постепенно раскатываете ARC по доменам
Проверка ARC на входящем трафике
Параллельно с подписью полезно учитывать валидную цепочку ARC при принятии решений по входящим письмам, особенно когда DMARC у получателя «красный». В Rspamd это обычно делается через скоринг символов:
# /etc/rspamd/local.d/groups.conf (пример идей, значения под свою политику)
symbols {
ARC_ALLOW {
weight = -2.0; # валидная цепочка снижает итоговый скор
description = "Valid ARC chain";
group = "policies";
}
ARC_INVALID {
weight = 3.5; # сломанная цепочка подозрительна
description = "Invalid ARC chain";
group = "policies";
}
}
Конкретные символы зависят от версии Rspamd, но идея одна: валидная цепочка улучшает карму письма, невалидная — ухудшает. Не переусердствуйте с отрицательным весом; ARC — не безусловный пропуск.
Пример: как выглядит письмо после форвардинга
После успешного внедрения вы увидите в пересланном письме заголовки наподобие:
ARC-Seal: i=1; a=rsa-sha256; d=example.ru; s=arc1; t=1732198000; cv=none;
b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.ru; s=arc1; h=from:to:subject:date:message-id:mime-version;
b=...
ARC-Authentication-Results: i=1; mx.example.ru;
dkim=pass header.d=sender.tld;
spf=fail smtp.mailfrom=sender.tld;
dmarc=pass header.from=sender.tld
Далее следующий пересылщик добавит i=2, и так далее. Конечный провайдер может валидировать цепочку и учитывать исходные результаты проверки.
Форвардинг в Postfix: алиасы, виртуальные домены, списки
Наиболее частые сценарии:
- Алиасы в
virtual_alias_mapsпересылают внешним адресатам. Для таких писем ARC критичен. - Листы рассылки, которые добавляют префиксы в
Subjectили меняют тело. Здесь ARC защищает цепочку, но полезно минимизировать модификации. - Пересылка с локального ящика в облачную почту. Без ARC такие пересылки часто получают DMARC fail у получателя.
Если меняете From или тело, следите за минимальными модификациями, чтобы DKIM-исходника по возможности оставался валидным. Используйте каноникализацию relaxed/relaxed и избегайте переписывания критичных заголовков.
Нужно ли включать SRS
SRS (Sender Rewriting Scheme) чинит SPF при форвардинге. Он бывает полезен, но не всегда обязателен, если у вас стабильно работает DKIM и ARC. В сценариях с большим количеством NDR/DSN и где важна корректная доставка бэкендовских уведомлений, SRS дополняет ARC. Однако многие операторы успешно живут с DKIM+ARC без SRS, полагаясь на DMARC и доверие к ARC-цепочке.
Политики принятия решения при DMARC fail с валидным ARC
Задача: не «пропускать все подряд», а аккуратно помогать легитимной почте. Практические рекомендации:
- Если
DMARC=fail, ноARC=passи цепочка короткая (например, 1–2 звена), уменьшите штраф до слабонегативного или нуля. - Если
ARC=pass, но цепочка длиннее 3–4 звеньев, не снимайте штраф полностью: выше риск манипуляций. - Если
ARC=fail, наоборот, увеличьте штраф: кто-то пытался «косить» под доверенную пересылку.
Всё это настраивается скорингом символов в Rspamd, комбинируясь с другими метриками (BAYES, IP reputation, URL reputation и так далее).
Отладка: где смотреть логи и метрики
Проверяйте три источника:
- Логи Rspamd: наличие символов ARC, результаты модулей SPF/DKIM/DMARC, время проверки и подписи.
- Логи Postfix на отправку пересланных писем: убедитесь, что milter применился и заголовки добавлены до выхода в очередь.
- Заголовки письма у получателя: есть ли
ARC-*, валидны ли DKIM-подписи, совпадает ли селектор.
Типичные проблемы:
- Нет DKIM-подписи у исходящих: проверьте путь к ключу и селектор в
dkim_signing.conf. - ARC не добавляется на форвардинге: убедитесь, что письмо классифицируется как inbound для этапа подписи (настройка
sign_inboundи порядок milter). - DKIM ломается после модификации: уменьшите трансформации письма (особенно переписывание заголовков и MIME-структуры) или оставьте DKIM от исходника и добавляйте свой DKIM как дополнительную подпись.
Практическая модель раскатки
- Включите DKIM-подпись на доменах, убедитесь в валидной подписи и корректной публикации TXT.
- Включите ARC в Rspamd и ограничьте его для одного тестового домена через
settings. - Форвардьте почту с этого домена на внешний ящик и анализируйте заголовки, логи и поведение антиспама.
- Настройте умеренный негатив или позитив в скоринге на основании
ARC=pass/invalid. - Постепенно расширяйте зону доменов с ARC и корректируйте веса.
Про deliverability: что реально меняется
После включения ARC вы заметите снижение ложных срабатываний при форвардинге, особенно для писем от крупных доменов с жесткими DMARC-политиками. Падения в папку спам становятся редкими, а возвраты с причиной DMARC fail сокращаются. Продолжайте мониторить отчеты DMARC и статистику антиспама, чтобы понимать, где ARC помог, а где корень проблемы в контенте или репутации IP/домена.
Безопасность: как не превратить ARC в «индульгенцию»
Не выставляйте чрезмерно большой отрицательный вес за ARC=pass. Всегда комбинируйте с другими сигналами. Следите, чтобы приватный DKIM-ключ не утекал и периодически ротируйте селектор. Наблюдайте за длиной цепочек, аномальными доменами-пересылщиками и несогласованностью домена в d= для DKIM/ARC.
FAQ
Нужно ли подписывать ARC все исходящие письма? Не обязательно, но безопасно. Ключевое — обязательно подписывать то, что вы форвардите.
Что если у отправителя нет DKIM? ARC все равно может помочь, так как фиксирует ваши результаты SPF/DMARC. Но без DKIM у исходника ценность ARC ниже.
RSA или Ed25519? Многие провайдеры отлично принимают RSA 2048. Ed25519 быстрее и компактнее, но проверьте совместимость вашей аудитории.
Как долго хранить селектор? Рекомендуется регулярная ротация (например, раз в 6–12 месяцев) с перекрытием валидности старого и нового записей.
Итоги
ARC — практичный инструмент для защиты форвардинга и повышения deliverability. На связке Postfix+Rspamd он включается быстро: стабильный DKIM, минимальная конфигурация arc.conf, аккуратные политики скоринга и немного дисциплины в изменении писем при пересылке. Дальше — только мониторинг и операционная гигиена.
