ARC-аутентификация: что это и зачем нужна

ARC (Authenticated Received Chain) - протокол аутентификации email, который сохраняет результаты проверок SPF, DKIM и DMARC при пересылке письма через промежуточные серверы. Стандарт описан в RFC 8617 и поддерживается Gmail, Microsoft 365 и другими крупными провайдерами.

The problem ARC solves

SPF, DKIM, and DMARC work well when a message travels directly from sender to recipient. But email is often forwarded: mailing lists, university aliases, corporate relays, auto-forwarding rules. Each intermediary can break the authentication chain.

SPF fails because the forwarding server's IP is not listed in the original sender's SPF record. DKIM may break if the intermediary modifies the message body or headers (adding a footer, rewriting subjects, stripping attachments). When both SPF and DKIM fail, DMARC fails too, and the message can be rejected or sent to spam - even though it was originally legitimate.

ARC addresses this by allowing each intermediary to record what the authentication results looked like before it touched the message. The final receiving server can then look at the ARC chain and decide whether to trust the forwarding path.

How ARC works

When an intermediary server receives and forwards a message, it adds three new headers forming an ARC set:

• ARC-Authentication-Results (AAR) - a snapshot of the authentication results (SPF, DKIM, DMARC) as seen by this intermediary at the moment it received the message.
• ARC-Message-Signature (AMS) - a DKIM-like signature over the message body and selected headers, computed by the intermediary. This proves the message content at the point of forwarding.
• ARC-Seal (AS) - a signature over all previous ARC sets and the current AAR header. The seal links each ARC set to the previous ones, creating the chain.

Each ARC set is numbered with an instance counter (i=1, i=2, etc.). The first intermediary creates set 1, the second creates set 2, and so on. The chain is ordered and tamper-evident: modifying any earlier set invalidates the seals of all subsequent sets.

How the receiver uses ARC

The final receiving server validates the ARC chain in reverse order. It checks the seal of the latest set, then the previous one, all the way back to i=1. If the chain is intact, the server can look at the AAR from set 1 to see the original authentication results - before any forwarding happened.

ARC does not override DMARC. It provides additional context. A receiving server with a local policy might say: "DMARC failed, but the ARC chain is valid, the first hop showed DMARC pass, and I trust the intermediary - so I will deliver this message." The decision to trust an ARC chain is entirely at the receiver's discretion.

Какую проблему решает ARC

SPF, DKIM и DMARC работают надёжно, когда письмо идёт напрямую от отправителя к получателю. Но электронная почта часто проходит через посредников: списки рассылки, университетские алиасы, корпоративные релеи, автоматическая пересылка. Каждый промежуточный сервер может сломать цепочку аутентификации.

SPF не проходит, потому что IP пересылающего сервера не указан в SPF-записи исходного домена. DKIM может сломаться, если посредник изменил тело письма или заголовки - добавил подпись в конец, переписал тему, удалил вложение. Когда SPF и DKIM оба не прошли, DMARC тоже даёт fail, и письмо может быть отклонено или отправлено в спам, хотя изначально оно было легитимным.

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

Как работает ARC

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

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

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

Как получатель использует ARC

Принимающий сервер проверяет цепочку ARC в обратном порядке: начинает с последнего набора, затем предыдущий, и так до i=1. Если цепочка целостна, сервер смотрит AAR из набора 1, чтобы увидеть исходные результаты аутентификации - до начала пересылки.

ARC не отменяет DMARC. Он предоставляет дополнительный контекст. Принимающий сервер может принять решение: «DMARC не прошёл, но ARC-цепочка валидна, на первом шаге DMARC был pass, и я доверяю посреднику - поэтому доставлю письмо.» Решение о доверии к ARC-цепочке полностью остаётся за получателем.

ARC и доставляемость рассылок

Для email-маркетолога ARC важен не как настройка, которую нужно включить, а как часть экосистемы, от которой зависит доставляемость. Если ваши подписчики используют пересылку (а многие это делают: с рабочей почты на личную, через алиасы), ARC помогает вашим письмам пройти проверку на конечном сервере.

Gmail, Microsoft 365 и Yahoo оценивают ARC при принятии решений о доставке. Если ваш домен имеет корректно настроенные SPF, DKIM и DMARC, промежуточные серверы с поддержкой ARC сохранят эти результаты. Конечный получатель увидит, что изначально письмо прошло все проверки.

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

Ограничения ARC

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

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