Почему письма попадают в спам, даже если вы не спамер: SPF, DKIM и DMARC простыми словами
Представьте ситуацию.
Вы подготовили красивое письмо, придумали выгодное предложение, собрали клиентскую базу и запустили рассылку.
Система показывает: письмо отправлено. Возможно, даже доставлено.
Но продажи почти не изменились. Клиенты говорят, что ничего не получали. А затем выясняется, что значительная часть писем оказалась в папке «Спам».
Первая мысль — почтовому сервису не понравился текст, слово «скидка» или слишком яркая кнопка.
Однако проблема часто начинается ещё до того, как почтовый сервис анализирует содержание письма.
Сначала он пытается понять:
— кто на самом деле отправил письмо;
— разрешено ли этому серверу отправлять письма от имени указанного домена;
— не изменилось ли сообщение по дороге;
— совпадает ли технический отправитель с адресом, который видит получатель;
— можно ли вообще доверять этому домену.
На первые четыре вопроса отвечают три технологии: SPF, DKIM и DMARC.
Если они отсутствуют или настроены неправильно, даже полезное и ожидаемое письмо может выглядеть для почтового сервиса подозрительно.
«Доставлено» ещё не означает «попало во входящие»
Когда сервис рассылок показывает статус «Доставлено», это обычно означает, что почтовый сервер получателя принял сообщение.
Но после приёма он всё ещё может:
— положить письмо во «Входящие»;
— отправить его в раздел рассылок;
— переместить в спам;
— временно ограничить доставку следующих писем;
— полностью заблокировать отправителя в будущем.
Поэтому доставляемость — это не только факт передачи письма на сервер.
Главный вопрос звучит так:
Куда именно попало письмо после того, как почтовый сервер его принял?
SPF, DKIM и DMARC не гарантируют папку «Входящие». Но без них у отправителя изначально значительно меньше доверия.
SPF: список серверов, которым разрешено отправлять письма
Представьте закрытое мероприятие со списком приглашённых.
На входе охрана проверяет, есть ли имя посетителя в списке. Если есть — его пропускают. Если нет — начинают задавать вопросы.
SPF работает похожим образом.
Владелец домена публикует в DNS специальную TXT-запись, в которой перечисляет серверы и сервисы, имеющие право отправлять почту от имени этого домена.
Упрощённый пример SPF-записи:
v=spf1 ip4:203.0.113.10 include:_spf.mailservice.ru -all
Эта запись сообщает:
— сервер с указанным IP-адресом имеет право отправлять письма;
— серверы подключённого почтового сервиса тоже имеют такое право;
— остальные источники не авторизованы.
Когда письмо приходит на почтовый сервер, он сравнивает IP отправителя с опубликованной SPF-записью.
Если источник разрешён, проверка получает результат SPF Pass.
Если не разрешён — SPF Fail или другой отрицательный результат.
Что SPF действительно подтверждает
SPF отвечает на вопрос:
Разрешил ли владелец домена этому серверу отправлять почту от имени данного технического отправителя?
Но здесь есть важный нюанс.
SPF проверяет домен технического адреса возврата — его также называют MAIL FROM, Return-Path или envelope sender. Этот домен не всегда совпадает с адресом в поле «От кого», который видит получатель.
Поэтому результат SPF Pass сам по себе ещё не доказывает, что видимый адрес отправителя полностью подтверждён.
Эту проблему решает DMARC, о котором поговорим немного позже.
Частые ошибки в SPF
Несколько SPF-записей у одного домена
У домена должна быть одна итоговая SPF-запись. Если разные сервисы предлагают добавить каждый свою отдельную запись, их обычно необходимо корректно объединить.
Забытый сервис
Письма могут отправляться не только из сервиса рассылок, но и с сайта, из CRM, корпоративной почты, системы заказов, службы поддержки и других источников.
Все законные отправители должны быть учтены.
Слишком большое количество include
SPF имеет ограничения на количество DNS-проверок. Если бездумно добавлять всё новые include, запись может стать слишком сложной и возвращать ошибку PermError.
Слишком мягкая политика
Окончание ~all означает мягкое несоответствие, а -all — явный запрет для неуказанных источников.
Но нельзя просто заменить ~all на -all, не проверив предварительно все реальные источники отправки. Иначе можно заблокировать собственные письма.
DKIM: цифровая подпись письма
Если SPF похож на список приглашённых, то DKIM можно сравнить с сургучной печатью на конверте.
Перед отправкой почтовый сервер подписывает определённые заголовки и содержимое письма закрытым ключом.
Получатель находит соответствующий открытый ключ в DNS домена и проверяет подпись.
Если проверка успешна, почтовый сервер понимает:
— письмо действительно подписано владельцем соответствующего домена или уполномоченным сервисом;
— подписанные части сообщения не были незаметно изменены после отправки.
В заголовке письма появляется DKIM-подпись, содержащая в том числе:
— домен подписанта;
— селектор ключа;
— перечень подписанных заголовков;
— криптографическую подпись.
Открытый ключ обычно публикуется по адресу вида:
selector._domainkey.example.ru
Где selector — имя конкретного ключа.
Селекторы позволяют использовать несколько ключей, постепенно заменять старые ключи новыми и разделять разные системы отправки.
DKIM не шифрует письмо
Это распространённое заблуждение.
DKIM не скрывает содержимое письма и не делает его недоступным для чтения. Он подтверждает подпись и целостность выбранных частей сообщения.
Это похоже не на закрытый сейф, а на пломбу.
Письмо по-прежнему можно прочитать, но получатель может проверить, соответствует ли оно тому сообщению, которое подписал отправитель.
Почему DKIM может не пройти проверку
Причины бывают разными:
— письмо отправляется без подписи;
— в DNS опубликован неверный открытый ключ;
— используется другой селектор;
— закрытый и открытый ключи не соответствуют друг другу;
— письмо было изменено после подписания;
— сервис начал использовать новый ключ, но DNS ещё не обновился;
— старая запись была удалена слишком рано.
Важно не только добавить TXT-запись в DNS. Необходимо убедиться, что отправляющий сервер действительно подписывает письма соответствующим закрытым ключом.
DMARC: правило, которое связывает SPF, DKIM и видимый адрес отправителя
Вернёмся к примеру с охраной.
SPF проверил, что автомобиль имеет право въехать на территорию.
DKIM подтвердил, что документы не были изменены.
Но остаётся ещё один вопрос:
Действительно ли эти документы относятся к человеку, имя которого указано на пропуске?
Именно это проверяет DMARC.
DMARC анализирует домен в видимом поле From — то есть в адресе, который увидит получатель, — и сравнивает его с доменами, подтверждёнными через SPF и DKIM.
Такое соответствие называется alignment — выравниванием или согласованием доменов.
Для успешного прохождения DMARC необходимо, чтобы:
— SPF прошёл проверку и его домен был согласован с доменом в поле From;
или
— DKIM прошёл проверку и домен подписи был согласован с доменом в поле From.
Достаточно одного правильно согласованного механизма. Но на практике лучше добиваться корректной работы и SPF, и DKIM.
Почему SPF и DKIM могут пройти, а DMARC — нет
Предположим, получатель видит письмо от:
Но технический адрес возврата использует домен:
mailer-service.ru
А DKIM-подпись также создана доменом:
mailer-service.ru
SPF и DKIM могут успешно пройти собственные проверки. Сервис действительно имеет право использовать домен mailer-service.ru, и его подпись корректна.
Но видимый отправитель использует shop.ru.
Если между этими доменами нет необходимого согласования, DMARC для домена shop.ru не пройдёт проверку.
Именно поэтому недостаточно увидеть отдельно:
SPF: Pass
DKIM: Pass
Нужно также проверить:
DMARC: Pass
Политики DMARC
Запись DMARC публикуется в DNS по адресу:
_dmarc.example.ru
Упрощённый пример:
v=DMARC1; p=none; rua=mailto:dmarc@example.ru
Параметр p определяет рекомендуемое действие с письмами, которые не прошли проверку.
Существуют три основные политики.
p=none
Только наблюдение. Владелец домена получает отчёты, но не просит почтовые сервисы изолировать или отклонять письма.
Это разумный начальный режим для сбора информации.
p=quarantine
Подозрительные письма рекомендуется изолировать — например, отправлять в спам.
p=reject
Письма, не прошедшие проверку, рекомендуется отклонять.
Не стоит включать p=reject сразу после добавления первой записи.
Сначала желательно:
— собрать список всех источников отправки;
— проверить SPF и DKIM;
— настроить согласование доменов;
— получать и анализировать DMARC-отчёты;
— убедиться, что легитимные письма проходят проверку.
И только после этого постепенно переходить к более строгой политике.
Как работают SPF, DKIM и DMARC вместе
Запомнить их назначение можно так:
SPF: имеет ли этот сервер право отправлять почту от имени технического домена?
DKIM: действительно ли письмо подписано указанным доменом и сохранилась ли его целостность?
DMARC: совпадает ли подтверждённый домен с доменом, который видит получатель, и что делать при несоответствии?
Вместе эти технологии создают базовый уровень доверия к отправителю.
Но именно базовый.
Почему письмо всё равно может попасть в спам
Предположим, проверки показывают:
SPF: Pass
DKIM: Pass
DMARC: Pass
Означает ли это, что все следующие письма гарантированно попадут во «Входящие»?
Нет.
SPF, DKIM и DMARC подтверждают техническую подлинность отправителя. Но они не подтверждают, что получатели хотят читать его письма.
Спамер тоже может настроить собственный домен технически правильно.
Поэтому почтовые сервисы анализируют множество дополнительных сигналов.
1. Жалобы получателей
Если люди регулярно нажимают «Это спам», репутация отправителя ухудшается.
Даже небольшая доля жалоб может стать проблемой при больших объёмах рассылки.
Крупные почтовые сервисы устанавливают очень строгие ориентиры. Например, Google рекомендует удерживать долю жалоб ниже 0,1% и не допускать достижения 0,3%.
Это означает, что при больших объёмах даже несколько недовольных получателей могут иметь значение.
2. Качество базы
Старые, несуществующие и ошибочные адреса увеличивают количество возвратов.
Особенно опасны:
— купленные базы;
— адреса без подтверждённого источника;
— базы, которые годами не использовались;
— адреса с опечатками в доменах;
— технические и временные почтовые ящики.
Перед массовой отправкой базу необходимо проверять и очищать.
3. Резкий рост объёма
Новый домен, который вчера отправлял десять писем в день, а сегодня внезапно отправил сто тысяч, выглядит подозрительно.
Объём следует увеличивать постепенно, начиная с наиболее активной и лояльной аудитории.
4. Репутация домена и IP-адреса
Почтовые сервисы оценивают историю отправителя:
— сколько писем он отправляет;
— сколько сообщений отклоняется;
— как часто на него жалуются;
— взаимодействуют ли получатели с письмами;
— не замечен ли домен или IP в подозрительной активности.
Если используется общая инфраструктура, на репутацию могут влиять и другие отправители этого сервиса.
5. Отсутствие удобной отписки
Когда человек не может быстро отказаться от рассылки, он нажимает кнопку «Спам».
Поэтому хорошо заметная ссылка отписки защищает не только права получателя, но и репутацию отправителя.
Для массовых отправителей крупные почтовые сервисы требуют также техническую возможность отписаться одним действием.
6. Остальная техническая инфраструктура
SPF, DKIM и DMARC — не единственные технические параметры.
Имеют значение:
— корректная PTR-запись;
— совпадение прямого и обратного DNS;
— нормальное имя сервера в HELO/EHLO;
— защищённое TLS-соединение;
— правильная структура MIME;
— корректные заголовки Date и Message-ID;
— отсутствие подозрительных редиректов;
— репутация доменов в ссылках и изображениях.
7. Содержание и поведение рассылки
Почтовый сервис анализирует не отдельное «запрещённое слово», а совокупность признаков.
Проблемой могут стать:
— вводящий в заблуждение заголовок;
— несоответствие темы содержанию;
— большое количество сомнительных ссылок;
— скрытый текст;
— попытки имитировать другое лицо или компанию;
— одинаковые письма случайной аудитории;
— слишком частые отправки неактивным получателям.
Поэтому замена слова «скидка» на «выгода» обычно не исправляет плохую доставляемость.
Как проверить своё письмо
Отправьте тестовое сообщение на несколько почтовых сервисов и откройте оригинал письма или его служебные заголовки.
Найдите строку Authentication-Results.
В корректно настроенном письме желательно увидеть:
spf=pass
dkim=pass
dmarc=pass
Но не останавливайтесь на слове pass.
Проверьте:
— какой именно домен прошёл SPF;
— какой домен указан в параметре d= DKIM-подписи;
— какой адрес находится в видимом поле From;
— согласованы ли эти домены для DMARC;
— через какой IP-адрес отправлено сообщение;
— какой Return-Path используется;
— присутствует ли корректная ссылка отписки.
Дополнительно используйте постмастер-сервисы почтовых провайдеров. Они позволяют отслеживать репутацию, жалобы, ошибки аутентификации и проблемы с доставкой.
Правильный порядок настройки
Чтобы не создавать новые проблемы, действуйте последовательно.
Шаг 1. Найдите все источники отправки
Составьте список систем, которые отправляют письма от имени компании:
— корпоративная почта;
— интернет-магазин;
— CRM;
— сервис массовых рассылок;
— триггерные рассылки;
— служба поддержки;
— система уведомлений;
— платёжные и логистические сервисы.
Шаг 2. Создайте одну корректную SPF-запись
Она должна учитывать все законные источники, но не содержать лишних разрешений.
Шаг 3. Включите DKIM-подпись
Проверьте не только наличие ключа в DNS, но и фактическое подписание каждого типа писем.
Шаг 4. Добавьте DMARC в режиме наблюдения
Начните с p=none и настройте получение агрегированных отчётов.
Шаг 5. Проверьте согласование доменов
Домен в поле From должен быть согласован как минимум с корректно прошедшим SPF или DKIM.
Шаг 6. Исправьте найденные источники ошибок
Не переходите к строгой политике, пока легитимные письма периодически проваливают DMARC.
Шаг 7. Постепенно усиливайте DMARC
После проверки инфраструктуры можно рассматривать переход к p=quarantine, а затем к p=reject.
Шаг 8. Работайте с качеством базы
Проверяйте адреса и домены получателей, удаляйте постоянные возвраты и не отправляйте письма людям, которые не ожидают рассылку.
Три записи — не формальность, а основа доверия
SPF, DKIM и DMARC иногда воспринимают как технические галочки, которые нужно один раз добавить в DNS и забыть.
Но это не просто набор записей.
Это способ доказать почтовому сервису:
— письмо отправлено разрешённым сервером;
— сообщение подписано ответственным доменом;
— подпись и технический отправитель связаны с адресом, который видит человек;
— владелец домена контролирует использование своего имени.
Правильная настройка не создаёт отправителю безусловно хорошую репутацию и не гарантирует попадание во «Входящие».
Она убирает одну из основных причин не доверять ему.
А дальше репутация формируется качеством базы, реакцией получателей, количеством жалоб, стабильностью отправки и соблюдением правил почтовых сервисов.
Как этот подход реализуется в EcomKit
В маркетинговой экосистеме EcomKit.ru верификация домена и проверка email-адресов и доменов получателей рассматриваются как часть общей системы, а не как необязательные настройки.
Вместе с массовыми и триггерными рассылками это помогает:
— уменьшать количество технических ошибок;
— исключать очевидно некорректные адреса;
— защищать репутацию домена;
— контролировать качество отправки;
— выстраивать автоматические коммуникации с клиентами.
Потому что эффективная рассылка начинается не с кнопки «Отправить».
Она начинается с доверия.
Сохраните эту статью, чтобы проверить настройки своего домена.
В следующих материалах разберём, почему письма могут попадать в спам даже при результатах SPF Pass, DKIM Pass и DMARC Pass, а также какие технические и репутационные показатели нужно контролировать отправителю.