DNS-панель не принимает длинный DKIM-ключ или после сохранения почтовый сервис видит только его начало? Лимит 255 байт относится к одной строке внутри TXT-записи, а не ко всему значению: длинное значение можно разместить несколькими строками в одной записи.
Для DKIM эти части соединяются без добавления пробелов. Поэтому нужно проверить три вещи: формат ввода в панели, число получившихся TXT-записей и точное совпадение собранного значения с исходным.
Что именно ограничено 255 байтами
TXT-запись содержит одну или несколько строк; каждая вмещает до 255 байт данных. Это следует из формата character-string и TXT в RFC 1035, разделах 3.3 и 3.3.14.
У ASCII-текста DKIM число символов совпадает с числом байт. Для произвольного текста с кириллицей такое равенство неверно. Ограничение поля в панели также может отличаться от ограничения самого DNS.
Правило сборки зависит от приложения: для DKIM RFC 6376, раздел 3.6.2.2 требует соединять строки одной записи без промежуточных пробелов. Несколько отдельных TXT-записей на одном selector не являются продолжением ключа.
1. Сохраните исходное значение и уточните формат панели
Возьмите полное публичное значение из кабинета почтового отправителя. Сохраните его для сравнения вместе с точным DNS-именем и прежней настройкой; приватный ключ для публикации в DNS не нужен.
Проверьте инструкцию своего DNS-провайдера: одни панели принимают длинное значение целиком и сами делят его, другие требуют отдельных строк в кавычках внутри одного поля. Формат файла зоны нельзя автоматически переносить в веб-форму.
Если запись ещё не находится по имени, сначала пройдите проверку selector и имени DKIM. Деление строки не исправляет ошибочный адрес записи.
2. Разделите содержимое, сохранив одну запись
Для файла зоны условный пример выглядит так:
demo.example.com. IN TXT "abc" "DEF"Здесь одна TXT-запись с двумя строками. Приложение, использующее сборку как в DKIM, получит abcDEF. Это короткая иллюстрация формата, не готовый DKIM-ключ.
А такой вариант создаёт две самостоятельные записи:
demo.example.com. IN TXT "abc"
demo.example.com. IN TXT "DEF"Не разбивайте ключ на несколько строк таблицы DNS с одинаковым именем. Не сокращайте ключ и не меняйте его размер только ради ограничения интерфейса.
При ручном делении считайте все байты каждой части, включая префикс вроде v=DKIM1; k=rsa; p=. Сохраняйте порядок частей, регистр и все символы исходного значения. Не добавляйте пробел внутрь кавычек на границе частей; уже имеющиеся разделители между тегами сохраняйте.
3. Проверьте ответ авторитетных DNS-серверов
После сохранения смотрите не только на форму панели, но и на фактический DNS-ответ. На компьютере с установленным dig запросите запись у авторитетного NS:
dig @ns1.example.net selector._domainkey.example.com. TXT +norecurse +noall +answerЗамените имя сервера, selector и домен своими значениями. Повторите запрос для каждого действующего NS зоны; условный сервер из примера использовать не нужно.
В секции ответа одна строка записи может содержать несколько фрагментов в кавычках — это ожидаемо. Несколько отдельных записей с частями одного DKIM-ключа означают, что способ ввода был выбран неверно. Учитывайте визуальный перенос длинной строки терминалом: перенос на экране сам по себе не создаёт новую DNS-запись.
Для сравнения соедините содержимое строк одной записи в исходном порядке. Сопоставьте результат с эталоном целиком, а не только начало p= и последние символы. Удалять все пробелы и кавычки во всём выводе командой вслепую нельзя: так легко смешать разные записи или потерять реальные данные.
4. Отделите ошибку сохранения от кэша и проверки подписи
| Наблюдение | Следующая проверка | | --- | --- | | На всех NS значение обрезано | Формат поля и ограничения DNS-панели | | На одном имени несколько частей отдельными записями | Пересоздание как одной TXT-записи по инструкции провайдера | | NS возвращают разные значения | Согласованность зоны у DNS-провайдера | | NS уже отвечают верно, резолвер — старым значением | Кэш прежнего ответа и его TTL | | Значение совпало, но DKIM не проходит | Соответствие ключевой пары и изменения письма после подписания |
Повторное сохранение того же значения не очищает чужой DNS-кэш. Если ответы уже совпали, отправьте свежее тестовое письмо на свой ящик тем же почтовым маршрутом и проверьте результат DKIM у получателя. Успешная публикация ключа ещё не доказывает успешную подпись или доставку во «Входящие».
Когда диагностику стоит передать специалисту
Если известен формат панели и собранное значение совпадает с исходным, исправление обычно можно проверить самостоятельно. Web-Puls помогает контролировать доступность сайта, но обычная HTTP-проверка не подтверждает корректность DKIM.
Если панель и DNS продолжают отдавать разные значения, отправьте заявку на диагностику: укажите домен, имя записи, DNS-провайдера и время проверки с часовым поясом. Специалист оценит задачу и предложит формат работ; пароли, приватный ключ и полные исходники писем передавать не нужно.