Return-Path: куда уходят bounce-уведомления

Return-Path это заголовок, который принимающий почтовый сервер сам вписывает в письмо на основании команды MAIL FROM из SMTP-сессии. Он говорит, куда слать отбойники, если письмо доставить не удалось. Отправитель не проставляет Return-Path руками, тот берётся из адреса отправителя в конверте во время SMTP-транзакции.

Конверт SMTP и заголовки письма

Когда MTA соединяется с принимающим сервером, SMTP-диалог начинается с двух ключевых команд.

Адрес из MAIL FROM и становится Return-Path. Совпадать с заголовком From, который видит получатель, он не обязан. В примере выше человек видит в почтовом клиенте «newsletter@example.com», а отбойники уходят на bounce-id-4782@tracking.example.com. На этом разделении держится вся обработка недоставленных писем в больших объёмах.

Зачем разделять From и Return-Path

Для единичных писем разделение не нужно: отправитель и получатель bounces - один и тот же человек. Но в массовых рассылках ситуация другая. ESP отправляет миллионы писем от имени тысяч клиентов. Каждый bounce нужно привязать к конкретному сообщению, конкретному получателю и конкретной кампании.

Для этого используется техника VERP (Variable Envelope Return Path). Return-Path кодирует идентификатор получателя:

Когда bounce приходит на этот адрес, система разбирает его и понимает: это отклонение от user@recipient.com. Без VERP пришлось бы парсить тело bounce-сообщения, что ненадёжно из-за отсутствия единого формата DSN.

Return-Path и SPF

SPF проверяет домен именно из Return-Path (envelope sender), а не из заголовка From. Это критически важно для понимания SPF. Когда принимающий сервер получает MAIL FROM:<bounce@tracking.example.com>, он запрашивает SPF-запись домена tracking.example.com и проверяет, разрешено ли IP-адресу отправляющего сервера отправлять почту от имени этого домена.

Если Return-Path и From используют разные домены, SPF-проверка пройдёт для envelope-домена, но DMARC потребует alignment - совпадение доменов (или хотя бы организационного домена). При relaxed alignment tracking.example.com и newsletter.example.com считаются выровненными, потому что оба принадлежат example.com.

Пустой Return-Path

Специальный случай: пустой MAIL FROM (<>). Он используется для bounce-сообщений (DSN) и автоматических ответов. Когда сервер генерирует уведомление о недоставке, он отправляет его с пустым Return-Path, чтобы избежать бесконечного цикла bounces.

Если bounce на bounce тоже вызовет bounce, сервер получит ещё один bounce и так далее. Null Return-Path разрывает эту цепочку: письма с пустым envelope sender не генерируют bounce-ответов.

Return-Path в заголовках письма

Принимающий сервер записывает Return-Path как первый заголовок сохранённого сообщения. В исходном тексте письма вы увидите:

Если в заголовках два Return-Path - это аномалия. Некоторые спам-фильтры расценивают дублирование Return-Path как признак поддельного сообщения. По стандарту Return-Path должен быть один и устанавливается только финальным принимающим сервером.

Ошибки настройки Return-Path

• Return-Path на несуществующий домен. Если домен из MAIL FROM не разрешается в DNS, принимающий сервер может отклонить письмо ещё до передачи данных. Многие MTA проверяют существование домена envelope sender.
• Отсутствие SPF для Return-Path домена. SPF проверяется по envelope sender. Если для tracking.example.com нет SPF-записи, проверка вернёт "none", и DMARC с policy=reject отклонит письмо (при условии, что DKIM тоже не пройдёт alignment).
• Ящик Return-Path не принимает почту. Bounce-адрес должен быть рабочим. Если bounces уходят в никуда, ESP не может обновить статус адресов, и вы продолжаете отправлять на невалидные адреса. Это разрушает репутацию.
• Return-Path на стороннем домене без согласования. Если MAIL FROM использует домен, который не связан с доменом From, DMARC alignment не пройдёт. Это частая ошибка при использовании стороннего SMTP без настройки кастомного Return-Path.

Return-Path и валидация email

При проверке email-адреса валидатор выступает в роли отправителя: он открывает SMTP-сессию с сервером получателя и отправляет MAIL FROM. Если Return-Path валидатора настроен некорректно (несуществующий домен, отсутствие SPF, плохая репутация), принимающий сервер может отклонить соединение до этапа RCPT TO, и проверка адреса не состоится.

Для точной валидации важна не только корректность проверяемых адресов, но и безупречная инфраструктура самого валидатора, включая рабочий Return-Path с правильными DNS-записями.