Компания переименовала адрес уведомлений, сохранила привычное имя бренда, и часть получателей Яндекса стала находить сообщения в Спаме. Кажется, что причина очевидна: новый адрес «не понравился» фильтру. Но вместе с ним могли измениться сервис отправки, домен подписи, шаблон или правила получателя. Нужно разделить эти изменения, прежде чем возвращать старое имя или создавать ещё один адрес.
Проверяемая гипотеза состоит не в том, что Яндекс всегда хуже принимает новые адреса. Она уже: наблюдаемое различие связано с новым отправляющим адресом или условиями, которые изменились вместе с ним. Чтобы получить полезный ответ, сначала составьте точную карту изменений и выберите минимальную сопоставимую пару.
Сравните адреса, а не названия
В поле «От кого» есть отображаемое имя и сам адрес From. «Магазин Пример» может остаться прежним, хотя support@example.com заменили на notices@example.com. Отдельно существует адрес для ответов Reply-To, технический адрес возвратов и домен DKIM-подписи. Не называйте все эти поля просто «почтой отправителя»: они выполняют разные задачи.
Для получателя важно ещё одно условие: белый список Яндекса описан для полного конкретного адреса. Поэтому исключение для прежнего адреса не следует считать автоматически действующим для нового. Это возможное объяснение различия одного ящика, но не доказательство общей репутационной проблемы домена.
Составьте короткую историю изменения
Возьмите последнюю старую и первую новую полученную копию. Запишите From, Reply-To, домен подписи, систему отправки, ссылки, вложения и доступные результаты аутентификации. Если одновременно подключили другую CRM или почтового оператора, честно назовите это сменой маршрута, а не чистым экспериментом с адресом. Старое письмо недельной давности не является идеальным контролем для сегодняшнего.
Проверьте, разрешено ли отправляющему сервису использовать новый адрес и домен. Успешная проверка старого адреса не подтверждает новую конфигурацию. При этом не включайте жёсткие политики DNS наугад: сначала выясните действующих отправителей домена. Для интерпретации результатов пригодится чек-лист аутентификации, а изменения согласуйте с владельцем почтовой инфраструктуры.
Подготовьте две сопоставимые отправки
Если старый и новый адреса принадлежат вам и доступны в одной рабочей системе, отправьте с каждого безопасную версию одного уведомления на собственный ящик Яндекса. Используйте один шаблон, одинаковые ссылки, одинаковый тип отправки и небольшой временной интервал. Оба адреса должны быть легитимно настроены; подмена чужого From не является диагностикой.
Сохраните идентификаторы обеих копий. Перед проверкой запишите, есть ли у получателя исключения для старого адреса, и не меняйте их в первой паре. Через десять минут и через час отметьте папки в веб-интерфейсе. Если отправляющий сервис выбрал разные исходящие маршруты, укажите это как ограничение: тогда адрес не остался единственной переменной.
Для второго этапа можно использовать другой собственный ящик без намеренно созданных исключений для этих адресов. Не называйте его «чистым» в абсолютном смысле: у любого ящика есть своя история и настройки. Отправьте туда такую же пару. Это помогает проверить, повторяется ли различие за пределами одного известного получателя, но не превращает два ящика в исследование всей аудитории.
Что делать с результатом
Если новый адрес оказывается в Спаме только там, где для старого было личное исключение, сначала разбирайте настройки этого получателя. Если отличие повторяется в обоих ящиках, сопоставьте аутентификацию и маршруты полученных копий. Подтверждённая техническая ошибка нового адреса даёт конкретную задачу. При отсутствии ошибки сохраняйте гипотезу открытой, а не объявляйте неизвестный «срок доверия Яндекса».
После исправления одного условия повторите пару и сохраните результаты до и после. Не просите всю аудиторию добавлять адрес в белый список как замену корректной отправке. Получатель может сделать личное исключение, но оно не доказывает исправление почтовой инфраструктуры и не отменяет его права не получать ненужные сообщения.
Отдельно проверьте, совпадает ли адрес, на который получатель отвечает, с ожидаемым адресом поддержки. Ошибка Reply-To может не объяснять папку, но после смены From она способна нарушить реальную коммуникацию. Зафиксируйте её как отдельный дефект, не смешивая с доставляемостью. В контрольном опыте ответ отправляйте только на принадлежащий вам адрес и проверяйте отдельным сообщением: успешное получение исходного уведомления не подтверждает исправность обратного пути.
Для отдельного наблюдения запустите проверку Check из той же системы с новым адресом. Яндекс включайте, только если он доступен в текущем наборе. Методология объясняет, почему вывод относится к конкретным копиям и времени проверки. Такой тест помогает увидеть размещение после изменения, но не устанавливает скрытую причину фильтрации по одному результату.
Видео-памятка: что проверить
Видео без звука, 24 секунды. Текстовая версия краткого плана:
- Одинаковое имя компании не означает одинаковый адрес отправителя.
- Сравнивайте старый и новый адрес через один рабочий маршрут.
- Проверьте личные исключения получателя и аутентификацию новых копий.