Ключ создаётся в вашем браузере, а не на нашем сервере
Пару ключей создаёт ваш браузер, поэтому странице нужен JavaScript. На нашем сервере ничего не создаётся, и приватный ключ к нам не попадает.
Приватный ключ DKIM это секрет, которым подписывается ваша почта. Любой, у кого есть его копия, может подписывать письма, и получатели сочтут их вашими. Поэтому генератор, который создаёт ключ на своём сервере, предлагает доверить постороннему ровно то, что вы пытаетесь защитить. Даже при самых лучших намерениях ключ прошёл бы по сети, через веб сервер, и оказался бы в памяти машины, которую вы не контролируете.
Эта страница так не делает. Пару ключей создаёт ваш браузер через WebCrypto, тот же интерфейс, которым он создаёт ключи для TLS, и приватная половина не покидает вкладку. Нет запроса, который бы её нёс, а значит нечего писать в журнал, нечего класть в кеш и нечего попадать в резервную копию, и нам нечего было бы выдать, если бы у нас это потребовали. По этой же причине странице нужен JavaScript: работа идёт на вашей стороне, и серверного запасного варианта нет намеренно.
Ключ живёт только в памяти. После закрытия страницы он пропадает, поэтому скопируйте приватный ключ до того, как уйдёте. Если он всё же потерян, ничего страшного не произошло: создайте новую пару и опубликуйте новую запись.
Для чего нужна каждая половина
DKIM работает парой. Публичная половина публикуется в DNS, чтобы её мог прочитать любой получатель в мире, а приватная остаётся на машине, которая отправляет вашу почту.
- Публичный ключ попадает в запись TXT по имени селектор._domainkey.example.com в виде v=DKIM1; k=rsa; p= и самого ключа следом.
- Приватный ключ ложится на почтовый сервер в файл, который читает только почтовый сервер.
- Селектор это просто имя. Он позволяет одному домену держать несколько ключей сразу, по одному на каждый сервис, который шлёт от его имени.
Публикация записи сама по себе ничего не меняет. Письма подписывает отправляющий сервер, поэтому пока ему не указан приватный ключ, подписи нет и проверять нечего, а опубликованный ключ просто лежит без дела.
Куда класть приватный ключ
Приватный ключ сохраняют файлом на машине, которая подписывает. Владелец файла это пользователь, от которого работает служба подписи, и больше его не читает никто. В Linux это chmod 600 и правильный владелец. Ему не место в git репозитории, в тикете, в чате и на общем диске.
OpenDKIM указывают на файл директивой KeyFile или через KeyTable, если один сервер подписывает за несколько доменов, и рядом называют селектор. Rspamd принимает путь для каждого домена в настройках подписи DKIM. В облачном почтовом сервисе вставить ключ обычно некуда: он сам создаёт свою пару и выдаёт запись для публикации, и тогда эта страница вам не нужна.
Приватный ключ здесь в формате PKCS#8 PEM, который OpenDKIM, rspamd и другие построенные на OpenSSL программы читают напрямую. Инструменту, который требует старый формат с заголовком BEGIN RSA PRIVATE KEY, файл преобразуют командой openssl rsa.
Тот же ключ через openssl
В ключе нет ничего, что было бы привязано к этой странице. Если хочется сделать его у себя или он нужен в скрипте, хватит трёх команд:
openssl genrsa -out mail.private 2048 chmod 600 mail.private openssl rsa -in mail.private -pubout -outform der | openssl base64 -A
Первая команда пишет приватный ключ, вторая запрещает остальным на машине его читать, третья печатает строку base64, которая в записи DNS стоит после p=. Подставьте её в v=DKIM1; k=rsa; p= и опубликуйте это как запись TXT.
Публикация, проверка и смена ключа
После публикации дождитесь, пока запись дойдёт до резолверов, и прочитайте её обратно проверкой записи DKIM. Это вторая половина работы: здесь ключ создаётся, там читается то, что реально видит мир, и только вторая страница может сказать, пережила ли запись вставку в панель управления.
Успешно проверенная подпись сама по себе ещё не защита. DKIM доказывает, что письмо подписано ключом, опубликованным под каким то доменом, и только DMARC требует, чтобы домен в видимом адресе From совпадал с тем, который подписал. Посмотрите, что у вас есть, проверкой записи SPF и проверкой записи DMARC, прежде чем ужесточать политику.
Смена ключа идёт в том же порядке и никогда наоборот. Создайте пару с новым селектором, опубликуйте новую запись, дождитесь, когда она станет видна, переключите почтовый сервер на новый приватный ключ и только потом уберите старую запись. Письма, которые уже в пути, подписаны старым ключом, и он им ещё нужен.