После исправления письма хочется сразу увидеть зелёный результат. Но повторная проверка полезна только тогда, когда понятно, что изменилось между отправками. Если одновременно сменить SMTP-сервис, тему, ссылки и оформление, новая папка не покажет, какая правка повлияла на результат.
Цель повторного теста — проверить конкретное изменение в сопоставимых условиях. Для этого нужен исходный отчёт, краткая запись правки и новая отправка. Открытие старой страницы не пересчитывает сохранённые результаты под новые настройки.
Начните с проверяемого вопроса
Сформулируйте гипотезу так, чтобы результат можно было проверить. Например: «После исправления DKIM новая копия должна пройти проверку подписи» или «После замены неработающей ссылки доступность перехода должна подтвердиться».
Вопрос «Стало ли письмо лучше?» слишком широк. Изменение подписи и изменение папки — разные результаты. Подпись может исправиться, а Спам сохраниться. Это не отменяет выполненную работу: техническая ошибка устранена, но диагностика размещения продолжается.
Если исходный отчёт содержит неизвестные состояния, сначала разберитесь с ними. В материале о No data и Unknown описано, почему пропущенный замер нельзя использовать как доказательство плохой доставки.
Сохраните исходное состояние
Запишите дату и время, отправляющую систему, адрес From, версию шаблона и выбранных провайдеров. Сохраните папки отдельных копий, доступные результаты аутентификации и ошибки. Процент без знаменателя и списка ящиков для сравнения недостаточен.
Зафиксируйте содержание правки: «исправлена целевая страница одной ссылки» точнее, чем «почистили письмо». Если менялась инфраструктура, сохраните доступные сведения о маршруте и исходящем IP.
Не рассчитывайте на бессрочное хранение старого отчёта: данные проверки в Check хранятся семь дней. Сохраните необходимые выводы в своём рабочем журнале, ограничив доступ к содержимому письма и диагностическим ссылкам.
Сначала исправьте подтверждённую проблему
Если есть конкретная ошибка, начните с неё. Для DNS-изменения проверьте, что нужная запись опубликована и доступна тем средствам проверки, которыми вы пользуетесь. Затем отправьте новую копию и смотрите результат её аутентификации.
Не назначайте универсальное время ожидания после любой правки DNS. Кеширование и состояние конкретной записи нужно проверять по факту. Таймер сам по себе не подтверждает, что новое письмо уже обработано с нужной конфигурацией.
При исправлении ссылки проверьте нужный адрес и назначение перехода. Не открывайте служебные ссылки, которые могут выполнять действие, лишь ради проверки доступности. Наличие заголовков отписки также не равно проверке рабочего механизма. Требования к one-click описаны в RFC 8058.
Для гипотез меняйте один фактор
Если явных ошибок нет, выберите одно изменение содержимого. Например, сравните рабочий текст с более простым оформлением, сохранив тему, смысл, отправляющую систему и обязательную отписку. Следующим отдельным экспериментом можно проверить вариант ссылок или настроек отслеживания.
Такой порядок не раскрывает внутреннюю модель фильтра. Он уменьшает число возможных объяснений и делает вывод проверяемым. Даже устойчивое совпадение изменения с папкой требует осторожной интерпретации.
Не удаляйте обязательные элементы ради успешного теста. Вариант, который нельзя отправить вашей реальной аудитории, не подтверждает готовность рабочей кампании. Если эксперимент временно упрощал письмо, затем нужно проверить финальный вариант.
Сопоставьте одинаковые наблюдения
Отправьте новую копию тем же способом и выберите сопоставимый набор провайдеров. Не пересылайте старое письмо из личного ящика. Правила подготовки описаны в статье о точной тестовой копии.
Сравнивайте папки отдельных ящиков и возраст наблюдения. Первый результат нового теста и последняя точка старого 24-часового окна относятся к разным стадиям. Такое сравнение возможно, но различие нужно явно указать.
По методологии Check, наблюдение продолжается для той же полученной копии. График не означает, что сервис каждый час отправляет новое письмо. Пропущенные точки сохраняйте как пропуски и не заполняйте предыдущим цветом.
Учебный пример: после правки Входящих стало больше
Предположим, в исходном тесте один провайдер показал Спам, а другой оказался недоступен. После изменения ссылки первая копия найдена во Входящих, вторая тоже получена. Общий процент вырос.
Нельзя всю разницу процента приписать ссылке: изменилась и полнота выборки. Сначала сравните результат первого провайдера с его прежним результатом. Появившуюся вторую копию отметьте отдельно как новое наблюдение.
Затем проверьте, сохранились ли остальные условия. Если отправляющий сервис выбрал другой исходящий маршрут, это ещё одно различие. Его не всегда можно контролировать, но можно не скрывать.
Рабочий вывод: «В новом тесте после замены ссылки копия у этого провайдера найдена во Входящих; причинная связь пока не установлена». Следующая проверка поможет оценить воспроизводимость.
Когда возвращаться к рабочему письму
После диагностических вариантов отправьте итоговый шаблон со всеми нужными элементами. Сохраните подтверждённые исправления, фактические папки и оставшиеся ограничения. Не объявляйте восстановленной репутацию домена по одному удачному тесту.
Создайте новую проверку в Check и отправьте исправленную копию из своей системы. Один понятный вопрос на тест даст больше полезных выводов, чем серия несопоставимых отправок с постоянно меняющимися условиями.