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

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

Какую проблему решает 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 и AMS. Печать связывает каждый набор с предыдущими, образуя цепочку.

Каждый 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 не поможет - ему просто нечего сохранять. Протокол дополняет существующую аутентификацию, а не заменяет её.