Баунсы email: как их читать и что значат коды

Что такое баунс и в какие два момента он возникает

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

Возникнуть он может в два совершенно разных момента, и умение их различать — это почти вся диагностика. Ещё два исхода выглядят как отказ с того места, где стоите вы, но отказом не являются:

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

Где на самом деле причина

Отчёт о доставке — это письмо из трёх частей, и его форма зафиксирована ещё RFC 3464. Первая часть — извинение, написанное для человека машиной, ближайшей к вам. Вторая — блок, предназначенный для машин, и только в нём есть факты. Третья — ваше исходное письмо целиком либо только его заголовки, чтобы вы могли понять, о каком именно письме речь.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

Читайте среднюю часть в таком порядке:

Final-Recipient:

Какой именно адрес не сработал. В одном отчёте может быть блок на каждого получателя, так что при письме, отправленном нескольким людям, только так вы поймёте, о ком идёт речь, — а остальные вполне могли дойти.

Action:

failed — это баунс. delayed — предупреждение о том, что сервер всё ещё пытается и пока ни от чего не отказался; позже может прийти второй отчёт о том, что всё получилось. relayed и delivered — это вообще не отказ, хотя их легко принять за него.

Status:

Расширенный код статуса — три числа, предназначенные скорее для программ, чем для вас. Это единственная часть, которую можно сравнивать между разными провайдерами, — в отличие от произвольных фраз.

Diagnostic-Code:

Строка, которая действительно важна. Это дословный ответ дальнего сервера — с его кодом ответа и той фразой, которую написал его администратор. Всё, что выше, — пересказ; это — оригинал.

Remote-MTA:

Какой именно хост это сказал. Стоит взглянуть, если отказ связан с маршрутизацией: незнакомое имя хоста обычно значит, что почта домена уходит не туда, куда вы ожидали, — или туда, куда она уходила когда-то раньше.

Фраза в самом верху отчёта — не доказательство. Её пишет ваш собственный исходящий сервер теми словами, что зашиты в его программное обеспечение, — про отказ, который он лишь передаёт дальше. Два одинаковых извинения вполне могут стоять над двумя совершенно не связанными строками Diagnostic-Code:, и именно поэтому баунс, прочитанный сверху вниз, так часто понимают неправильно.

Два числа и цифра, которая всё решает

Отказ записывается вот так, и это три разные вещи, соединённые пробелами:

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

550 — это код ответа: три цифры, определённые самим SMTP в RFC 5321, — именно та часть, которая нужна протоколу, чтобы решить, что делать дальше. 5.1.1 — расширенный код статуса из RFC 3463, добавленный потому, что трёх цифр не хватало для выражения смысла. Всё, что идёт после, — произвольный текст, который пишет тот, кто управляет этим сервером, и он не стандартизирован вообще ничем.

Оба числа начинаются с одной и той же цифры, и именно она — вердикт:

Второе число — это тема, категория того, что пошло не так. Это самый быстрый способ сориентироваться в коде, который вы видите впервые:

Жёсткий баунс (hard bounce)

Это 5. Адрес неверен, исчез, либо отказ — вопрос принципа, и повторная отправка того же письма ничего не изменит. Массовые отправители удаляют адрес из списка после первого же такого случая, потому что упорство — это ровно то, из-за чего домен-отправитель ограничивают везде и сразу.

Мягкий баунс (soft bounce)

Это 4. Переполненный ящик, занятый сервер, временный отказ по политике. Повторяется само, без чьей-либо помощи, и обычно всё-таки доходит; вы услышите об этом, только если попытки закончатся раньше.

Ни то ни другое не входит ни в одну спецификацию. Это жаргон отрасли рассылок для той самой первой цифры — и его стоит знать, потому что именно в нём отчитывается любой инструмент проверки доставляемости, который вам когда-либо дадут в руки.

Коды, которые вы реально встретите

В реестре IANA их десятки, а в обычной жизни — около дюжины. Вот они — и это покрывает почти любой баунс, который кому-либо доводится читать:

Существуют и коды за пределами этого списка, и каждый из них что-то значит, но код, которого вы никогда раньше не видели, почти всегда окажется .7. — чьей-то политикой, описанной своими словами в строке рядом.

Что бывает и не бывает баунсом на временном адресе

Почти ничего — и это стоит проговорить прямо, потому что три вещи, которые люди здесь называют баунсом, баунсом на самом деле не являются:

«User unknown» здесь невозможен

Сервер принимает любое имя на своих публичных доменах. anything@grabmail.io — это валидный адрес ещё до того, как его кто-то набрал, потому что нет никакого списка ящиков, по которому его можно было бы сверить, — так что 5.1.1 от GrabMail просто не существует в природе. Как устроена временная почта изнутри раскрывает весь механизм.

Истечение срока — не баунс

Письмо удаляется через 5 дней после получения, а к этому моменту отправляющий сервер давно получил 250 и напрочь забыл про весь этот обмен. Никого не уведомляют, потому что ничего не сломалось: письмо доставили, а уже потом удалили. Срок жизни ящика — руководство как раз про эту половину.

Форма, отклонившая адрес, — тоже не баунс

Почта вообще не отправлялась. Сайт сверил домен со списком и отклонил саму форму; до почтового сервера дело не дошло, и читать здесь нечего. Почему формы блокируют одноразовую почту — это другая проблема с другим набором ответов.

Молчание — тоже не баунс

Если письмо, которого вы ждали, так и не пришло, а отчёта никто не присылал, значит, отказ — если он вообще был — произошёл на стороне отправителя, где вам ничего не видно. Письмо, которое не доходит разбирает причины в том порядке, в котором их стоит проверять.

Остаётся ровно один настоящий отказ — это потолок размера. Отправляющий сервер, который заранее объявляет размер, разворачивают немедленно, ещё до того, как сохранён хоть один байт:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Отправитель, который не объявляет размер заранее, получает тот же самый ответ, но в конце письма, когда байты уже посчитаны за него. В обоих случаях код один — 5.3.4, ничего не сохраняется, и живому человеку об этом сообщает его собственная почтовая система, — и именно ради этого имеет смысл отказывать на пороге, а не принимать и потом выбрасывать.

Никакой тариф и никакой заголовок не поднимут этот потолок, и баунса здесь ни для чего другого не бывает: ни квоты на входящие, ни ограничения по скорости, ни отказа из-за того, что имя уже кем-то занято. На общем домене два человека, набравшие одно и то же имя, просто делят один ящик на двоих, — а это уже вопрос приватности, а не доставки.

Баунсы на домене, который вы только что направили сюда

Направить домен на catch-all-ящик — это одна DNS-запись, и почти каждый баунс, который при этом возникает, относится к часу вокруг самого изменения, а не к настройке как таковой. Есть пять случаев, и выглядят они по-разному:

1. Пока записи ещё нет. Домен без MX и без адресной записи в запасе отдаёт отправителям 5.4.4 или 5.1.2: доставлять некуда, и повторять попытки незачем.
2. Пока изменение ещё расходится. Отправители, которые уже успели посмотреть запись, держат старый ответ, пока не истечёт его TTL. Баунс в этом окне называет старый хост в строке Remote-MTA: — именно так вы отличите его от записи, которую просто настроили неверно.
3. Когда оно разошлось полностью. Принимается любое имя на домене, так что «user unknown» становится невозможен и здесь тоже. Одна запись, приоритет 10, указывающая на smtp.grabmail.io, — и больше ничего публиковать не нужно, чтобы почта начала приходить.
4. Если домен раньше публиковал нулевой MX. Припаркованные домены часто несут запись, означающую «этот домен никогда не принимает почту». Отправители, у которых она закэширована, будут отвечать 5.1.10, пока кэш не истечёт, — что бы вы ни опубликовали после.
5. Если домен ещё и отправляет почту. 5.7.26 на исходящей почте вообще не об этом — это ваши собственные SPF или DMARC не покрывают то, что реально отправило письмо. Руководство про домен только на приём — это строгий случай; домену, который ещё и отправляет, нужен обычный поэтапный переход вместо этого.

Прочитать саму запись — и это отвечает почти на всё это ещё до того, как придётся читать баунс:

$ dig +short MX yourdomain.com

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

Баунс на письмо, которого вы не отправляли

Выглядит он в точности как обычный отчёт об отказе — цитирует письмо, которого вы никогда не видели, к получателю, о котором вы никогда не слышали. Никто никуда не взламывался. Кто-то отправил почту, вписав ваш адрес в конверт в качестве отправителя, принимающий сервер забрал её, прежде чем выяснилось, что доставить её не получится, — и дальше поступил с несостоявшимся письмом правильно: написал отчёт и отправил его тому, кто был указан отправителем. То есть вам.

Это явление называют backscatter (обратный спам-«рикошет»), и то, что оно доказывает, стоит сказать прямо: ничего о вашем ящике. Для подделки отправителя конверта не нужен доступ вообще ни к чему — это одна строка, набранная во время сеанса связи. Тому, кто это сделал, был нужен только ваш адрес, и не более того, — а угадать его вполне можно было.

От настоящего баунса это отличают за секунд десять по трём признакам:

• Возвращённое письмо — не ваше. Третья часть отчёта несёт оригинал или хотя бы его заголовки. Если вы никогда его не писали, значит, вы его не отправляли, а всё остальное в отчёте — чужая проблема.
• Цепочка Received: начинается там, где вы никогда не были. Читайте её снизу вверх: самая нижняя строка — это машина, которая на самом деле впустила письмо в сеть, и это точно не ваш провайдер. Чтение заголовка письма объясняет направление чтения и почему нижняя строка — самая честная.
• Даты не сходятся. Backscatter обычно сообщает о письме, отправленном за часы или дни до того, как отчёт дошёл до вас, — из очереди, которая с тех пор всё повторяет попытки для чужой рассылки.

Здесь нечего чинить и не на что отвечать. Если адрес принадлежит домену, которым владеете вы, публикация SPF и DMARC снижает поток единственным способом, который реально работает: принимающий сервер, проверяющий политику отправителя до приёма, отклоняет подделку прямо во время сеанса и вообще ни для кого не порождает отчёт. Три записи для домена только на приём — самая строгая версия этого, и при этом на порядок самая простая в публикации.

Короткое имя на общем публичном домене собирает этого добра больше, чем личный адрес, — по той же причине, по которой оно собирает больше спама: его легко угадать, а мошенник, выбирающий отправителя конверта, не целится именно в вас. Это шум про кого-то другого, и, в отличие от спама, здесь нет кнопки, которая хоть чему-то обучает, — что на самом деле делают элементы управления спамом — руководство про кнопки, которые действительно работают.

В каком порядке его читать

1. Определите, что у вас в руках. Ошибка прямо в вашем почтовом приложении в момент отправки — это отказ. Письмо от MAILER-DAEMON, пришедшее позже, — это отчёт, и читать есть что только в отчёте.
2. Проверьте, что речь о письме, которое вы действительно отправляли. Возвращённая копия — в третьей части. Если она не ваша, это backscatter, и на этом всё.
3. Откройте исходный текст письма. Извинение вверху — это шаблонная фраза вашего собственного сервера, а не причина, и блок для машин по умолчанию нигде не показывается.
4. Найдите Status: и прочитайте первую цифру. 4 ещё повторяется и вполне может сработать сам; 5 — это окончательно, и больше ничего не произойдёт.
5. Прочитайте Diagnostic-Code:. Это собственная фраза дальней стороны, и единственное место, где действительно названо правило, которое вам отказало.
6. Определите вторую цифру. .1. — это адрес, .2. — ящик, .4. — маршрут, .7. — чья-то политика. Обычно этого достаточно, чтобы понять, чья это проблема.
7. Действуйте исходя из того, чья это проблема. Отказ по адресации чинится правильным адресом; отказ по маршруту — исправлением DNS; отказ по политике — выполнением этой политики, либо просьбой к человеку на той стороне заглянуть в собственные логи, — там тот же самый отказ записан куда подробнее, чем в том, что прислали вам.

Есть два действия, которые не помогают никогда. Отправить то же письмо без изменений после 5 — значит просто повторить тот же отказ, а если делать так часто, это разом портит репутацию домена-отправителя везде. А ответ на отчёт не дойдёт ни до кого: он пришёл от пустого отправителя конверта, и именно поэтому он вообще смог дойти до вас.

Вопросы