Почему письмо, которое вы переслали себе, попало в спам

Установите автоматическую переадресацию со старого аккаунта на новый — и часть писем тихо исчезнет в спаме. Не потому, что ваш провайдер сломан, а потому что переадресация переписывает того, кто отправляет сообщение, без переписывания криптографического подтверждения. SPF проверяет не тот сервер, вердикт DMARC становится отрицательным, и законное письмо, которое вы отправили себе, помещается в карантин. Решение называется ARC, определённое в RFC 8617 ещё в 2019 году.

Почему переадресация приводит к отказу SPF для моего письма?

Потому что SPF проверяет последний сервер, который передал сообщение, а переадресация этот сервер меняет. SPF (Sender Policy Framework) — это DNS-запись, которая содержит список IP-адресов, авторизованных для отправки писем от домена. Когда bank.com отправляет вам квитанцию, принимающий сервер проверяет: пришло ли это с IP-адреса, авторизованного bank.com? Да. Проверка пройдена.

Теперь переадресуйте эту квитанцию из Gmail на новый адрес. Серверы Google передают её дальше. Итоговый принимающий сервер запускает проверку SPF и спрашивает: авторизован ли Google отправлять письма от bank.com? Нет. SPF не пройден. Собственная документация Workspace от Google это чётко объясняет — переадресованные письма не проходят SPF, потому что сервер переадресации не указан в SPF-записи исходного домена. Никакой подделки не было. Проверка просто смотрит на неправильный hop.

Так почему это отправляет письмо в спам?

DMARC. Раньше отказ SPF в одиночку был выживаемым; DMARC превратил его в вердикт. DMARC связывает SPF и DKIM вместе и указывает получателям, что делать, если оба не пройдены: ничего, поместить в карантин или отклонить. К 2024 году крупные отправители не имели выбора — Google и Yahoo начали требовать DMARC от любого, кто отправляет более 5000 сообщений в день их пользователям.

DKIM, вторая опора, — это подпись, встроенная в сообщение. В теории она выживает переадресацию, потому что подписывает содержимое, а не маршрут. На практике любое изменение сообщения её разрушает. Список рассылки, который добавляет подвал «вы подписаны, отписаться здесь», сервер, который переписывает строку темы, даже изменение в переносе строки — подпись больше не совпадает, и DKIM тоже не проходит. Обе опоры упали, DMARC говорит об отказе, и ваша собственная квитанция в папке спама.

Что такое ARC и действительно ли это это исправляет?

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

Загвоздка в «если он доверяет». ARC — это не пароль; это система репутации. Получатель оценивает, является ли ARC-сеалер известным хорошо ведущим себя оператором. Google и проставляет ARC-заголовки, и принимает их от отправителей, которым он доверяет, поэтому переадресация из Gmail в Gmail обычно выживает, а переадресация через какой-то древний университетский relay — нет.

Если вы запускаете переадресацию самостоятельно, два конкретных шага помогут. Используйте Server-Side Redirect / SRS-style переписывание, если ваш хост его предлагает, что переписывает адрес отправителя конверта так, чтобы SPF проверялся против вашей переадресации вместо исходного домена. И отдавайте предпочтение переадресации между провайдерами, которые оба поддерживают ARC. Если вы консолидируете аккаунты и хотите, чтобы пункт назначения просто разобрался с проблемой проверки подлинности за вас, это именно тот вид сантехники, который встроен в платформу AI email.

Когда мне прекратить винить свой провайдер?

Когда паттерн — «отказывают только переадресованные письма», провайдер делает свою работу правильно — проблема в протоколе. Вот как это узнать: откройте заголовки потерянного письма и найдите строку Authentication-Results. Если вы видите spf=fail рядом с IP-адресом отправителя, который принадлежит переадресующему серверу, а не исходному отправителю, это SPF, проверяющий неправильный hop. Если dkim=fail появляется в письме, которое прошло через список или relay, редактирующие сообщения, это повреждённая подпись, а не подделка.

Неудобная правда в том, что проверка подлинности электронной почты была приклеена слой за слоем на протяжении двух десятилетий к системе, которая никогда не предполагала, что кто-то будет врать. SPF пришёл в 2006 году, DKIM в 2007, DMARC в 2015, ARC в 2019 — каждый из них закрывал дыру, которую открыл предыдущий. Переадресация — это шов, где все четыре трутся друг о друга, и ваш inbox — это место, где вы ощущаете трение.

@@END@@