Рассылка ушла без ошибки, а покупатель ищет письмо в спаме. В отчете сервиса при этом стоит «доставлено». Противоречия может не быть: принимающий сервер согласился принять сообщение, но затем выбрал для него другую папку. Чтобы разобраться, нужно восстановить путь письма и проверить конкретный участок. Ни одна DNS-запись не гарантирует попадание во входящие. Доставляемость складывается из технической настройки, ожидаемости сообщения и реакции получателей. Ниже — порядок проверки для маркетолога и администратора: что собрать, кому передать задачу и по каким свидетельствам принимать результат.
Сначала определите, что именно не работает
Разделите четыре события: сервис поставил письмо в очередь, принимающий сервер принял его, письмо оказалось во входящих, человек прочитал содержание. Это разные этапы. Уточните у своего сервиса, какое событие он называет доставкой и как учитывает отложенные ответы.
Открытие тоже не равно внимательному прочтению: счетчик зависит от загрузки изображения и поведения почтового приложения. По одному снижению открытий нельзя заключить, что домен заблокирован. Нужны дополнительные признаки: ответы сервера, обращения подписчиков, изменение переходов и распределение проблем по почтовым доменам.
Запишите начало сбоя и последнее изменение: подключили новый сервис, поменяли адрес отправителя, добавили сегмент или резко увеличили объем. Сравнивайте одинаковые типы сообщений. Подтверждения заказов и реактивация давно неактивной базы имеют разный контекст, поэтому общий средний показатель легко скрывает причину.
Составьте карту всех отправителей домена
Частая ошибка — настроить основной сервис рассылок и забыть о письмах сайта. Из одного домена могут писать CRM, магазин, служба поддержки и система уведомлений. У каждого потока своя техническая цепочка. Исправление одного кабинета не подтверждает исправность остальных.
Для каждого потока сохраните назначение, платформу, видимый адрес From, технический домен возвратов и домен подписи DKIM. Добавьте владельца настроек и контрольное письмо с датой. Администратору нужен полный заголовок сообщения, а не только скриншот строки «От кого».
Не пересылайте исходники писем с персональными сведениями в общий рабочий чат. Для внутренней задачи оставьте нужные технические поля и уберите лишнее содержание. Полный экземпляр храните там, где доступ есть у участников расследования. Это позволит обсуждать настройку без распространения клиентской переписки.
Участок | Что сохранить | Какое решение принять |
|---|---|---|
Источник отправки | Платформа, поток, From, ответственный | Какие системы должны быть разрешены |
Аутентификация | Результаты SPF, DKIM, DMARC и проверенные домены | Где исправить запись, подпись или соответствие |
Прием сервером | Время, домен получателя, SMTP-ответ | Разобрать отказ или временную задержку |
Отписка | Заголовки письма и результат тестового отказа | Проверить исключение из следующих отправок |
Аудитория | Источник подписки, ожидания, история общения | Какой допустимый сегмент подходит для пилота |
Разберитесь, за что отвечают SPF, DKIM и DMARC
SPF описывает, каким серверам разрешено использовать определенный домен при отправке. Проверка связана с технической идентичностью SMTP, а не просто с красивым адресом в поле From. Поэтому зеленый SPF у платформы еще не отвечает на все вопросы о вашем видимом отправителе.
DKIM — подпись сообщения, которую получатель проверяет по опубликованному ключу. В заголовках видны результат проверки и домен подписи, обозначенный параметром d=. Настройка требует согласованной работы платформы, которая подписывает письмо, и DNS домена, где размещен открытый ключ.
DMARC связывает проверку с доменом видимого From. Для успешной проверки нужен хотя бы один успешный и согласованный с ним механизм: SPF или DKIM. Соответствие доменов называют alignment. Нельзя проверить только три слова pass, не посмотрев, к каким именам они относятся.
В учебном письме указан From: news@example.com, а SPF и DKIM успешно проверены только для sender.example.net. Это разные домены. При таком условии успешные отдельные проверки не обеспечат DMARC pass для example.com. Домены в примере условные; это объяснение диагностики, а не готовая настройка.
Попросите администратора объяснить результат на контрольном письме каждого потока. Формулировка задачи: «Проверьте, каким механизмом подтверждается соответствие From и почему DMARC проходит». Такой вопрос полезнее просьбы «добавить DMARC», после которой запись появится, а неправильная подпись останется.
Меняйте DNS по карте отправителей
Не копируйте чужую строку SPF из статьи. Список разрешенных источников зависит от ваших платформ. Если компания отправляет письма через несколько систем, администратор должен согласовать их в одной корректной политике для проверяемого имени. Две отдельные конкурирующие SPF-записи не решают задачу.
Стандарт SPF запрещает публиковать несколько записей, из-за которых проверка выберет больше одной политики. Это не означает запрет любых других TXT-записей: записи подтверждения сервисов могут существовать рядом. Перед изменением сохраните текущее состояние зоны и разберите назначение каждой записи.
Для DKIM получите параметры именно своего сервиса: имя селектора, тип записи и значение. Не публикуйте закрытый ключ. После изменения DNS проверьте фактическое письмо, а не только отметку в интерфейсе настройки. Ошибка может находиться в другом потоке или в подписи, которую платформа еще не начала применять.
Политику DMARC ужесточают после проверки легитимных отправителей. Иначе можно затронуть нужные уведомления. План изменения должен содержать ответственного, контрольные потоки, критерий проверки и порядок возврата к предыдущему состоянию. Время обновления DNS также учитывайте при разборе результата: повторная проверка сразу после сохранения не всегда отражает новое состояние.
Учитывайте требования конкретного почтового сервиса
У Gmail есть отдельные требования к письмам в личные ящики @gmail.com и @googlemail.com. Для всех отправителей руководство предусматривает SPF или DKIM, корректные прямые и обратные DNS-записи, TLS и соблюдение формата сообщения. Часть инфраструктуры находится у платформы рассылок: уточните, кто ее обслуживает.
Для массовых отправителей Gmail требует SPF и DKIM, а также DMARC с политикой не ниже p=none и соответствие домена From одному из механизмов. По FAQ Google массовый отправитель — тот, кто приблизился к 5000 письмам или превысил этот объем за 24 часа в личные ящики Gmail.
Google суммирует отправки поддоменов одного основного домена; статус массового отправителя сохраняется после его присвоения. Деление потока между поддоменами не стоит рассматривать как способ избежать требований. Это правила Gmail: не переносите его порог на другие почтовые сервисы без их собственной документации.
Создайте отдельную строку проверки для каждого значимого провайдера получателей. Зафиксируйте ссылку на руководство, дату и применимые условия. Внутренняя инструкция устаревает, если из нее исчезает область действия. «Все провайдеры требуют одинаковое» — слишком широкая формулировка для технического задания.
Проверьте отписку в заголовках и в работе системы
Видимая ссылка внизу письма помогает человеку отказаться от рассылки, но не заменяет технический механизм отписки в один клик. Gmail требует его для маркетинговых и рекламных сообщений массовых отправителей. Транзакционные сообщения вроде сброса пароля имеют другой контекст; не смешивайте потоки ради удобного общего шаблона.
Стандарт RFC 8058 описывает связку List-Unsubscribe с HTTPS-адресом и List-Unsubscribe-Post со значением List-Unsubscribe=One-Click. Нужна действительная DKIM-подпись, покрывающая оба заголовка. Обычная ссылка на страницу настроек или mailto сами по себе не подтверждают реализацию этого механизма.
Маркетологу не нужно вручную собирать запросы отписки. Попросите сервис подтвердить поддержку стандарта и покажите администратору исходник контрольного письма. Затем проверьте путь на тестовом контакте: отказ принят, статус изменился, контакт исключен из следующей подходящей маркетинговой отправки.
Отдельно проверьте интеграции. Если CRM снова выгрузит отказавшийся адрес как активный, работающая кнопка не спасет от повторного письма. Определите, какая система хранит окончательный запрет, как он передается и что происходит при повторном импорте. Результат теста сохраните вместе с настройками потока.
Проверьте ожидания аудитории до увеличения объема
Техническая подпись не превращает неожиданное письмо в нужное. Посмотрите, где человек подписался, какую частоту ему обещали и узнает ли он отправителя. Старую базу нельзя считать готовой к запуску только потому, что адреса сохранились в CRM. Основания общения и актуальность контактов проверяются отдельно.
Начните с понятного сегмента, которому действительно подходит сообщение. Не подменяйте проверку покупкой открытий, искусственными ответами или просьбами массово пометить письма как важные. Такие действия не объясняют, захотят ли реальные подписчики читать будущие рассылки, и искажают наблюдение.
Рост объема планируйте вместе с контролем отказов, жалоб и технических ответов. Универсального безопасного числа писем в день нет: важны история домена, состав базы и возможности платформы. Календарь увеличения согласуйте с ее поддержкой, а при ухудшении сначала разберите причину.
Содержание обращения тоже дает полезные сигналы. Если клиенты регулярно спрашивают, зачем им приходит однотипное предложение, проверьте сегмент и обещание подписки. Аналитика отзывов Спикс помогает разбирать темы обратной связи о продукте и сервисе; настройку DNS и отправку email выполняют соответствующие почтовые системы.
Проведите небольшой проверяемый пилот
До запуска назначьте вопрос пилота. Например: проходит ли аутентификация у нового потока и исчезли ли конкретные технические отказы после исправления. Смена DNS, дизайна, сегмента и частоты одновременно усложнит вывод: команда не поймет, какое изменение связано с результатом.
Контрольные адреса в нескольких почтовых сервисах помогают осмотреть письмо и заголовки. Но попадание одного теста во входящие не доказывает результат для всей базы. Сохраните наблюдение как проверку конкретного экземпляра, а массовый поток оценивайте по доступным отчетам и обращениям.
Готовая карточка проверки. Учебный пример
Поток: еженедельная подборка для подписчиков магазина. Изменение: подключен новый сервис. Симптом: появились отказы у одного провайдера. Владелец задачи: администратор почты.
До пилота: сохранить SMTP-ответы, проверить From и домены аутентификации, исправить подтвержденную причину. После пилота: сравнить тот же тип ответа и повторно прочитать заголовки. Критерий: конкретная ошибка устранена; обещания всеобщего попадания во входящие нет.
В рабочем отчете укажите число попыток, принятых сообщений и отказов с понятными знаменателями. Например, доля отказов среди попыток отвечает на другой вопрос, чем доля жалоб в отчете конкретного провайдера. Не складывайте эти проценты и не сравнивайте показатели без определения.
Если письма продолжают попадать в спам
Передайте поддержке платформы пакет фактов: время отправки с часовым поясом, идентификатор кампании, домен получателя, точный ответ сервера и обезличенные заголовки. Отдельно опишите последнее изменение и масштаб: один адрес, один провайдер или весь поток. Это сокращает число предположений.
Если сервер принимает сообщения, а проблема остается на уровне папки, изучайте репутацию и ожидания аудитории вместе с техническими данными. Один найденный термин в теме письма редко объясняет весь сбой. Проверяйте связь с конкретным изменением, а не редактируйте текст наугад после каждого теста.
Заведите журнал решений: гипотеза, свидетельство, исправление, дата проверки и результат. Неподтвержденную причину так и называйте. При следующем сбое команда сможет отделить известную ошибку настройки от новой проблемы, вместо повторной смены домена и потери истории наблюдений.
Распределите работу между маркетингом и администратором
Маркетолог отвечает за происхождение аудитории, обещанную частоту, понятность отправителя и содержание письма. Администратор проверяет DNS и технические идентичности. Поддержка сервиса разбирает особенности платформы и обслуживаемой ею инфраструктуры. Один общий пункт «доставляемость настроена» скрывает эти разные обязанности и затрудняет приемку работы.
Для передачи задачи приложите карту потоков и перечислите нужные проверки по каждому из них. Не требуйте от исполнителя подтвердить настройку, которую он не контролирует. Если IP-адрес и обратную DNS-запись обслуживает платформа, запросите у нее подтверждение. Если доменную зону ведет ваш подрядчик, согласуйте с ним изменение и способ проверки.
Приемку проводите по фактическому сообщению после изменения. Сверьте адрес From, домен подписи, результат DMARC и наличие заголовков отписки для нужного типа письма. Добавьте проверку других важных потоков, чтобы исправление рассылки не оставило без внимания уведомления магазина. В карточке задачи сохраните дату, исполнителя и обезличенное свидетельство.
Проверьте также замену ответственного. Настройки домена могут пережить увольнение сотрудника и смену агентства, а доступ к кабинету останется у прежнего исполнителя. В рабочей инструкции должно быть понятно, кто может изменить DNS, кто управляет платформой и кто принимает сообщения об ошибках. Секреты и пароли в саму инструкцию не включайте.
После подключения новой системы повторите проверку именно ее потока. Наличие корректной подписи у еженедельной рассылки не доказывает исправность формы сайта. Удобно добавить проверку контрольного письма в порядок запуска интеграции: источник внесен в карту, нужная конфигурация согласована, результат прочитан, владелец назначен. Это небольшая отдельная задача, которую легко потерять при общем запуске проекта.
Для планового пересмотра выбирайте события, которые меняют условия: новая платформа, новый тип писем, заметный рост объема, изменение базы или появление устойчивых жалоб. Сохраняйте предыдущие выводы вместе с их областью действия. Запись «проверено» без указания потока и даты быстро перестает помогать: команда уже не понимает, относится ли она к сегодняшнему отправителю.
Частые вопросы
Решает ли SPF всю задачу?
Нет. Проверяйте применимые требования получателей, подпись DKIM, DMARC и соответствие доменов, а также отписку и аудиторию. SPF решает определенную задачу аутентификации; он не определяет, интересно ли человеку содержание.
Нужно ли немедленно ставить DMARC reject?
Сначала проверьте все легитимные потоки и согласуйте изменение с администратором. Жесткая политика без учета сайта, поддержки и других систем может затронуть нужные письма. Конкретную запись выбирают по устройству вашей почты.
Можно ли подтвердить доставляемость одним тестовым письмом?
Тест подтверждает наблюдение для конкретного сообщения и адреса в момент проверки. Он полезен для чтения заголовков и проверки оформления, но не гарантирует расположение писем у остальных подписчиков.
Если проверка не дала ответа, зафиксируйте, чего именно не хватает: исходника письма, ответа сервера или подтверждения изменения. Назначьте сбор этого свидетельства отдельным действием. Отсутствие данных не подтверждает ни техническую исправность, ни вину конкретной платформы; следующий шаг должен закрывать этот пробел.
Что в итоге
Соберите карту отправителей, результаты аутентификации по каждому потоку, проверку отписки и журнал пилота. Назначьте владельцев изменений. Тогда задача «как не попасть в спам» превратится в последовательность проверяемых действий с понятным результатом и следующей точкой контроля.
Источники
- Gmail: руководство отправителям. Прочитано 20.10.2026.
- Gmail: уточнения для массовых отправителей. Прочитано 20.10.2026.
- GoogleWorkspace: настройкаSPF. Прочитано 20.10.2026.
- RFC8058: отписка в один клик. Прочитано 20.10.2026.
- RFC7208: единственная SPF-политика для имени. Прочитано 20.10.2026.
Разбирайте обратную связь покупателей в Спикс
Темы отзывов помогают выбрать, что уточнить в товаре и объяснениях для покупателей. Посмотрите, как организовать эту работу в Спикс.
Попробовать Спикс