RSA или Ed25519 для DKIM: DNS, подписи и совместимость

В DKIM алгоритм определяет, каким закрытым ключом почтовая система подписывает сообщение и как принимающая сторона проверяет подпись по открытому ключу из DNS. На практике выбирать приходится не между абстрактно «старой» и «новой» криптографией, а между разными эксплуатационными свойствами: размером ключа и заголовка письма, поведением DNS, поддержкой подписывающего ПО и совместимостью с валидаторами получателей.

RSA остаётся наиболее консервативным вариантом с широкой совместимостью. Ed25519 создаёт значительно более компактные записи и подписи, но его нельзя включать без проверки почтовой инфраструктуры. Для домена с разнородной аудиторией разумным переходным решением обычно становится одновременная подпись писем двумя алгоритмами через разные селекторы.

Что именно сравнивается в DKIM

DKIM использует два связанных, но разных элемента:

• Заголовок DKIM-Signature в письме содержит домен d=, селектор s=, алгоритм a=, хеш тела bh= и собственно подпись b=.
• TXT-запись селектора в DNS содержит тип ключа k= и открытый ключ p=, по которому получатель проверяет подпись.

Для RSA в заголовке обычно указывается a=rsa-sha256, а в DNS — k=rsa. Для Ed25519 используются a=ed25519-sha256 и k=ed25519. В обоих случаях в схеме DKIM применяется SHA-256, но механизм создания цифровой подписи и формат ключа различаются.

Количество битов нельзя сравнивать напрямую. Открытый ключ Ed25519 длиной 256 бит не является аналогом RSA-ключа длиной 256 бит и не становится слабее только из-за меньшего числа в названии. Это разные криптографические конструкции с разными требованиями к длине ключевых данных.

RSA: привычный и совместимый вариант

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

Для RSA DKIM должен использовать SHA-256. Устаревший вариант rsa-sha1 применять нельзя. RSA-ключи короче 1024 бит не должны считаться допустимыми, а для новых конфигураций следует выбирать как минимум 2048 бит. Значение 1024 бита стоит рассматривать только как нижнюю границу совместимости со старыми установками, а не как рекомендуемый выбор для нового селектора.

Увеличение RSA-ключа влияет сразу на два объекта:

• открытый ключ p= становится длиннее и увеличивает DNS TXT-запись;
• значение подписи b= увеличивает заголовок каждого отправленного письма.

RSA-4096 может быть оправдан внутренней политикой организации, но не является автоматическим улучшением DKIM. Такой ключ заметно увеличивает DNS-ответы и подписи, усложняет публикацию записи в некоторых панелях и повышает вычислительную стоимость операций. Стандартные валидаторы должны уметь обрабатывать RSA-ключи до 4096 бит, однако это не устраняет ограничения конкретного DNS-хостинга, почтового фильтра или промежуточного сетевого оборудования.

Ed25519: компактный ключ и короткая подпись

Алгоритм Ed25519 добавлен в DKIM как ed25519-sha256. Открытый ключ имеет фиксированную длину 256 бит, а его представление Base64 в поле p= занимает 44 символа. Поэтому полная запись вида v=DKIM1; k=ed25519; p=... без труда помещается в одну строку TXT.

Подпись Ed25519 имеет фиксированный размер 64 байта, что после кодирования Base64 даёт 88 символов в b=. Для сравнения: подпись RSA-2048 занимает 256 байт, или 344 символа Base64. Таким образом, Ed25519 уменьшает не только DNS-запись, но и служебную часть каждого письма.

Компактность особенно полезна в следующих ситуациях:

• панель DNS неудобно работает с длинными или составными TXT-записями;
• зона подписана DNSSEC, из-за чего ответы дополнительно увеличиваются;
• используются длинные имена домена и селектора;
• важно уменьшить вероятность усечения или фрагментации UDP-ответов;
• в инфраструктуре публикуется много селекторов для разных систем отправки.

Главное ограничение Ed25519 связано не с форматом DNS, а с фактической поддержкой на обоих концах. Алгоритм должен уметь создавать используемый подписывающий модуль, а валидатор получателя — распознавать ed25519-sha256, извлекать ключ k=ed25519 и выполнять криптографическую проверку. Требование стандарта поддерживать алгоритм не означает, что все установленные версии программ, библиотеки, шлюзы и облачные фильтры уже обновлены и собраны с нужными возможностями.

Сравнение RSA и Ed25519

Длины RSA в таблице относятся к распространённому представлению открытого ключа с типичными параметрами. Фактический размер опубликованной записи следует измерять после генерации: к значению p= добавляются теги DKIM, разделители, служебные байты DNS и полное имя селектора.

Почему RSA создаёт сложности в DNS

Одна символьная строка внутри DNS TXT имеет ограничение 255 октетов. Это не означает, что вся TXT-запись ограничена 255 символами: ресурсная запись может содержать несколько строк, которые DKIM-валидатор должен объединить без вставки пробелов.

Например, длинный RSA-ключ в представлении файла зоны выглядит как одна TXT-запись, составленная из соседних строк:

rsa-primary._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=<FIRST_BASE64_PART>"
  "<SECOND_BASE64_PART>"
)

Кавычки, круглые скобки и переносы относятся к синтаксису файла зоны или интерфейса DNS. После получения ответа валидатор должен увидеть одно непрерывное значение. Между частями ключа нельзя добавлять пробел, потому что он изменит данные p=.

RSA-1024 обычно даёт около 216 символов в p= и может поместиться в одну 255-октетную строку вместе не со всеми служебными тегами. Для RSA-2048 значение p= обычно составляет около 392 символов, поэтому запись приходится делить как минимум на два TXT-фрагмента. Для RSA-4096 типичное значение p= приближается к 736 символам и требует ещё большего числа частей.

Важно различать три ограничения:

1. Размер отдельной строки TXT. Решается корректным разделением одной ресурсной записи на несколько строк.
2. Размер полного DNS-ответа. В него входят имя, вопрос, ответ, служебные поля, а при DNSSEC — ещё и криптографические записи.
3. Возможности панели DNS. Одни панели автоматически делят длинное значение, другие требуют ввести части вручную, а некоторые некорректно сохраняют кавычки или создают несколько независимых TXT-записей.

Современный DNS умеет передавать ответы крупнее исходного UDP-предела через EDNS и при необходимости повторять запрос по TCP. Но нельзя считать, что любой сетевой путь одинаково хорошо обрабатывает крупные UDP-пакеты, фрагментацию и TCP-повтор. Межсетевые экраны, старые резолверы и ошибочно настроенные DNS-серверы иногда создают проблемы именно на больших ответах. Ed25519 уменьшает этот риск, но не исправляет общие ошибки DNS.

Почему несколько TXT-записей не заменяют несколько строк

Для одного имени селектора должна публиковаться одна DKIM-запись. Составной TXT с несколькими строками и несколько отдельных TXT-записей — не одно и то же.

Корректная логическая запись:

selector._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=<PART_1>"
  "<PART_2>"
)

Ошибочный вариант — создать в панели два отдельных значения:

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=<PART_1>"
selector._domainkey.example.com. IN TXT "<PART_2>"

Во втором случае DNS возвращает набор из двух ресурсных записей. Валидатор не обязан угадывать их порядок и собирать из них ключ. Результатом может стать ошибка синтаксиса ключа или постоянный отказ проверки подписи.

Если панель не позволяет явно управлять частями TXT, нужно выяснить, разделяет ли она длинное значение автоматически. Проверять следует опубликованный ответ авторитетных серверов, а не только текст, отображаемый в форме управления.

Совместимость валидаторов: стандарт и реальная инфраструктура

Поддержку Ed25519 нужно оценивать на нескольких уровнях:

• Подписывающий компонент должен уметь создать ключ и заголовок ed25519-sha256.
• Криптографическая библиотека, с которой собрано ПО, должна предоставлять необходимые операции.
• Валидатор на стороне получателя должен распознать алгоритм и тип ключа.
• Политика почтового шлюза не должна принудительно отклонять неизвестный или запрещённый локальными правилами алгоритм.
• Средства мониторинга должны корректно показывать результат каждой подписи, а не только один общий статус DKIM.

Название почтового сервера само по себе не гарантирует поддержку. Подписание и проверку нередко выполняет отдельный фильтр, библиотека, milter-модуль или облачный шлюз. Возможности зависят от версии, параметров сборки и настроек. Перед выбором Ed25519 нужно проверять именно тот компонент, который формирует или валидирует DKIM-Signature.

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

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

На VPS или выделенном сервере администратор может обновить подписывающий компонент, но сначала необходимо проверить документацию установленной версии и поддержку используемой криптографической библиотеки. Нельзя переносить настройку для одного DKIM-фильтра в другой: синтаксис ключей, таблиц доменов и подключения к MTA различается.

Если требуется самостоятельно управлять почтовым компонентом и селекторами, подойдёт VPS-сервер с административным доступом.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Двойная подпись как безопасная стратегия перехода

DKIM допускает несколько заголовков DKIM-Signature в одном письме. Это позволяет добавить Ed25519, не отказываясь сразу от RSA. Совместимый получатель проверит обе подписи или выберет поддерживаемую, а старый валидатор сможет использовать RSA.

Для разных алгоритмов нужны разные селекторы. Один селектор указывает на одну DNS-запись с одним типом открытого ключа. Нельзя опубликовать RSA и Ed25519 под одним именем и ожидать, что получатель выберет подходящий ключ.

Условная пара подписей выглядит так:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
 s=rsa-primary; ...
DKIM-Signature: v=1; a=ed25519-sha256; d=example.com;
 s=ed25519-primary; ...

В DNS им соответствуют две независимые записи:

rsa-primary._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=<RSA_PUBLIC_KEY_BASE64>"
)
ed25519-primary._domainkey.example.com. IN TXT
  "v=DKIM1; k=ed25519; p=<ED25519_PUBLIC_KEY_BASE64>"

Обе подписи могут использовать одинаковое значение d=example.com. Если этот домен выровнен с доменом адреса From по правилам DMARC, успешная проверка хотя бы одной подходящей DKIM-подписи может обеспечить прохождение DKIM-пути DMARC. Ошибка или неподдерживаемый алгоритм одной подписи не должны автоматически обесценивать другую успешно проверенную подпись, хотя итоговое решение всегда остаётся за политикой получателя.

Двойная подпись увеличивает заголовок письма и добавляет второй DNS-запрос при полной проверке. Тем не менее это контролируемая цена за совместимость на период внедрения Ed25519. Подробнее о селекторах, смене ключей и миграции без потери доставляемости читайте в статье о ротации DKIM-ключей.

Как организовать селекторы и ротацию

Имя селектора лучше делать уникальным для алгоритма и поколения ключа. Например, rsa-primary и ed25519-primary сразу показывают тип ключа. Конкретная схема может быть другой, но селектор не стоит повторно привязывать к новому ключу.

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

Безопасная ротация строится вокруг нового имени:

1. Создать новую пару ключей и новый селектор.
2. Опубликовать открытый ключ в DNS.
3. Дождаться доступности записи через авторитетные и независимые рекурсивные резолверы.
4. Переключить подписывающую систему на новый закрытый ключ.
5. Сохранить прежнюю DNS-запись на период, достаточный для проверки уже отправленных и задержанных писем.
6. Удалить или отозвать старый ключ только после завершения переходного интервала.

При двойной подписи RSA и Ed25519 ротация каждого алгоритма может выполняться независимо. Необязательно менять обе пары одновременно. Раздельная ротация уменьшает риск одновременной ошибки, но требует понятного реестра активных селекторов, закрытых ключей, дат ввода и плановых дат вывода.

Как проверять DNS и реальные письма

Если доступна утилита dig, опубликованные записи можно запросить отдельно:

dig TXT rsa-primary._domainkey.example.com
dig TXT ed25519-primary._domainkey.example.com

Для длинного RSA-ответа полезно сравнить обычный запрос с запросом по TCP:

dig TXT rsa-primary._domainkey.example.com
dig +tcp TXT rsa-primary._domainkey.example.com

Если зона использует DNSSEC, нужно учитывать увеличенный ответ:

dig +dnssec TXT rsa-primary._domainkey.example.com

В выводе dig составной TXT может отображаться несколькими строками в кавычках. Это нормально, если строки принадлежат одной ресурсной записи и после объединения дают непрерывное значение DKIM. Следует проверить отсутствие лишнего пробела внутри p=, наличие правильного k= и соответствие селектора заголовку письма.

Одного DNS-запроса недостаточно. Нужно отправить тестовые письма через реальный исходящий маршрут и изучить исходные заголовки у получателей. Проверяются:

• наличие обеих подписей;
• правильные значения a=, d= и s=;
• результат каждой подписи в Authentication-Results;
• выравнивание домена d= с From для DMARC;
• отсутствие изменений сообщения после этапа подписания;
• результаты у разных классов получателей, а не только в одном почтовом ящике.

Тест следует проводить для всех фактических источников: основного MTA, сайта, CRM, системы уведомлений, рассылочного сервиса и резервного SMTP-шлюза. Наличие Ed25519 в одном потоке не означает, что остальные системы используют тот же подписывающий компонент.

Типичные ошибки при переходе

Один селектор для двух алгоритмов

RSA и Ed25519 нельзя надёжно разместить под одним селектором. Для каждой подписи создаётся отдельное имя и отдельная TXT-запись.

Несколько TXT-записей вместо составного TXT

Фрагменты RSA-ключа должны быть строками одной ресурсной записи. Если панель создала несколько записей с одинаковым именем, результат проверки становится неопределённым.

Несоответствие a= и k=

Подпись a=ed25519-sha256 должна ссылаться на запись с k=ed25519, а a=rsa-sha256 — на RSA-ключ. Ошибка приводит к постоянному отказу проверки.

Удаление RSA сразу после включения Ed25519

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

Удаление старого ключа сразу после ротации

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

Выбор RSA-4096 без проверки DNS

Больший RSA-ключ создаёт более крупные ответы, особенно в зоне с DNSSEC. Перед вводом нужно проверить авторитетные серверы, ответы по UDP и TCP, работу публичных резолверов и сохранение записи в панели.

Оценка только общего статуса DKIM

При двух подписях общий результат dkim=pass может скрывать ошибку Ed25519, если RSA успешно проверилась. Для миграции нужен раздельный результат по алгоритму, домену и селектору.

Какой вариант выбрать

RSA-2048 подходит, если приоритетом является максимально широкая совместимость, а DNS-провайдер корректно обрабатывает длинные составные TXT-записи. Это консервативный базовый выбор для домена с неизвестным и разнородным кругом получателей.

Ed25519 вместе с RSA-2048 — практичная схема внедрения нового алгоритма. Она позволяет получить компактную современную подпись и одновременно сохранить проверяемость у получателей, которые пока используют старый валидатор или ограниченную сборку.

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

RSA-4096 следует применять не по принципу «чем больше, тем лучше», а при наличии конкретного требования и после проверки DNS-тракта. Для большинства доменов RSA-2048 обеспечивает более удобный баланс между совместимостью и эксплуатационными затратами.

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

Итог

RSA и Ed25519 решают одну задачу DKIM, но создают разную нагрузку на DNS и почтовые заголовки. RSA-2048 обеспечивает наиболее предсказуемую совместимость, однако его открытый ключ приходится публиковать как составной TXT. Ed25519 даёт 44-символьное значение открытого ключа и существенно более короткую подпись, но требует проверки подписывающего ПО и валидаторов получателей.

Для публичного почтового домена безопаснее не заменять RSA одномоментно, а добавить Ed25519 вторым алгоритмом. Разные селекторы, одна подписывающая доменная идентичность, корректно опубликованные ключи и раздельный мониторинг результатов позволяют внедрить Ed25519 без потери совместимости. Отказ от RSA должен быть следствием измерений и подтверждённой поддержки, а не только формального наличия нового алгоритма в стандарте.