DKIM перестал проходить после смены почтового сервиса: руководство по миграции CNAME и селекторов (2026)

Опубликовано 2026-07-08

Данные по состоянию на 2026-06-29 · методология v7. Агрегированные данные переписи по 261 миллионам оценённых доменов. См. как мы выставляем оценки.

DKIM ломается после смены сервиса по двум механическим причинам: ваша DNS-панель искалечила CNAME-цели нового сервиса — обычно дописав к ним вашу собственную зону — либо селекторы старого сервиса были удалены до того, как иссякла его почта. Лишь 3,87% доменов — 10 092 481 — имеют полную триаду SPF+DKIM+DMARC, согласно переписи Defaults.Exposed по 261 086 232 оценённым доменам.

Порядок исправления: просканируйте домен, затем проверьте сохранённую цель каждой новой CNAME через dig — цель, оканчивающаяся именем вашего собственного домена, и есть улика. Исправьте записи на авторитативных серверах имён, убедитесь, что новый сервис подписывает и проходит проверки, прежде чем направлять через него реальную почту, и держите селекторы старого сервиса опубликованными, пока его трафик не иссякнет.

Почему DKIM сломался при смене сервиса?

В самом DKIM ничего не изменилось — изменились ваши селекторы. Старый сервис подписывал своими селекторами; новый подписывает другими, обычно делегированными через две-три CNAME-записи, добавленные при подключении. Четыре подвоха объясняют почти каждый послемиграционный сбой DKIM:

Ваша DNS-панель дописала вашу зону к CNAME-цели. Многие панели считают любое вставленное имя хоста относительным и молча сохраняют target.provider.com.yourdomain.com вместо target.provider.com. Запись существует, панель показывает зелёную галочку — а имя не разрешается ни во что.
Путаница с точкой на конце. Одни панели требуют точку на конце (target.provider.com.) как знак «абсолютное имя — не дописывать мою зону»; другие отвергают точку как недопустимую и обрабатывают абсолютность сами. Одно и то же вставленное значение верно в одной панели и искалечено в соседней.
Селекторы старого сервиса удалили в день переключения. Почта, уже подписанная старым сервисом, ещё несколько дней сидит в очередях повторной доставки и путях пересылки; удаление его селекторов — или закрытие старой учётной записи, которое убивает его делегированные CNAME, — задним числом ломает эту почту.
Вы проверяли не на тех серверах имён. Если миграция включала смену серверов имён, исправленные записи могут существовать на одном наборе NS, тогда как получатели всё ещё опрашивают другой.

Лишь 51,84% из 261 миллионов доменов переписи предъявляют обнаружимый DKIM-ключ на момент сканирования (данные на 2026-06-29).

Та же миграция обычно оставляет и мусор в SPF: 1 013 416 доменов — примерно 1 из 138 среди пытающихся настроить SPF — держат две записи v=spf1, классический признак того, что смена провайдера добавила запись вместо слияния. У этой стороны переезда есть собственное руководство: SPF перестал работать после смены почтового провайдера.

Как распознать искалеченную CNAME-запись?

Не доверяйте панели — спросите у DNS, что она сохранила на самом деле. Запросите CNAME-цель для каждого селектора, который выдал новый сервис. Иллюстративный пример, имитирующий делегированный селектор в стиле SendGrid (форма цели у вашего провайдера будет иной):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Провайдер просил s1.domainkey.u1234567.wl123.sendgrid.net — а сохранённая цель оканчивается на .yourdomain.com. Панель дописала зону; это имя не разрешается ни во что, и получатели не находят ключ. Здоровый вариант:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Одиночная точка на конце в выводе dig — это нормально: она помечает полностью определённое имя.) Если цель верна, пройдите на один шаг дальше: dig TXT s1._domainkey.yourdomain.com +short должен вернуть ключ провайдера. Пустой ответ при верной CNAME означает, что проблема на стороне провайдера в цепочке делегирования — завершите его шаг проверки или см. DKIM «no key for signature» для диагностики на уровне селектора.

Регламент миграции: до, во время, после

Сбой обычно не в записях, а в порядке действий. Миграции DKIM проваливаются на переключении, потому что проверка происходит после переезда, когда реальная почта уже не проходит.

Этап	Что делать	Условие перехода дальше
До переключения	Добавьте DKIM-записи CNAME нового сервиса (и записи bounce-домена), затем докажите их работоспособность: выполните `dig` по сохранённой цели каждой CNAME извне вашей сети, завершите собственный шаг проверки сервиса и отправьте тест через новый сервис на подконтрольный вам ящик	Тестовое сообщение показывает `dkim=pass` с `d=`, равным вашему домену, — никогда не направляйте реальную почту через непроверенный сервис
День переключения	Переведите реальный трафик на новый сервис. Не трогайте ничего, принадлежащего старому: оставьте его селекторы, CNAME и учётную запись живыми	Почта нового сервиса проходит у реальных получателей; старый сервис продолжает проходить для всего, что через него ещё течёт
После иссякания	Следите за агрегированными отчётами DMARC, пока селекторы старого сервиса не перестанут появляться (очереди повторной доставки и пересылки живут днями — заложите неделю и больше), затем выведите его записи и учётную запись из эксплуатации	Старые селекторы отсутствуют в отчётах ≥ 7 дней до удаления

Жирная строка — то место, где миграции спасаются или гибнут: каждую проверку из неё можно сделать за несколько дней до переключения, с нулевым риском для живой почты. Механика вывода селекторов из эксплуатации — включая то, почему повторная публикация с пустым p= лучше удаления, — описана в регламенте ротации; эта таблица — о последовательности самой смены сервиса.

Как исправить DKIM после переезда?

Запустите бесплатное сканирование на defaults.exposed, прежде чем трогать DNS. Оно читает ваши живые записи и показывает то, что реально видят получатели, — включая CNAME-цели с дописанной зоной и селекторы, которые не разрешаются.
Составьте список DKIM-записей, которых ожидает новый сервис. Из его панели администратора: для почтовых провайдеров руководства по настройке Google Workspace и Microsoft 365 показывают, где искать; сервисы рассылок и CRM перечисляют свои CNAME в разделе аутентификации домена (см. письма Mailchimp/Brevo/Klaviyo не проходят DMARC).
Проверьте сохранённое значение каждой записи через dig CNAME <name> +short и сравните его посимвольно с тем, что запросил сервис. Цель, оканчивающаяся вашим собственным доменом, = дописанная зона; введите её заново, а если панель продолжает дописывать — добавьте точку на конце (или уберите её, если панель точки отвергает).
Проверьте на авторитативных серверах имён. dig +short NS yourdomain.com, затем повторите проверки CNAME с @<этот сервер имён>. Если миграция меняла серверы имён, проверьте оба набора — получатели могут ещё опрашивать старый, пока делегирование не распространится.
Повторно запустите проверку сервиса и отправьте тестовое сообщение. Заголовок Authentication-Results должен показывать dkim=pass с d=, равным вашему домену, — прохождение на домене сервиса по умолчанию не выравнивается для DMARC.
Оставьте селекторы старого сервиса опубликованными, пока его почта не иссякнет, затем выведите их из эксплуатации осознанно. После этого просканируйте домен заново и проработайте всё остальное, что отмечено на странице исправить DKIM.

Часто задаваемые вопросы

Нужна ли точка на конце моей DKIM CNAME или нет? Это целиком зависит от панели. Точка означает «абсолютное имя — не дописывать мою зону»; одни панели её требуют, другие добавляют за вас, третьи отвергают. Единственный значимый тест — вывод dig CNAME <selector>._domainkey.yourdomain.com +short после сохранения: если цель оканчивается вашим собственным доменом, панель дописала зону, и вам нужна точка (или другой формат ввода).

Можно ли удалить DKIM-записи старого сервиса в день переключения? Нет. Почта, подписанная старым сервисом, ещё находится в очередях повторной доставки и путях пересылки, и удаление ключа, на который она указывает, ломает эти сообщения задним числом. Держите старые селекторы живыми, пока они не перестанут появляться в ваших агрегированных отчётах DMARC — неделю и больше, — и не закрывайте старую учётную запись раньше этого.

И DNS-панель, и новый сервис говорят «проверено», но получатели всё равно не пропускают DKIM. Как так? Два частых случая: сервис проверял по закешированному ответу, тогда как авторитативные серверы имён отдают другое (опросите их напрямую через dig @<ns>), либо DKIM проходит, но на домене по умолчанию сервиса, а не на вашем, и DMARC всё равно не проходит выравнивание. Сканирование различает эти два случая.

Могут ли DKIM-записи обоих сервисов сосуществовать в переходный период? Да — и должны. У DKIM нет правила единственной записи: каждый селектор — отдельное DNS-имя, поэтому записи обоих сервисов живут бок о бок без конфликта, и правилу «держать старые селекторы до иссякания» ничего не мешает. (SPF — противоположность: две записи v=spf1 аннулируют его, поэтому руководство по миграции SPF посвящено слиянию.)

Отправьте владельцу отчёт

Если вы проводите эту миграцию для клиента или работодателя, завершите её доказательством. Когда новый сервис подписывает и выравнивается, повторно запустите бесплатное сканирование и перешлите отчёт с оценкой владельцу бизнеса: датированное, написанное простым языком подтверждение того, что после переезда домен полностью аутентифицирован. Это артефакт, который понадобится при продлении киберстраховки и следующей анкете безопасности от заказчика, — он превращает «миграция завершена» из утверждения в документ.

Проверьте свой DKIM бесплатно

Узнайте, разрешаются ли селекторы вашего нового сервиса — и что именно исправлять, — конфиденциально и только для владельца.

Проверьте свой домен → · SPF сломался после смены провайдера → · Исправить DKIM → · Настроить DKIM в Google Workspace → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.