Проблема DKIM

Сегодня произошла интересная ситуация, когда один из наших сотрудников не смог связаться с внешней компанией. Он сообщил мне, что почта не доходит до него с одного домена, предположим, это domain.com, хотя его сообщения доходят, другая сторона не получает никаких ответных сообщений с указанием причины отклонения почты. Он попросил меня проверить проблему, я вкратце расскажу, как я это сделал и что вызвало проблему.

Диагностика новостей — Exim

Поскольку мы используем exim в качестве MTA, команды здесь будут специфичны для этой системы, но процесс может быть легко использован и в postfix.
Первая часть информации заключается в том, что если сообщения не возвращаются отправителю, это означает, что они где-то застряли, столкнулись с временной ошибкой, и один из серверов попытается доставить их снова. Это стандартное действие, и в нем нет ничего странного. Те, кто читал нашу статью о том, как работает почта, знают об этом. И важной информацией является то, что сообщения были отправлены с домена domain.com.

Поскольку сообщения где-то застряли, мы проверим нашу очередь сообщений, которые должны быть доставлены, чтобы увидеть, застряли ли они у нас или даже не дошли до нас:

То есть, сообщение находится в нашей очереди уже 66 минут и не может быть доставлено, что может быть немного удивительно, что сообщение находится на нашем сервере и все еще не дошло до адресата, но об этом мы еще поговорим. Следующий тест — проверка журналов с помощью полезной команды exigrep, которая ищет сообщения на основе заданных данных, например, домена, и выводит всю информацию о том, что с ним произошло. Использование простого grep в этой ситуации привело бы к тому, что у нас не было бы всей информации.

То есть, у нас есть причина, сообщение не доставлено, потому что не может найти запись DKIM в зоне DNS, а само сообщение подписано и должно быть проверено, если оно пришло из реального источника, поэтому, чтобы убедиться, мы проверяем, существует ли такая запись, потому что это может быть проблема с нашим локальным DNS-сервером. Для проверки мы будем использовать публичный DNS-сервер от Google:

Итак, у нас есть причина, запись txt для домена zendesk1._domainkey.domain.com не существует, и там наш сервер будет искать DKIM ключ, с помощью которого он сможет проверить подпись. Во-первых, почему zendesk1._domainkey.domain.com? Ранее в журнале были приведены данные DKIM: «d=domain.com s=zendesk1 c=relaxed/relaxed a=rsa-sha256 t=1431354869″, как вы можете видеть, запись s= — это zendesk1, а s означает selector. Он сообщает нам, в каком домене следует искать DKIM-запись, в данном случае zendesk1._domainkey.domain.com, в соответствии с шаблоном: value s._domainkey.value d, d — домен. Если там нет записи txt, это означает, что есть временная проблема с DNS-сервером или кто-то не ввел его туда, как это было в случае с этим доменом.
Сам запрос dig вернул еще одну часть информации, а именно, что DNS-серверы находятся в Cloudflare. Это компания, с которой мы работали, и мы обязательно напишем о ней подробнее. Cloudflare действует как прокси-сервер для веб-сервера, но это требует, чтобы вы также отказались от собственного DNS-сервера, что это значит? Ну, этот кто-то просто не ввел DKIM ключ в зону DNS, поэтому наш сервер не мог проверить, правильно ли подписано сообщение, и ждал с доставкой, пока кто-то добавит DNS запись или DNS сервер начнет отвечать, но это произошло только через 6 часов с момента поступления сообщения на наш сервер, и оно было автоматически возвращено отправителю как недоставленное из-за ошибки DKIM. Я, конечно, проинформировал другую сторону о проблеме, и мы ждем, пока они ее решат.
Хорошим инструментом для проверки правильности конфигурации электронной почты является сайт , просто отправьте письмо по указанному адресу, нажмите кнопку и получите полный отчет. Письма, отправленные с наших доменов, получают 10/10 баллов.

Бонус — Что такое селектор DKIM?

Селектор — это не что иное, как информация о том, каким ключом DKIM было подписано сообщение, и где его искать. Он был введен, чтобы дать администраторам возможность вводить несколько ключей для одного домена, чтобы старые или скомпрометированные ключи могли быть легко отозваны, или вам не нужно следить за ключом, потому что он пропал, вы можете быстро изменить селектор и начать подписывать новым ключом, или даже не менять его вообще, а сразу начать подписывать новым ключом, однако это означает, что сообщения, отправленные во время изменения, могут быть возвращены из-за неправильного ключа.