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

Return-Path is a header that the receiving mail server writes into the message based on the MAIL FROM command from the SMTP session. It identifies where bounce notifications (non-delivery reports) should be sent when a message cannot be delivered to its intended recipient. The sender does not set Return-Path directly in the message headers - it is derived from the envelope sender address during the SMTP transaction.

SMTP envelope vs message headers

When an MTA connects to the receiving server, the SMTP dialogue begins with two key commands:

The MAIL FROM address becomes the Return-Path. It does not have to match the From header that the recipient sees. In the example above, the recipient sees "newsletter@example.com" in their mail client, but bounces go to bounce-id-4782@tracking.example.com. This separation is fundamental to how modern email systems handle delivery failures at scale.

Зачем разделять 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.

Null 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-записями.