Как я разбираю письмо, которое Яндекс отправил в спам

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

Письмо отклонено или уже лежит в папке «Спам»?

Я начинаю с развилки: сервер получателя отказал в приёме или письмо принято и оказалось в нежелательной почте. Для отправителя оба события выглядят как «меня не читают», но доказательства у них разные. Если сообщение видно в папке «Спам», у получателя уже есть экземпляр для исследования. Если пришёл отчёт о недоставке, нужен полный ответ сервера, отказавшего в приёме. При настройке корпоративной почты я проверяю оба сценария отдельно: исправление должно соответствовать месту, где остановилось письмо.

Текст Message rejected under suspicion of SPAM в отчёте Яндекса означает, что письмо распознано как спам и отклонено. Это не уведомление о перекладывании во внутреннюю папку и не доказательство попадания домена в публичный список блокировок. Я сохраняю ответ целиком вместе с датой, временем и сервером, который его выдал. Одинаковая английская фраза может встретиться и при отправке через Яндекс, и при доставке на Яндекс; направление соединения нужно установить по журналу. Одной вырезанной строки для этого мало.

Папка «Отправленные» подтверждает действие в почтовой программе. Для следующего шага я прошу администратора найти передачу сообщения серверу назначения: кто подключался, какой адрес обслуживал и чем закончилась попытка. Копия у отправителя не доказывает появления письма во «Входящих» адресата. Если письмо ещё ждёт отправки, разбирать его содержание как причину попадания в спам преждевременно. Сначала устанавливаю, дошло ли оно до системы получателя. Конверт на рабочем столе ещё не означает, что почтальон добрался до двери.

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

Какие заголовки я читаю в исходнике письма

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

Дальше я сопоставляю From — видимого автора письма, Return-Path — адрес для возвратов, и домен из параметра d= подписи DKIM, если эти поля присутствуют. Они выполняют разные задачи и не обязаны быть одинаковыми адресами. В Authentication-Results ищу результаты проверок SPF, DKIM и DMARC, если принимающая система их записала. Принципиально важно, кто добавил эту строку: произвольному заголовку, который мог принести сам отправитель, доверять нельзя. Для разбора нужен результат принимающей системы, связанный с исследуемой доставкой.

Я не обещаю найти у Яндекса X-Spam-Status или X-Spam-Level. Такие поля могут добавлять отдельные почтовые фильтры; их наличие не делает значение внутренним баллом Яндекса. Если поле есть, устанавливаю его происхождение. Если поля нет, это не доказывает отсутствия фильтрации. В чужом письме нельзя увидеть все правила, которые применил сервис. Приписывать конкретному слову прибавку баллов без диагностических данных — занятная бухгалтерия: суммы есть, первичных документов нет.

По Received я восстанавливаю переходы между серверами и сверяю их с журналом отправки. Message-ID помогает сопоставить экземпляры, но сам по себе не доказывает ни легитимность письма, ни успешную доставку. Для каждого вывода указываю основание: результат проверки, ответ сервера или наблюдение получателя. Если исходника нет, так и пишу: «аутентификация этого экземпляра не проверена». Запись в DNS, просмотренная сегодня, не рассказывает достоверно, какой ответ получил фильтр в момент вчерашней отправки. Поэтому после изменения настроек нужен новый тест.

Что проверить в SPF, DKIM, DMARC и обратном DNS

Я проверяю настройки того источника, который действительно отправил проблемное письмо. В офисе почтовая программа, сайт и учётная система могут использовать разные маршруты. Успешный тест из браузера не проверяет автоматически отправку с сайта. Для SPF выясняю домен конвертного отправителя и фактический исходящий IP, а затем сопоставляю их с политикой. Работать от чужого домена, просто вписав его в From, нельзя считать корректно настроенной отправкой. Если используется внешний сервис, проверяю предусмотренную им аутентификацию собственного домена.

В базе знаний есть полезная конкретика, которую часто пропускают: для одного проверяемого доменного имени нельзя публиковать несколько отдельных SPF-записей. Если при выборе подходят две записи с началом v=spf1, результатом будет permerror. Вторую запись не добавляют «для надёжности» при подключении ещё одного отправителя — состав разрешённых источников согласуют в одной политике. При этом прочие TXT-записи в том же имени не запрещены. Я отдельно проверяю, не осталась ли старая SPF-запись после смены подрядчика: внешне обе выглядят вполне убедительно.

Ещё один факт из базы уточняет RFC 7208: при проверке SPF действует предел в 10 оцениваемых механизмов и модификаторов, требующих DNS-поиска, включая вложенные include. Превышение даёт permerror. Это не универсальный запрет на количество MX-записей домена. Я смотрю цепочку вычисления, а не длину строки глазами. Результат spf=pass означает прохождение именно SPF; он не подтверждает DKIM, согласование доменов или решение антиспама. Даже все успешные проверки аутентификации не обещают попадания во «Входящие».

У DMARC политика p=none не выключает проверку: владелец домена не задаёт предпочтение по обработке писем, проваливших её. Такой режим используют при наблюдении за потоками почты и получении настроенных отчётов. Для DMARC достаточно успешного SPF с согласованным доменом либо успешной согласованной подписи DKIM. Согласование, или alignment, связывает проверенный домен с доменом видимого From по выбранному режиму. Я сначала добиваюсь корректной работы законных источников, затем обсуждаю усиление политики. Совет «сразу поставьте reject» может отрезать собственные уведомления. Строгость настройки сама по себе почту не чинит.

PTR связывает исходящий IP с именем узла; совпадение с адресом или именем автора в From не требуется. Я проверяю обратное разрешение и то, что полученное имя через A или AAAA разрешается обратно в исходящий IP. Настройку обратной зоны обычно запрашивают у владельца адресного пространства, например провайдера площадки. Публикация обычной A-записи не создаёт PTR автоматически. Подробную проверку SPF, DKIM и DMARC я отделяю от текущего разбора: здесь важно проверить конкретное письмо, а не объявить DNS причиной по умолчанию.

Как проверить шаблон письма и условия отправки

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

Сокращать ссылки для улучшения доставки я не советую: Яндекс прямо не рекомендует сокращённые ссылки в требованиях к рассылкам. Для проверки оставляю понятный адрес назначения и смотрю, куда он действительно ведёт. В HTML убираю ненужные редиректы и проверяю соответствие видимого текста фактической ссылке. Обычный деловой PDF не объявляю спамом из-за одного расширения или размера. Если результат меняется при добавлении вложения, изучаю сам файл, формат сообщения и ограничения принимающей стороны. Такой тест даёт направление поиска, но ещё не раскрывает внутреннюю причину решения фильтра.

Рекламную рассылку я отделяю от переписки по действующему проекту. Для рассылки проверяю подтверждённое согласие, работающую отписку и заголовок List-Unsubscribe — это требования Яндекса. Просьбы прекратить рассылку и ответы о несуществующих адресах должны попадать ответственному сотруднику, а не исчезать в забытом ящике. При проверке обычного согласования чертежа не предлагаю механически превращать письмо в рекламный шаблон. Правила конкретного потока нужно соблюдать по назначению. Надпись «полезная информация» над нежелательной рекламой согласия не создаёт.

Параллельно я выясняю, не появилась ли посторонняя отправка: неизвестное приложение, забытая форма сайта, неожиданная очередь сообщений. Проверку публичных списков делаю для фактического источника письма; порядок разобран в материале про чёрные списки почтовых отправителей. Найденная запись требует изучить основание и устранить причину. Отсутствие записи ничего не гарантирует о внутренних оценках Яндекса. Репутацию нельзя измерить одной зелёной отметкой внешнего сервиса, как температуру исправностью термометра.

Резкий всплеск отправки я рассматриваю вместе с возвратами, жалобами и историей потока. Универсальных ступеней прогрева на заданное число писем для любого малого офиса нет. После исправлений возвращаю нужную рабочую нагрузку постепенно, наблюдая за реальной доставкой. Покупку другого домена не назначаю лечением: она не исправляет заражённый сайт, ошибочную подпись или нежелательную рассылку. У нового адреса тоже предстоит выстроить доверие. Если нужна смена площадки по отдельным причинам, её планируют как самостоятельное изменение с проверкой всех источников.

Условный разбор: «План и узел», 27 рабочих мест

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

Для проверки сайта беру два согласованных ящика получателей на Яндексе и три варианта сообщения. Первый — обычный текст, второй — тот же текст с HTML-подписью, третий — исходный рабочий шаблон с вложением. Получается шесть отправок с одинакового источника. Их число — устройство этого примера, а не норма Яндекса. В журнале записываю фактический результат каждой попытки; пустые поля не заполняю догадками. До эксперимента не прошу добавлять адрес в разрешённые, иначе сравнение будет отвечать уже на другой вопрос.

Я использую такую таблицу. Столбец результата заполняется после отправки; заранее обещанных «Входящих» в ней нет. | Вариант | Источник | Получатели | Что фиксирую | |---|---|---|---| | Обычный текст | Сайт | Оба тестовых ящика | Приём, папка, исходник | | Текст с HTML-подписью | Тот же сайт | Те же ящики | Приём, папка, исходник | | Шаблон с вложением | Тот же сайт | Те же ящики | Приём, папка, исходник | Если только исходный шаблон отличается результатом, возвращаюсь к его элементам. Если у сайта отличаются также проверенные домены, сначала разбираю маршрут и аутентификацию.

Предположим, сайт подписывает письмо доменом внешнего отправляющего сервиса, а видимый From принадлежит бюро; согласованного успешного SPF тоже нет. Это проверяемое объяснение провала DMARC, если его подтверждают заголовки. Я настраиваю разрешённую отправку и подпись собственного домена средствами используемого сервиса, затем повторяю тест. При p=none сама неудача проверки не исчезает. Если же у одного адресата результат иной при одинаковом маршруте и проверках, отдельно изучаю его правила. Один случай не даёт права объявить весь домен исправным или заблокированным.

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

Что может сделать получатель и когда нужна поддержка

Если легитимное письмо уже лежит в нежелательной почте, я прошу получателя сохранить исходник, а затем нажать «Не спам!». По справке Яндекса фильтр учитывает и общие, и персональные правила, поэтому у разных адресатов один отправитель может получать разную оценку. Для конкретного ящика проверяю также собственные фильтры и список блокировок. Это полезное действие получателя, но результат у него нельзя распространять на всех пользователей. Просить каждого нового контрагента заранее исправлять свою почту — дорогой способ спрятать неисправность отправки.

Откладывать сохранение проблемного письма нельзя: в базе знаний и справке Яндекса указано, что сообщения из папки «Спам» автоматически удаляются через 10 дней, восстановление удалённых писем невозможно. Поэтому я сохраняю материал для разбора сразу после жалобы. Отдельно предупреждаю о типичной путанице: совет разрешить почтовые адреса Яндекса при Sender verification failed относится к определённой ошибке проверки на стороне другого сервиса при отправке из Яндекса. Это не универсальная инструкция для писем со своего сервера, попадающих в спам у получателя на Яндексе.

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

Закрываю задачу по доказательствам: повторные письма из нужных рабочих источников приняты, проверенные домены согласованы, а согласованные получатели подтвердили папку назначения. Результат отмечаю для исследованных попыток и продолжаю наблюдение за возвратами и новыми жалобами. Гарантию вечных «Входящих» не выдаёт ни запись DNS, ни удачный тест. Для директора полезен конкретный итог: какой поток ломался, что исправили, кто следит за повторением и куда обращаться. Именно такой отчёт я считаю законченной диагностикой, а не обменом мнениями о характере фильтра.

Частые вопросы