Ключ DKIM: длина, публикация в DNS и смена ключей

Ваш ключ DKIM является частью DNS-настройки, необходимой для успешной аутентификации. Слабый, поврежденный или устаревший ключ может нарушить проверку и повлиять на доставку. В статье описаны требования Gmail с февраля 2024 и дальнейшее усиление контроля с ноября 2025; ориентируйтесь на актуальные правила для отправителей. Если еще приводите в порядок DNS, начните с корпоративной почты и затем вернитесь сюда.

Краткий ответ: по возможности используйте RSA-ключ длиной 2048 бит. Правильно публикуйте его в DNS: длинный TXT часто состоит из нескольких строк в кавычках. Меняйте ключи по графику через селекторы и сохраняйте старую запись на подходящий переходный период. Это снижает эксплуатационные риски.

Для нового домена дополните настройку статьей о создании почты со своим доменом и списком TrekMail необходимые DNS-записи, чтобы вместе настроить DKIM, SPF и DMARC.

Что такое ключ DKIM?

Здесь имеется в виду открытая часть системы подписи. Почтовый сервер подписывает письма закрытым ключом, а получатель получает открытый из DNS и проверяет целостность подписанных частей и связь подписи с доменом. Это не доказывает автоматически личность отправителя, указанного в From.

DKIM означает DomainKeys Identified Mail. Закрытый ключ хранится у отправляющей системы, открытый публикуется под селектором, например s1._domainkey.example.com.

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

• Охваченные подписью части тела и заголовки не изменились способом, нарушающим проверку.
• Подписывающая сторона имела доступ к закрытому ключу этого домена и селектора.

Это не гарантирует попадание во входящие, но дает проверяемый криптографический сигнал для систем фильтрации.

Какую длину ключа DKIM использовать?

RSA-ключ длиной 2048 бит рекомендуется по возможности для конфигураций 2025 и 2026. Стандарт еще допускает 1024 бита, но рекомендует 2048 как более стойкий вариант. Ключи 4096 бит увеличивают DNS-ответы и могут усложнить совместимость и эксплуатацию.

Формальное основание: RFC 8301. Подписывающая сторона обязана использовать RSA не короче 1024 бит и ей рекомендуется применять не менее 2048 бит. Это важно для современной конфигурации.

При получении старой почтовой системы проверьте ключ. Прежние панели часто создавали 1024-битные ключи по умолчанию. То, что было допустимо раньше, не обязательно является оптимальным выбором сейчас.

Google требует DKIM для массовых отправителей и описывает возможное ограничение скорости при неуспешной аутентификации. Актуальные требования приведены в ответах Google о правилах отправки почты.

Почему ключ 2048 бит может неправильно публиковаться в DNS

Ключ 2048 бит длиннее одной строки TXT с пределом 255 октетов. Если панель ожидает одну длинную вставку без правильного разделения, она может отвергнуть, обрезать или неверно сохранить значение.

Чаще проблема не в криптографии, а в интерфейсе DNS.

Значение p= для RSA-ключа 2048 бит обычно приходится делить на несколько строк внутри одной TXT-записи. Их соединяет проверяющее приложение DKIM, а не обязательно DNS-резолвер. Ошибка публикации может нарушить проверку.

Типичные проблемы:

• Панель обрезает запись на 255 символах.
• Добавляет лишние пробелы или переносы внутрь ключа.
• Опубликованы несколько TXT-записей вместо нескольких строк в одной записи.
• При сокращении удалена часть префикса v=DKIM1; k=rsa; p=.

В итоге ключ не становится слабее: он становится некорректным.

Как правильно опубликовать ключ DKIM длиной 2048 бит

Для одного селектора публикуйте одну однозначную TXT-запись и делите длинное значение только на строки внутри нее. Получающее приложение их соединяет. Проверьте синтаксис и фактический ответ DNS из командной строки.

Пример синтаксиса файла зоны:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

Многие веб-панели ожидают ту же запись в одной строке:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

Затем проверьте извне, а не только по предварительному просмотру:

dig txt s1._domainkey.example.com +short

Нужен полный TXT-ответ. Две части в кавычках нормальны. Недостающие части, странное экранирование или неполную выдачу следует сопоставить с реально опубликованными данными и используемым инструментом.

В TrekMail можно следовать инструкции управляемый SMTP TrekMail и мастеру DNS. Описанные платные тарифы включают управляемый SMTP и показывают необходимую доменную запись DKIM в панели. Starter указан от $3.50 в месяц, платные тарифы с 14-дневным бесплатным тестом и обязательной банковской картой. Nano описан как бесплатный тариф со своим SMTP. Актуальные функции и условия уточняйте.

Пример: создан ключ 2048 бит, но регистратор незаметно обрезал TXT. Почта продолжает уходить, а проблема проявляется только в неуспешной аутентификации у получателя. Поэтому нужна внешняя проверка.

Как менять ключ DKIM с меньшим риском для почты

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

Осторожный порядок:

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

Переходный период 7 дней является примером, а не универсальным сроком. Он зависит от очередей, повторных доставок и DNS-кэшей. При компрометации немедленный отзыв может оказаться важнее сохранения проверки старой почты.

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

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

Когда менять ключ DKIM?

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

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

Причины досрочной замены:

• Перенос исходящей почты к другому поставщику.
• Отключение поставщика с доступом к подписи.
• Экспорт ключей небезопасным способом.
• Обнаружение старого общего административного аккаунта с неясным назначением.

Плохие причины откладывать:

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

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

Стоит ли использовать Ed25519 для DKIM?

Ed25519 дает гораздо более короткие ключи и уменьшает проблемы длинного TXT у RSA-2048. Но требуется проверять поддержку получателей. В DKIM он стандартизирован RFC 8463; RSA-2048 часто остается более консервативным выбором для широкой совместимости.

Главный плюс: размер. Открытый ключ Ed25519 существенно меньше RSA, поэтому проще публикуется в DNS.

Главный минус: различия поддержки у получателей и инструментов. RSA-2048 широко используется, но тоже не гарантирует универсальную совместимость. Если платформа умеет двойную подпись, можно тестировать Ed25519 вместе с RSA на реальных маршрутах.

Для большинства администраторов разумен такой выбор:

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

Старый и новый подход к управлению DKIM в масштабе

Старый подход: вручную менять TXT, вставлять длинные ключи в разные панели и надеяться, что о ротации не забудут. Новый подход объединяет повторяемое управление DNS и подписью, делая жизненный цикл ключа частью почтовой платформы.

Старый подход:

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

Новый подход:

• Одна процедура для множества доменов.
• Управляемый SMTP может унифицировать подпись.
• Меньше повторяющейся диагностики длинных TXT и расхождений аутентификации.

TrekMail описывает многодоменный хостинг с фиксированной оплатой без платы за каждого пользователя, общее хранилище, IMAP-ящики, встроенную миграцию, catch-all, пересылку, BYO SMTP в Nano и управляемый SMTP в платных тарифах. Уточните текущие возможности. При нескольких правилах пересылки проверяйте изменения аутентификации; поможет статья о пересылке почты домена в Gmail.

Возможный выигрыш для команд и агентств заключается в единых процессах, а не в гарантированно безошибочном DNS. Описанный Starter начинается от $3.50 в месяц; актуальные условия проверяйте.

Итог о ключе DKIM

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

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