В отчёте SPF, DKIM и DMARC отмечены как успешные, но письмо найдено в Спаме. Это не обязательно ошибка отчёта. Аутентификация проверяет свойства отправки и доменов, а размещение показывает результат обработки конкретной копии принимающей почтовой системой.
Начинать заново всю настройку DNS в такой ситуации не стоит. Сначала убедитесь, что успешные результаты относятся к нужной копии и получены из надёжного источника. Затем отделите подтверждённые технические проблемы от предположений о фильтрации.
Уточните, что именно прошло проверку
SPF относится к технической идентичности SMTP-отправки, которая может отличаться от видимого From. DKIM проверяет подпись подписанных частей письма. Для DMARC нужен успешный SPF или DKIM с доменом, согласованным с доменом From. Это разные проверки, поэтому одного слова pass без контекста недостаточно.
Протокол DMARC описан в RFC 9989. Политика p=none сама по себе не означает провал проверки: она задаёт режим политики. Успешный DMARC также не подтверждает личность человека, который написал письмо, и не обещает нужную папку.
Практический вопрос для отчёта: какой домен проверен, каким методом, на основании какой копии и в какое время? Если этих данных нет, не переносите уверенность из соседнего зелёного блока.
Проверьте источник результата
Заголовок Authentication-Results не становится достоверным только потому, что в нём написано pass. Нужно понимать, какой сервер его добавил и доверяет ли ему система проверки. Границы доверия к таким заголовкам описывает RFC 8601.
Check использует сохранённую локальную проверку или результат доверенного принимающего сервера. Подробности выбранной копии и ограничения изложены в методологии. Если надёжное сопоставление недоступно, неопределённость должна оставаться в выводе.
Не объединяйте успешный SPF одной копии, DKIM другой и DMARC третьей в утверждение «у этого письма всё прошло». Промежуточная обработка и различия маршрутов могут дать разные результаты. Для конкретного вывода нужна привязка к конкретной копии.
Посмотрите, что известно о папке
Откройте строку нужного провайдера. Проверьте, что там действительно Спам, а не дополнительная категория, ожидание или отсутствие данных. Сохраните время обнаружения и последнего подтверждённого замера.
Если первый замер показал Спам, нельзя утверждать, что письмо сначала было во Входящих. Если позже возникла ошибка чтения, она не отменяет предыдущую находку, но и не подтверждает текущую папку.
Так вы получите точную формулировку: «Для этой копии подтверждена успешная аутентификация; в такой-то момент она найдена в Спаме». Эта формулировка оставляет место для дальнейшей диагностики и не приписывает провайдеру неизвестную причину решения.
Что проверять после аутентификации
Посмотрите на оставшиеся выполненные проверки. Есть ли подтверждённая проблема с PTR, совпадение в проверенном блок-листе, неработающая ссылка или незаполненный шаблон? Учитывайте источник IP и время: адрес промежуточного сервера нельзя автоматически считать исходящим IP вашей системы.
Отсутствие совпадений в проверенных списках не доказывает хорошую репутацию у всех провайдеров. Результат относится только к завершённым запросам перечисленных списков. Ошибка запроса также не равна отсутствию записи.
Отдельно оцените свою практику рассылок: ожидают ли адресаты письмо, работает ли отписка, нет ли жалоб и проблем в журналах отправляющего сервиса. Check не измеряет вовлечённость всей аудитории и не устанавливает её долю жалоб. Для этих вопросов нужны данные вашей системы и доступные инструменты провайдера.
Не используйте баллы анализатора как объяснение решения Gmail или Mail.ru. Различия между этими измерениями разобраны в статье о spam score, Delivered и папке письма.
Учебный пример: подпись исправна, ссылка вызывает вопрос
Команда проверяет подписную рассылку. В выбранной копии аутентификация прошла, один тестовый ящик показал Спам. В письме есть ссылка через несколько перенаправлений. Отчёт не доказывает, что именно эта ссылка стала причиной.
Сначала команда проверяет назначение перехода и исправляет обнаруженную ошибку, если она есть. Затем отправляет вариант с рабочей прямой ссылкой, сохраняя систему отправки, тему и остальное содержимое.
Если новая копия оказалась во Входящих, это полезное наблюдение, но пока не окончательное объяснение фильтра. Нужно проверить воспроизводимость результата и учесть различия времени, маршрута и доступности ящиков.
Если папка не изменилась, это тоже результат: выбранная правка не дала ожидаемого эффекта в этой проверке. Следующую гипотезу выбирают по данным, а не по списку универсальных «спам-слов».
Как закончить диагностику понятным выводом
Запишите отдельно: аутентификация, фактическая папка, подтверждённые недостатки, недоступные проверки и следующая гипотеза. Не обещайте восстановление Входящих за определённое число часов и не меняйте идентичность отправителя для обхода фильтров.
Проверьте письмо в Check, отправив его обычным способом на контрольные адреса. Если pass соседствует со Спамом, используйте отчёт для выбора одного проверяемого изменения. Успех аутентификации сужает задачу, но не завершает её.