Return-Path в email: куда приходят ошибки доставки
Return-Path — служебное поле email-письма с обратным адресом для сообщений о недоставке и других транспортных ошибках. Поле отражает адрес MAIL FROM из SMTP-конверта. SPF обычно проверяет домен этого адреса, который может отличаться от домена видимого отправителя в From.
Как формируется Return-Path
У email есть две группы данных:
- SMTP-конверт — служебная информация, которую почтовые серверы используют при передаче письма. В неё входят адрес отправителя
MAIL FROMи адрес получателяRCPT TO. - Заголовки и тело сообщения — тема, видимый отправитель
From, получательTo, адрес для ответаReply-Toи содержимое письма.
В начале SMTP-транзакции отправляющий сервер указывает обратный адрес командой:
MAIL FROM:<bounce@example.com>
Это значение также называют reverse-path, envelope sender, envelope from или smtp.mailfrom. Когда сервер выполняет финальную доставку, он записывает обратный путь в заголовок:
Return-Path: <bounce@example.com>
Таким образом, MAIL FROM и Return-Path отражают один и тот же обратный адрес на разных этапах. Первое значение передаётся в SMTP-конверте, второе появляется в доставленном письме. По стандарту RFC 5321, исходная система не должна самостоятельно добавлять готовое поле Return-Path: его формирует система финальной доставки на основе полученного обратного пути.
Если сервер уже принял письмо, но позднее не смог его доставить, уведомление об ошибке направляется по адресу из обратного пути. В сервисах массовых рассылок для этого часто используется отдельный технический адрес, а не рабочий ящик сотрудника.
Чем Return-Path отличается от From и Reply-To
Эти поля содержат адреса, но решают разные задачи.
| Поле | Для чего используется | Кто его видит |
|---|---|---|
From | Показывает автора или отправителя сообщения | Получатель в интерфейсе почтового клиента |
Reply-To | Указывает адрес для ответа на письмо | Почтовый клиент при нажатии «Ответить» |
Return-Path | Содержит обратный адрес для транспортных ошибок, полученный из SMTP-конверта | Почтовые серверы и специалисты при просмотре заголовков |
Например, рассылка может содержать такие значения:
From: Магазин <news@example.com>
Reply-To: support@example.com
Return-Path: <bounce@mail.example.com>
Получатель увидит отправителя news@example.com. При нажатии «Ответить» почтовый клиент подставит support@example.com. Уведомления о недоставке, сформированные после обработки письма сервером, будут направлены на bounce@mail.example.com.
Различие адресов само по себе не указывает на ошибку или подмену. Отдельный Return-Path нужен сервисам рассылок для обработки возвратов. Важно, чтобы домены были корректно настроены и согласованы с правилами email-аутентификации.
Как Return-Path связан с возвратами
Возврат, или bounce, возникает, когда почтовый сервер не принимает либо не доставляет сообщение. Ошибка может быть временной — например, из-за переполненного ящика адресата, — или постоянной, если адрес получателя не существует.
Return-Path нужен для обработки ошибок, которые обнаружены после принятия письма. Почтовый сервер формирует уведомление о недоставке и направляет его по обратному пути. Сервис рассылок анализирует ответ и связывает его с отправкой. Если сервер отклоняет письмо непосредственно во время SMTP-транзакции, код ошибки получает отправляющая система без отдельного уведомления на Return-Path.
Уведомления о недоставке отправляют с пустым обратным путём:
Return-Path: <>
В SMTP это соответствует команде:
MAIL FROM:<>
Пустое значение предотвращает бесконечный обмен ошибками. Если уведомление о недоставке также не удастся доставить, сервер не должен создавать ещё одно уведомление в ответ. Такое поведение предусмотрено стандартом SMTP.
Return-Path не заменяет рабочий адрес поддержки. Ответы подписчиков направляются на Reply-To или From, а технические сообщения о доставке обрабатываются по адресу SMTP-конверта.
Роль Return-Path в SPF и DMARC
SPF обычно проверяет домен обратного пути
Для обычного письма SPF определяет, имеет ли отправляющий сервер право использовать домен из MAIL FROM. После доставки этот домен обычно виден в Return-Path.
Например, при таком заголовке:
Return-Path: <bounce@mail.example.com>
SPF-проверка относится к домену mail.example.com, а не обязательно к домену видимого адреса в From. Результат часто записывается в Authentication-Results:
spf=pass smtp.mailfrom=mail.example.com
Если SPF возвращает fail, нужно проверять DNS-запись домена из smtp.mailfrom (после доставки он также виден в Return-Path). Она должна разрешать отправку с фактически используемого сервера. При пустом MAIL FROM, который применяется в уведомлениях о недоставке, SPF использует домен из HELO/EHLO. Такая механика описана в RFC 7208.
DMARC проверяет согласование доменов
Успешного SPF недостаточно для прохождения DMARC. Домен, подтверждённый через SPF, должен быть согласован с доменом видимого отправителя в From. При нестрогом согласовании достаточно общего организационного домена, при строгом требуется точное совпадение.
Пример несогласованной конфигурации:
From: news@example.com
Return-Path: <bounce@mailer-service.net>
Authentication-Results:
spf=pass smtp.mailfrom=mailer-service.net;
dmarc=fail header.from=example.com
SPF проходит для mailer-service.net, но этот домен не согласован с example.com. DMARC всё же может пройти через DKIM, если DKIM-подпись действительна и её домен согласован с From. Актуальный стандарт DMARC закреплён в RFC 9989, опубликованном в мае 2026 года.
spf=pass означает, что отправляющий сервер разрешён доменом из SMTP-конверта. dmarc=pass дополнительно требует, чтобы прошедший проверку SPF- или DKIM-домен был согласован с видимым доменом в From.
Как проверить Return-Path
Return-Path обычно скрыт в стандартном интерфейсе почтового клиента. Для проверки нужно открыть исходный текст или полные заголовки полученного письма.
Обратите внимание на следующие строки:
Return-Path— какой обратный адрес записан после доставки;From— какой отправитель показан получателю;Authentication-Results— результаты SPF, DKIM и DMARC;smtp.mailfrom— какой домен проверялся через SPF;header.from— какой домен использовался как авторский при проверке DMARC.
Проверка нужна после подключения нового сервиса рассылок, смены отправочного домена, переноса инфраструктуры и при росте ошибок доставки.
Типичные проблемы:
- SPF настроен не для того домена. В DNS настраивают SPF для домена из
From, хотя сервис рассылок использует другой домен в SMTP-конверте. - SPF проходит, но DMARC завершается ошибкой. Домен обратного пути не согласован с доменом видимого отправителя, а подходящей DKIM-подписи нет.
- Возвраты поступают на неподдерживаемый адрес. Отправляющая система не может корректно обработать сообщения о недоставке.
- Return-Path пытаются добавить как обычный заголовок. Обратный адрес должен задаваться через SMTP-конверт, а поле в доставленном сообщении формирует система финальной доставки.
Диагностика Return-Path в Altcraft
После тестовой отправки через Altcraft откройте полные заголовки письма и сопоставьте Return-Path, From и Authentication-Results. Подробнее — в руководстве по настройке собственного From-домена.
Если обнаружен spf=fail, проверьте DNS-настройки обратного домена. Для Cloud-версии Altcraft нужно настроить CNAME-поддомен для обработки возвратов, который направляется на akmta.net и используется в Return-Path. В On-premises-версии домен, с которого уходит MAIL FROM, определяется настройками сендера и пула. При dmarc=fail сравните домен из From с доменами, подтверждёнными через SPF и DKIM.
Транспортные ошибки после запуска рассылки можно анализировать в отчёте о возвратах и отчёте о недоставках. Первый показывает временные ошибки отправки, в том числе по сообщениям, которые могли быть доставлены позднее. Второй содержит информацию о сообщениях, которые в итоге не были доставлены, и причинах этого.
Чтобы разобраться в настройке email-канала, отчётах и сценариях коммуникации, пройдите бесплатный курс Altcraft.
Заключение
Return-Path — технический обратный адрес email, который связан с MAIL FROM в SMTP-конверте. Он используется для обработки транспортных ошибок, обнаруженных после принятия письма. Домен этого адреса обычно совпадает с доменом, по которому выполняется SPF-проверка.
Return-Path не обязан совпадать с From или Reply-To. При диагностике важны три условия: SPF проходит для домена обратного пути, SPF- или DKIM-домен согласован с видимым отправителем для DMARC, а система рассылок корректно обрабатывает возвраты.
Читайте по теме
