#Что произошло и как распознать неисправность
После переноса SMTP на новый сервер принимающая сторона возвращает dkim=fail в Authentication-Results или отказывает по политике DMARC. Ранее почта с этого домена проходила проверку. Причина может быть в новой паре ключей DKIM, неправильной TXT-записи, селекторе подписи или изменении текста письма после подписания. DKIM подтверждает, что заголовки и части содержимого, охваченные подписью, не были изменены и что проверка публичным ключом из DNS успешна. Нельзя лечить это удалением DMARC или отключением подписи на основном сервере: сначала определите действительные значения d= и s= в заголовке отправленного письма.
#Причины и отличительные признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Старый ключ остался в DNSНовый сервер подписывает закрытым ключом, который не соответствует опубликованному старому открытому ключу. | В заголовке есть DKIM-Signature, d= и s= верные, но проверка показывает bad signature. | Опубликовать правильный открытый ключ для нужного селектора после подтверждения у MTA. |
| Подпись использует другой селектор или доменПосле переезда изменился s= либо d=, а соответствующего DNS-имени нет. | dig TXT selector._domainkey.example.com +short пуст или NXDOMAIN. | Опубликовать запись для фактических d= и s= либо настроить подпись обратно. |
| Два сервера отправляют письма с разными ключами под одним селекторомВо время миграции часть почты ещё идёт с прежнего сервера. | Сбой зависит от исходящего IP, хотя d= и s= одинаковы. | Использовать отдельные селекторы для разных действующих ключей на переходный период. |
| Письмо меняется после подписиШлюз добавляет подпись, сжимает или преобразует содержимое, затем письмо меняет другой фильтр. | В заголовках dkim=fail при правильном DNS и совпадении ключей. | Проверить порядок подписания и модификации исходящих сообщений. |
#Пошаговая диагностика и исправление
- Получите полные заголовки контрольного письмаОтправьте одно обычное письмо с нового сервера на контролируемый Gmail или другой ящик, где доступен просмотр исходного сообщения. В Gmail откройте письмо → меню с тремя точками → «Показать оригинал». Найдите
Authentication-ResultsиDKIM-Signature. Запишитеdkim=pass/fail,header.d,d=иs=. Не публикуйте полные заголовки с адресами пользователей и внутренними маршрутами. - Убедитесь, что письмо действительно подписано новым серверомВ заголовке
DKIM-Signatureдолжны быть значенияd=(подписывающий домен) иs=(селектор). Если подписи нет, диагностируйте службу подписи нового MTA и исходящий маршрут. Если подпись есть, используйте её фактический селектор: старая инструкция с именемdefaultможет не соответствовать текущей конфигурации. - Прочитайте опубликованный ключ DNSВ терминале Linux выполните
dig TXT selector._domainkey.example.com +short, подставив селекторs=и доменd=из заголовка. Для селектора с точками используйте его целиком. Ожидается TXT сv=DKIM1иp=...либо допустимым набором тегов. Пустая строка и NXDOMAIN могут означать неверное имя, делегирование или отсутствие записи. Если видна CNAME, следуйте её разрешению. - Сверьте публичный ключ с ключом работающего сервераВ почтовой панели найдите раздел DKIM для нужного домена и скопируйте предлагаемую публичную TXT-запись. Если используется OpenDKIM/Exim в собственной конфигурации, администратор должен определить, какой закрытый ключ реально применяется для селектора, не извлекая и не передавая приватный ключ. Сверьте публичную часть с DNS; сохраните старое значение TXT до исправления.
- Проверьте переходный период между серверамиПосмотрите исходящий IP и заголовки двух писем, отправленных в разное время. Если оба старый и новый серверы активны, временно оставляйте старый селектор в DNS для сообщений, которые уже переданы, а новый сервер настройте на отдельный селектор с отдельным ключом. Не публикуйте два несовместимых открытых ключа как две TXT-записи одного и того же DKIM-имени.
- Исправьте только подтверждённое несовпадениеВ авторитетной DNS-панели измените TXT для фактического селектора или создайте новый. Учитывайте правила разбиения длинного TXT-значения у вашего поставщика DNS: части внутри одной TXT-записи объединяются при проверке; отдельные TXT-записи с разными ключами недопустимы для одного селектора. Если проблема в MTA, сохраните конфигурацию и исправьте привязку домена/селектора, затем проверьте синтаксис его штатным средством.
- Исключите изменение письма после подписиЕсли DNS и ключи совпадают, изучите порядок обработки сообщения: содержимое не должно меняться после DKIM-подписи в части, охваченной проверкой. Сравните тест без добавляемого нижнего колонтитула и через используемый шлюз, не отключая антиспам. При работе нескольких служб подписи проверяйте, какая из них добавляет заголовок в реальном маршруте.
- Проверьте новую подпись и согласование DMARCПосле распространения DNS отправьте новое контрольное письмо и убедитесь в
dkim=passдля нужногоheader.d. Затем проверьтеdmarc=pass: DKIM pass при подписи другого, несогласованного с From домена может не удовлетворять DMARC. Если исправление не помогло, верните прежнюю запись/селектор по плану и передайте специалисту обезличенные заголовки и DNS-ответ. - Проверка TXT в терминале без sudoLinux · Терминал (Bash)КомандаПроверка TXT в терминале без sudo. Замените selector и example.com на реальное s= и d= из DKIM-Signature; команда только читает DNS.
dig TXT selector._domainkey.example.com +short
#Как проверить результат и что делать при неуспехе
Исправление подтверждается результатами dkim=pass и, при подходящей политике, dmarc=pass в новом письме. Не ориентируйтесь на старые письма: их подпись уже сформирована прежним ключом и не меняется при правке DNS.