Доменные ошибки после смены DNS: почему письма уходят в спам и как это исправить
В большинстве случаев после смены NS-серверов, хостинга или регистратора письма попадают в спам по одной причине: при переносе зоны потерялись TXT-записи SPF, DKIM или DMARC. Проверка занимает 10 минут: сравните текущую зону с тем, что было до переезда, и верните недостающие записи. Ниже дерево диагностики по симптомам, команды для проверки и отдельный разбор популярной ошибки с проксированием CNAME в Cloudflare.
1. Почему переезд DNS ломает почту
Почтовая аутентификация домена держится на записях DNS-зоны: SPF в TXT-записи корня домена, DKIM в TXT-записи selector._domainkey.example.com, DMARC в TXT-записи _dmarc.example.com. При смене NS, регистратора или хостинга зону приходится пересоздавать вручную или импортировать - именно здесь записи теряются.
Типичный сценарий: сайт переехал, A-запись и MX перенесли, а TXT-записи ESP (SendPulse, Unisender, DashaMail, Mindbox и других) забыли - они не влияют на работу сайта, и их никто не проверяет. Внешне все работает: письма отправляются, SMTP-сервер отвечает accepted. Но у получателей DKIM-подпись не валидируется, SPF не находит include, и фильтры Gmail, Mail.ru и Яндекса относятся к рассылке как к непроверенной.
Вторая группа причин: записи перенесли с ошибками - вторая SPF-запись вместо объединения в одну, обрезанный DKIM-ключ, DMARC переписан с нуля и случайно с p=reject. Третья группа: особенности DNS-провайдера, например проксирование в Cloudflare - отдельный раздел ниже.
2. Дерево диагностики по симптомам
Начните с симптома, который вы наблюдаете, и идите по соответствующей ветке. Не меняйте все записи сразу: так вы не поймете, что именно было сломано.
| Симптом | Вероятная причина и первая проверка |
|---|---|
| Письма в спаме сразу после смены NS | Потеряна TXT-запись SPF или DKIM: dig TXT example.com и dig TXT selector._domainkey.example.com |
| DKIM fail в заголовках писем у всех получателей | Запись селектора не перенесена или ключ обрезан при копировании: проверка DKIM по селектору |
| SPF проходит, DKIM fail только у части получателей | Постоянный fail у всех получателей дал бы обрезанный ключ; расхождение по получателям сразу после смены NS почти всегда пропагация - разные получатели пока опрашивают разные NS с разным содержимым зоны |
| Письма не доходят вообще, возвраты 5.7.1 или 550 | Потеряна или сломана запись DMARC, либо отправка идет с IP вне SPF: смотрите полный текст отказа |
| Корпоративная почта ушла в спам, рассылки в порядке | Перенесли записи ESP, но потеряли SPF или DKIM почтовой системы (Google Workspace, Яндекс 360) |
| DMARC перестал валидироваться, записи на месте | Проверьте alignment: после переезда мог смениться домен в From или домен подписи d= |
| Все записи есть, но проверки то проходят, то нет | DNS propagation: старые и новые NS отдают разные ответы, подождите истечения TTL |
- ✕Все проверки ниже делаются на домене отправителя: для SPF это домен из Return-Path (адрес конверта, MAIL FROM), для DKIM - домен из тега d= в подписи, для DMARC - домен из заголовка From. При отправке через ESP Return-Path нередко стоит на техническом поддомене или домене самого ESP, а не на вашем домене в From - это нормально для SPF, но не путайте его с доменом, который проверяете. Проверять DNS-зону домена получателя бессмысленно.
- ✕Если рассылки идут с поддомена (например, mail.example.com), записи SPF, DKIM и DMARC могут лежать именно в зоне поддомена, а не корневого домена.
3. Проверяем SPF, DKIM и DMARC после переноса
Шаг 1. SPF. Выполните dig TXT example.com (или nslookup -type=TXT example.com в Windows): в ответе должна быть ровно одна запись, начинающаяся с v=spf1. По RFC 7208 несколько SPF-записей на одном имени дают permerror, и SPF считается проваленным. Частая ошибка переезда: старую запись перенесли, новую от ESP добавили рядом, вместо того чтобы объединить include в одну строку, например v=spf1 include:_spf.google.com include:sendpulse.com ip4:203.0.113.10 -all.
Шаг 2. DKIM. Узнайте селектор в кабинете ESP или в заголовке письма (тег s= в DKIM-Signature) и проверьте dig TXT selector._domainkey.example.com: должна быть строка вида v=DKIM1; k=rsa; p=MIIBIjANBg.... Сравните p= с тем, что показывает ESP. Ключи длинные, и при ручном копировании их обрезают или переносят с лишним пробелом, из-за чего подпись перестает валидироваться - справка DashaMail описывает именно такой сценарий.
Шаг 3. DMARC. Проверьте dig TXT _dmarc.example.com и сверьте политику с тем, что было до переезда: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com. Если запись создали заново по шаблону с p=reject, легитимные потоки без корректного alignment начнут отклоняться.
Шаг 4. Сверьте домен в подписи DKIM-Signature: значение d= должно совпадать с вашим доменом. Статистика Postmaster-инструментов привязана к d=, поэтому смена селектора s= ее не уводит, а смена d= обнуляет накопленную историю по домену.
4. Отдельный случай: Cloudflare и проксирование CNAME
Многие ESP выдают DKIM не TXT-записью, а CNAME на свой домен, например: s1._domainkey.example.com CNAME s1.domainkey.u123.wl.sendgrid.net. Если DNS-зона перенесена в Cloudflare и для этой CNAME-записи включен режим проксирования (оранжевое облако), DKIM ломается.
Причина в работе прокси Cloudflare: проксирование рассчитано на HTTP и HTTPS трафик, и на DNS-запрос к проксируемой записи Cloudflare отвечает своими адресами, а не исходным значением. Для сайта это работает, а для DKIM нет: почтовый сервер получателя ждет цепочку CNAME до ключа ESP, а получает A-записи прокси. Подпись не валидируется, DKIM fail.
Лечение: в панели Cloudflare, в разделе DNS, переведите записи _domainkey (и другие почтовые CNAME и TXT) в режим DNS only (серое облако) - проксировать нужно только записи веб-трафика. После переключения подождите TTL и перепроверьте: dig TXT s1._domainkey.example.com @1.1.1.1.
- •В панели Cloudflare отфильтруйте записи со статусом Proxied и проверьте, нет ли среди них _domainkey, mail, smtp и других почтовых имен.
- •Косвенный признак проблемы: dig CNAME selector._domainkey.example.com не возвращает CNAME, а сразу отдает A-записи из диапазонов Cloudflare.
5. MX, корпоративная почта и обратная связь с рассылками
Если после переезда в спам ушла корпоративная почта, проверьте записи почтовой системы: у Google Workspace и Яндекс 360 свои SPF include и DKIM-селекторы из админ-панели. Переносите их отдельно - ESP-записи не восстанавливают записи почтового сервиса, и наоборот.
Отдельно проверьте MX: dig MX example.com. Сломанная MX не всегда влияет на исходящую доставляемость напрямую, но рвет обратную связь: перестают приходить возвраты, DMARC-отчеты на адрес из rua и ответы получателей. Если адрес из Reply-To не принимает почту, вы просто не увидите ответы и отписки от подписчиков, пока не почините MX.
Если почта отправляется с собственного сервера, а не через ESP, проверьте еще PTR и HELO нового IP: при смене хостинга IP-адрес меняется, а PTR-запись за ним не переезжает автоматически, ее настраивает владелец нового IP.
6. DNS propagation: сколько ждать и когда паниковать
После смены NS-серверов разные резолверы какое-то время отвечают по-разному: часть уже опрашивает новые NS, часть держит в кэше ответы старых до истечения TTL. Из-за этого проверка DKIM может проходить у одного получателя и падать у другого в течение нескольких часов. Это нормальная фаза распространения, а не отдельная поломка.
Практический вывод: во время propagation диагностируйте с явным указанием резолвера - запросите ответ у нового NS (dig TXT example.com @ns1.new-dns-provider.com) и у публичных резолверов @1.1.1.1 и @8.8.8.8. Новый NS отдает верные записи, а публичные пока старые: подождите. Расхождение держится дольше суток при коротком TTL: проверьте, корректно ли делегирован домен и совпадают ли NS у регистратора и в зоне.
Важно не путать задержку propagation с ошибкой переноса: если записи нет и на новых NS, ждать бессмысленно, ее нужно добавить. Распространение маскирует только уже существующие записи, а не отсутствующие.
7. Записи на месте, а письма все равно в спаме
Бывает, что DNS пережил переезд без потерь, а доставляемость все равно просела. Тогда причина не в записях, а в сопутствующих изменениях: новый IP отправки без истории, смена ESP, смена домена в From, пауза в отправках, после которой фильтры заново оценивают поток.
Смотрите метрики в Postmaster-инструментах: Google Postmaster Tools API v2 отдает доли прохождения SPF, DKIM и DMARC, долю жалоб и соответствие требованиям Google - упала доля DKIM pass со 100% до 60%, масштаб проблемы виден в цифрах, а не на ощущениях. У Mail.ru в Postmaster есть объем, доставка, жалобы и Репутация, %: средний процент жалоб за 30 дней, меньше лучше.
Сверяйте жалобы с порогами: у Gmail держать уровень ниже 0,1% и никогда не достигать 0,3%; у Mail.ru пороги зависят от месячного объема - до 10 000 писем 1,1%, до 500 000: 1%, до 10 000 000: 0,8%, до 50 000 000: 0,5%, свыше 50 000 000: 0,3%. Жалобы после переезда пересекли порог - спам-проблема сохранится и с идеальным DNS, лечить нужно репутацию и базу, а не записи.
8. Как проверить результат исправлений
Проверяйте в таком порядке. Сначала DNS: dig TXT по корню, _dmarc и каждому селектору, все ответы совпадают с эталонными из кабинетов ESP. Затем письмо: отправьте тестовое письмо на Gmail и на Mail.ru, откройте исходник и убедитесь, что в Authentication-Results стоит spf=pass, dkim=pass, dmarc=pass. Удобно прогнать заголовки через анализатор: он разберет цепочку аутентификации и покажет, на каком шаге сбой.
Затем динамика: следите за долями SPF, DKIM и DMARC и уровнем жалоб в Postmaster-инструментах минимум неделю. Разовый pass ничего не доказывает: важно, чтобы все потоки (рассылки, транзакционные письма, корпоративная почта) стабильно проходили проверки каждый день.
- ✕Перед любой сменой NS, хостинга или регистратора выгрузите полную зону (AXFR или экспорт из панели) и сохраните как эталон.
- ✕После переезда сверяйте новую зону с эталоном построчно, а не по памяти: почтовые TXT-записи невидимы для сайта и теряются первыми.
- ✕Поставьте мониторинг DNS-записей домена: изменение SPF, DKIM или DMARC должно приходить вам уведомлением, а не обнаруживаться по жалобам подписчиков.
Что сделать дальше
Если записи восстановлены, закрепите результат: проверьте домен целиком и настройте контроль, чтобы следующий переезд не повторил историю.
- 1Проверить домен целиком
Прогоните домен через проверку SPF, DKIM, DMARC, MX и черных списков, чтобы убедиться, что после переноса не потерялось ничего еще.
Проверить домен - 2Разобрать заголовки проблемного письма
Если после исправлений письма все еще попадают в спам, посмотрите Authentication-Results конкретного письма в бесплатном анализаторе заголовков.
Открыть анализатор заголовков - 3Обсудить аудит доставляемости
Если переезд затронул несколько потоков и доменов, а причина просадки неочевидна, закажите аудит: проверим DNS, аутентификацию, репутацию и метрики по каждому потоку.
Обсудить аудит