Доставляемость email-рассылок: SPF, DKIM, DMARC и причины попадания в спам
SPF, DKIM и DMARC подтверждают право отправлять письма от имени домена и помогают защищать его от подделки, но сами по себе не гарантируют папку «Входящие». Доставляемость зависит также от репутации, согласия получателей, качества базы, жалоб, частоты, содержания и технических ошибок.
- Что такое доставляемость и почему письмо может пропасть
- Сначала составьте карту всех источников отправки
- Как работает SPF и где чаще ошибаются
- Что подтверждает DKIM-подпись
- Как DMARC связывает SPF, DKIM и адрес From
- От чего зависит репутация домена и IP
- Как качество базы влияет на доставляемость
- Каким должно быть технически аккуратное письмо
- Как диагностировать попадание в спам
- Итоги
- Вопросы и ответы
Что такое доставляемость и почему письмо может пропасть
Отправка, доставка и попадание во «Входящие» — разные события. Почтовый сервис может принять сообщение на свой сервер, а затем положить его в спам. Может временно отклонить отправку, вернуть постоянную ошибку или принять только часть потока. Поэтому высокий процент «отправлено» в сервисе рассылок ещё не доказывает, что подписчики увидели письмо.
Фильтры оценивают сочетание сигналов: подлинность домена, историю IP и домена, долю недействительных адресов, жалобы, реакцию аудитории, резкие изменения объёма, содержание и техническое качество. Точные веса закрыты и различаются между почтовыми системами. Практическая задача отправителя — не угадать один фильтр, а построить предсказуемый разрешённый поток.
| Уровень | Что проверяется | Типичная проблема |
|---|---|---|
| Транспорт | Принял ли сервер письмо | Ошибка адреса, лимит, временный отказ |
| Аутентификация | Разрешена ли отправка и цела ли подпись | SPF, DKIM или DMARC не прошли |
| Репутация | Как ранее вёл себя поток домена и IP | Жалобы, ловушки, резкий объём |
| Содержание | Соответствует ли письмо ожиданию и правилам | Обманная тема, сломанная вёрстка, опасная ссылка |
| Вовлечённость | Нужны ли письма получателям | Давняя база, лишняя частота, нет сегментации |
Сначала составьте карту всех источников отправки
Большинство ошибок возникает не при создании записи, а из-за забытого источника. От имени одного домена могут писать сотрудники, CRM, сервис рассылок, интернет-магазин, система поддержки, платёжный модуль и сервер сайта. Если SPF разрешает только часть, а DKIM подписывает один поток, переход к строгой DMARC-политике начнёт блокировать легитимные письма.
- сервис и владелец внутри компании;
- адрес From, домен возврата и домен DKIM-подписи;
- тип писем: служебные, транзакционные, рекламные;
- примерный объём и обычный график;
- IP или механизм авторизации поставщика;
- срок хранения базы и источник согласия;
- контакт для исправления ошибки.
Разведите разные задачи по поддоменам, если это оправдано объёмом и управлением: например, транзакционные уведомления и маркетинговые рассылки не должны зависеть от одного случайного эксперимента. Но не создавайте десятки доменов ради обхода репутации — такая схема усложняет контроль и не исправляет причину жалоб.
Как работает SPF и где чаще ошибаются
SPF — TXT-запись в DNS, которая перечисляет серверы, имеющие право использовать домен в SMTP-идентификаторе отправителя. Получающий сервер сравнивает источник письма с опубликованной политикой. Официальная документация Яндекс 360 также описывает SPF как список разрешённых серверов и предупреждает, что обновление DNS распространяется не мгновенно.
На домене должна быть одна согласованная SPF-политика. Несколько независимых записей вида v=spf1 дают ошибку, поэтому источники объединяют. Следите за ограничением DNS-проверок, установленным RFC 7208: чрезмерная цепочка include и redirect может закончиться permanent error. Удаляйте сервисы, которыми компания больше не пользуется.
| Элемент | Смысл | Риск |
|---|---|---|
| ip4 / ip6 | Разрешить конкретный адрес или сеть | Запись устареет после смены инфраструктуры |
| include | Проверить политику внешнего сервиса | Длинная цепочка увеличивает DNS-проверки |
| redirect | Передать всю политику другому домену | Нельзя механически смешивать с готовым шаблоном |
| ~all | Мягко пометить неразрешённые источники | Не заменяет мониторинг и исправление |
| -all | Жёстко объявить остальные источники неразрешёнными | Сломает забытый легитимный поток |
Не копируйте значение из статьи без проверки провайдера. Он публикует собственный include, selector и порядок настройки. После изменения запросите TXT-запись из нескольких резолверов и отправьте тестовые сообщения, а не ориентируйтесь только на зелёную отметку в панели.
Что подтверждает DKIM-подпись
DKIM добавляет к письму криптографическую подпись. Отправляющая система подписывает выбранные заголовки и тело закрытым ключом, а открытый ключ публикуется в DNS по адресу selector._domainkey.domain. Получатель проверяет, что подписанные части не изменились и подпись связана с заявленным доменом.
Ключ генерирует почтовый провайдер или ваша инфраструктура. В DNS размещают только открытый ключ; закрытый должен оставаться у подписывающей системы. Selector позволяет иметь несколько ключей и менять их без остановки всей почты. План ротации, владелец и дата последней замены должны быть записаны в техническом реестре.
- Убедитесь, что DKIM ставится на каждый нужный поток, а не только на письма сотрудников.
- Проверьте домен параметра d= и его связь с видимым адресом From.
- Не редактируйте подписанное письмо промежуточным шлюзом без понимания последствий.
- После смены selector оставьте старый открытый ключ на период доставки задержавшихся писем.
- Контролируйте длину и целостность TXT-записи в панели DNS.
Успешный DKIM означает, что конкретная подпись проверена. Он не доказывает согласие подписчика, безопасность всех ссылок и качество содержания.
Как DMARC связывает SPF, DKIM и адрес From
DMARC проверяет не только результаты SPF или DKIM, но и согласование доменов с видимым доменом в поле From. Письмо проходит DMARC, если проходит хотя бы один из механизмов с требуемым alignment. В мае 2026 года RFC 9989 заменил старый RFC 7489 и закрепил актуальную спецификацию DMARC, поэтому старые шаблоны нужно сверять с текущим стандартом и документацией провайдера.
Политика публикуется TXT-записью на _dmarc.example.ru. Значение p=none включает мониторинг без просьбы помещать не прошедшие письма в карантин или отклонять их. p=quarantine и p=reject усиливают защиту, но переход к ним безопасен только после анализа отчётов и исправления всех разрешённых потоков.
От чего зависит репутация домена и IP
Новый домен или IP не имеет истории, поэтому резкий массовый запуск выглядит аномально. Увеличивайте объём постепенно, начиная с активных получателей, которые ожидают письмо. Прогрев — не календарный ритуал, а формирование стабильного потока с низкими ошибками и жалобами.
Репутацию портят недействительные адреса, спам-ловушки, жалобы, резкие скачки, маскировка отправителя и постоянная смена доменов. Раздельная отправка транзакционных и рекламных сообщений помогает диагностике, но не даёт права игнорировать качество базы. Следите за ошибками по типам и провайдерам, а не только за общей средней.
| Сигнал | Что он может означать | Первое действие |
|---|---|---|
| Рост hard bounce | Старая база или ошибки сбора | Остановить сегмент, проверить источник адресов |
| Рост жалоб | Нет ожидания, узнаваемости или контроля частоты | Проверить согласие, тему и сегментацию |
| Отказы одного провайдера | Локальная репутационная или техническая проблема | Изучить SMTP-коды и панель отправителя |
| Падение после нового сервиса | Не настроена аутентификация потока | Сверить SPF, DKIM, From и DMARC-отчёт |
| Резкий спад открытий | Фильтрация, сезонность или искажение измерения | Сопоставить доставку, клики и контрольную группу |
Как качество базы влияет на доставляемость
Отправляйте маркетинговые письма людям, которые дали подходящее согласие и понимают, от какого бренда придёт сообщение. Сохраняйте источник, текст согласия, дату и способ подтверждения. Покупка базы или добавление контактов «из открытых источников» создаёт одновременно правовой и репутационный риск.
Double opt-in не является универсальной обязанностью для каждой ситуации, но помогает подтвердить адрес и намерение подписаться. После регистрации объясните ожидаемое содержание и частоту. В каждом рекламном письме должна быть заметная рабочая отписка; запрос нужно исполнять во всех связанных системах, а не только в одном списке.
- Проверяйте синтаксис адреса при вводе и подтверждайте опечатки.
- Не возвращайте hard bounce в активный список.
- Снижайте частоту для неактивной аудитории и проводите аккуратную реактивацию.
- Создайте центр предпочтений, если у бренда несколько типов коммуникации.
- Исключайте отписавшихся и пожаловавшихся из последующих импортов.
Каким должно быть технически аккуратное письмо
Тема, имя отправителя и адрес должны честно объяснять источник и содержание. Не используйте ложные ответы, фиктивную срочность и маскировку служебного письма. Ссылка ведёт на ожидаемый домен, а страница открывается без подозрительных перенаправлений.
Сделайте текстовую версию, добавьте alt к содержательным изображениям, не превращайте всё письмо в одну картинку. Проверяйте мобильную ширину, контраст, кодировку, подстановки, кнопки и отписку. Большие вложения лучше заменить безопасной ссылкой. URL сокращателей и недавно зарегистрированные домены могут создавать лишнюю неопределённость для фильтра и получателя.
- From и Reply-To принадлежат контролируемому домену.
- Тема соответствует содержанию и не обещает невозможного.
- Персонализация имеет запасной вариант, тестовые метки удалены.
- Все ссылки работают, размечены и ведут на ожидаемые страницы.
- Отписка видна и обрабатывается автоматически.
- Письмо проверено в нескольких клиентах и на телефоне.
Научитесь соединять каналы, контент и аналитику в работающую digital-воронку
На курсе «Интернет-маркетолог» вы разберёте коммуникационные каналы, работу с аудиторией, аналитику и контроль результата кампаний. Преподаватель Зотова Ксения ведёт проекты в digital и помогает выстраивать маркетинг как систему.
Как диагностировать попадание в спам
Не меняйте одновременно домен, тему, шаблон и сервис: вы потеряете причину. Сначала определите масштаб — один провайдер, один поток, один сегмент или вся почта. Затем соберите SMTP-коды, заголовки Authentication-Results, результаты SPF/DKIM/DMARC, изменения объёма и жалобы.
Не используйте сервисы, обещающие «100% Inbox». Решение принимает принимающая почтовая система, а состояние базы и репутации меняется. Профессиональная работа — это контролируемая вероятность, а не гарантия.
Итоги
- Сначала соберите все почтовые потоки, затем меняйте DNS и DMARC-политику.
- SPF разрешает источники, DKIM подписывает письмо, DMARC проверяет alignment с видимым From.
- Строгую DMARC-политику вводят после мониторинга и исправления легитимных отправителей.
- Доставляемость зависит от согласия, чистоты базы, стабильного объёма, содержания и реакции аудитории.
- Диагностика строится на SMTP-кодах, заголовках, отчётах и последовательных тестах.
Вопросы и ответы
- Гарантируют ли SPF, DKIM и DMARC попадание во «Входящие»?
Нет. Они подтверждают право использовать домен и помогают бороться с подделкой. Почтовый фильтр дополнительно учитывает репутацию, жалобы, ошибки адресов, содержание, частоту и реакцию получателей.
- Можно ли создать несколько SPF-записей для разных сервисов?
Нет, независимые SPF-записи на одном имени приводят к ошибке политики. Все разрешённые источники объединяют в одну запись с учётом лимита DNS-проверок и регулярно удаляют неиспользуемые сервисы.
- С какой DMARC-политики безопаснее начинать?
Обычно начинают с p=none и получения агрегированных отчётов. После классификации источников и исправления alignment переходят к более строгой политике. Включать reject без инвентаризации опасно для легитимных писем.
- Почему DMARC не проходит, хотя SPF показывает pass?
Для DMARC недостаточно отдельного SPF pass: SPF-домен должен быть согласован с доменом в видимом From. Альтернативно письмо может пройти через согласованную DKIM-подпись.
- Нужно ли прогревать новый домен для рассылок?
Новому потоку полезно наращивать объём постепенно, начиная с активных получателей. Смысл прогрева — создать предсказуемую историю с низкими ошибками и жалобами, а не просто ждать установленное число дней.
- Что проверить первым при резком попадании писем в спам?
Определите дату и масштаб проблемы, затем проверьте SMTP-коды, Authentication-Results, SPF, DKIM, DMARC, новый источник отправки, изменение объёма, качество сегмента и всплеск жалоб. Не меняйте все элементы одновременно.
Технические рекомендации сверены с RFC 7208, RFC 6376, RFC 9989 и документацией Яндекс 360 на дату публикации. Значения DNS для конкретного сервиса берите только из его актуальной панели и документации.