Как разделить запись DKIM

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

Вместо сообщения об успешном выполнении на экране появляется сообщение об ошибке. AWS Route 53 выдает непонятное предупреждение «CharacterStringTooLong». Google Cloud DNS прямо сообщает, что у вас «неверные данные записи».

Если при добавлении записи DKIM вы столкнулись с ограничением в 255 символов, не беспокойтесь: ваш ключ не повреждён, и вам не нужно снижать уровень безопасности. Вам просто нужно правильно разбить запись DKIM TXT на несколько строк. Разбиение записи DKIM — это стандартная и безопасная административная процедура, и после публикации DNS-резолверы автоматически и незаметно соединят фрагменты обратно.

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

Почему записи DKIM необходимо разделить

Необходимость разбивать записи DKIM обусловлена базовыми правилами работы Интернета. Согласно разделу 3.3.14 стандарта RFC 1035, длина одной символьной строки в записи DNS типа TXT не может превышать 255 символов (или октетов). Это ограничение связано с тем, что длина строки в стандартном пакете DNS хранится в одном байте, а значит, не может превышать 255 символов.

Это структурное ограничение приобретает особую актуальность в зависимости от длины ваших криптографических ключей:

• 1024-битные ключи DKIM: эти строки открытых ключей имеют небольшую длину и, как правило, без каких-либо изменений укладываются в ограничение в 255 символов.
• 2048-битные ключи DKIM: эти ключи обеспечивают значительно более высокий уровень безопасности, однако при их использовании генерируется строка открытого ключа в кодировке Base64, длина которой почти всегда составляет от 350 до 500 и более символов.

Поскольку 2048-битный ключ DKIM по своей природе превышает порог в 255 символов, он не может быть представлен в виде одной непрерывной строки.

Подход к работе с этой границей полностью зависит от вашего провайдера услуг DNS-хостинга. По состоянию на 2026 год основные платформы по-прежнему делятся на два лагеря:

• Строгие провайдеры: такие сервисы, как AWS Route 53, Google Cloud DNS и Azure DNS, строго соблюдают требования RFC 1035 на уровне пользовательского интерфейса. Если вы вставите строку длиной 300 символов, они мгновенно отклонят её.
• Автоматизированные провайдеры: такие платформы, как Cloudflare, GoDaddy и cPanel, часто выполняют эту форматировку незаметно для пользователя, разбивая запись внутренне, так что вам не нужно делать это вручную.

Важное примечание: Разбиение записи не приводит к изменению или нарушению вашей подписи DKIM. Когда сервер входящей почты запрашивает открытый ключ DKIM вашего домена, его DNS-резолвер автоматически объединяет (сводит) разбитые строки в одну непрерывную строку перед обработкой криптографического рукопожатия.

Как разделить запись DKIM (пошаговая инструкция)

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

Ниже приведен пример необработанной, неразбитой записи DKIM длиной 2048 бит — одной непрерывной строки, которую строгие провайдеры отклонят, — а также та же самая запись с ключом, разбитым надлежащим образом:

До — одна непрерывная строка (410 символов, отклонено):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDDj8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB

В результате — одна запись TXT и две строки в кавычках, разбитые по границе в 255 символов:

«v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDD”
“j8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB»

Разделение 2048-битного ключа DKIM

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…wIDAQAB

Одна непрерывная строка — 410 символов, которая отклоняется AWS Route 53 / Google Cloud DNS

↓ разделить по границе в 255 символов

Один запись TXT — две строки в кавычках

«v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…»

фрагмент 1 · 255 символов

«…zrIZtoLuCr64CxqlIOdNKhiwIDAQAB»

блок 2 · остаток (≈155)

ровно один пробел между фрагментами, при этом внутри каждого фрагмента пробелов не должно быть.

Шаг 1: Определите полную запись DKIM

Вы можете войти в панель управления своего почтового сервиса (например, Google Workspace, Microsoft 365, SendGrid или Mailchimp), чтобы найти сгенерированный открытый ключ. Запись всегда начинается с определённых тегов и, как правило, имеет следующий формат:

v=DKIM1; k=rsa; p=[Очень длинная строка в кодировке Base64]

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

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

Шаг 2: Разделить значение ключа на фрагменты по 255 символов

У вас есть два варианта разбиения записи: вручную с помощью математических вычислений или с помощью автоматизированной утилиты.

Ручной метод

Откройте текстовый редактор и отсчитайте ровно 255 символов от начала записи (включая префикс v=DKIM1; k=rsa; p=). Разделите строку именно на этой отметке в 255 символов.

Каждый отдельный фрагмент необходимо заключить в собственную пару двойных кавычек («»). Очень важно убедиться, что внутри фрагментов нет пробелов, но между закрывающей кавычкой первого фрагмента и открывающей кавычкой второго фрагмента должен быть ровно один пробел.

Автоматический метод (рекомендуется)

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

• Перейдите на страницу инструмента.

• Вставьте полную, неразбитую запись DKIM TXT в поле ввода.

• Выберите формат с кавычками (требуется такими строгими провайдерами, как AWS и Google).

• Нажмите «Разделить запись », чтобы мгновенно сгенерировать правильно отформатированные строки.

• Вот как должен выглядеть результат:

Шаг 3: Добавьте запись Split в ваш DNS

Распространенной ошибкой среди администраторов является попытка создать в панели управления DNS две отдельные записи TXT — по одной для каждого фрагмента. Не делайте этого; это полностью нарушит процесс аутентификации.

Вам необходимо добавить одну запись TXT. В интерфейсе управления DNS вставьте обе строки в кавычках в одно поле «Значение» / «Данные ». У большинства стандартных провайдеров их следует разделить одним пробелом:

«v=DKIM1; k=rsa; p=CHUNK1» «CHUNK2»

(Примечание: если вы используете AWS Route 53, не используйте формат с одной строкой и пробелом, а следуйте инструкциям по разбиению строк, указанным для конкретной платформы в разделе провайдера ниже.)

Шаг 4: Проверьте запись DKIM

После сохранения изменений необходимо подождать, пока обновления DNS распространятся по сети. Хотя обычно это занимает от 5 до 30 минут, в некоторых случаях процесс может занять до 48 часов в зависимости от настроек TTL (Time to Live) вашей зоны.

Чтобы убедиться, что всё работает как надо, воспользуйтесь бесплатным инструментом PowerDMARC DKIM Lookup и проверьте, опубликована ли ваша запись и правильно ли она разрешается.

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

В случае успешного прохождения проверки будет возвращен полный унифицированный криптографический ключ со статусом «green». Если проверка завершилась с ошибкой, обратите внимание на такие проблемы, как усечение (отсутствующие данные), отсутствие второго фрагмента или синтаксические ошибки, связанные с незакрытыми кавычками.

Разделение записей DKIM по провайдерам DNS

Различные панели управления DNS по-разному обрабатывают ввод многостроковых записей TXT. Ниже приведены инструкции по настройке для четырёх наиболее распространённых платформ:

AWS Route 53

Amazon Route 53 строго соблюдает ограничения и выдает ошибку CharacterStringTooLong, если в какой-либо отдельной строке отсутствуют кавычки или ее длина превышает 255 символов. Поскольку DNS-резолверы объединяют последовательные строки без каких-либо пробелов между ними, ввод пробела между кавычками в одной строке может случайно привести к повреждению криптографического ключа.

• Использование консоли: В поле «Значение» консоли Route 53 введите каждый фрагмент в виде отдельной строки в кавычках в отдельной строке. Не оставляйте пробел в конце строки. Route 53 изначально рассматривает последовательные строки в одном текстовом поле как отдельные строки в рамках одной записи TXT и объединяет их при поиске.
• Метод API/JSON: при развертывании инфраструктуры с помощью кода или API AWS структурируйте входные данные записи в виде массива JSON, в котором каждый фрагмент представляет собой отдельный элемент массива: [“v=DKIM1…”, “…CHUNK2”].

DNS Google Cloud

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

Cloudflare

Cloudflare оснащен интеллектуальным бэкэндом, который автоматически анализирует длинные строки TXT при сохранении, разбивая их на сегменты, соответствующие стандарту RFC, без участия пользователя. Однако использование автоматического анализа может в некоторых случаях приводить к возникновению нестандартных ситуаций при работе со сложными ключами. Наилучшей практикой развертывания по-прежнему является вставка заранее разбитых строк в кавычках непосредственно в панель управления Cloudflare вручную.

cPanel / WHM

В старых версиях редактора зон cPanel действует жесткое ограничение на длину ввода в стандартных полях ввода текста, составляющее 255 символов. Если основной интерфейс не принимает запись необходимой длины, перейдите в расширенный редактор зон DNS. Этот расширенный режим обеспечивает структурную гибкость, необходимую для беспроблемного ввода многофрагментарных полей данных TXT, разбитых на части.

Распространенные ошибки при разделении записей DKIM

Если вы развернули запись split, но системы проверки подлинности по-прежнему блокируют ваш домен, обратите внимание на три наиболее распространённые ошибки в настройках:

1. Ошибка проверки подписи DKIM после разделения

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

2. DNS отображает только часть ключа

• Причина: второй фрагмент был сохранен в виде полностью отдельной, вторичной записи TXT на хостинге вашего домена, а не объединен с первой записью.
• Решение: полностью удалите вторую запись. Отредактируйте основную запись DKIM TXT таким образом, чтобы обе строки в кавычках находились вместе в одном поле значения.

3. После разбиения длина записи превышает 255 символов

• Причина: точка разбиения была рассчитана неверно, в результате чего один из двух фрагментов слегка превысил ограничение в 255 символов (часто из-за неверного подсчета префикса v=DKIM1;).
• Решение: Разделите запись ровно на 255-м символе или доверьте подсчет автоматическому инструменту для разделения DNS-записей.

Как разделение DKIM влияет на DMARC

Часто ИТ-руководителей беспокоит вопрос: влияет ли изменение открытого ключа на то, как система DMARC обрабатывает входящие сообщения.

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

Однако если ваша запись с разбиением имеет неверную структуру или неправильный формат, это сразу же приведет к следующим последствиям:

• Сервер электронной почты-получателя не сможет восстановить ваш открытый ключ.
• Аутентификация DKIM завершится сбоем.
• DMARC будет вынужден полностью перейти на использование вашего SPF (Sender Policy Framework).
• Если не будет соблюдено и соответствие SPF (или если ваша политика DMARC требует соответствия обоих протоколов), ваши легитимные корпоративные письма будут отправляться в папку «Спам» или могут быть вовсе отклонены.

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

Подведение итогов

Разделение записи DKIM — это необходимый административный шаг при управлении защищёнными 2048-битными ключами у строгого типа провайдеров DNS, таких как AWS Route 53 или Google Cloud DNS. Это безопасная и стандартная процедура, которую легко выполнить, если знать основные правила форматирования.

При обновлении записей всегда помните об основных правилах:

• Разделите строку по границе в 255 символов.
• Заключите каждый фрагмент в двойные кавычки.
• Все данные следует поместить в одну запись TXT (разделяя их пробелом для стандартных провайдеров или размещая в отдельных строках для строгих интерфейсов, таких как AWS Route 53).

Не гадайте о количестве символов и не рискуйте нарушить работу электронной почты. Избавьтесь от ручных вычислений и мгновенно отформатируйте ключ с помощью бесплатного инструмента PowerDMARC DNS Record Splitter — регистрация не требуется.

Часто задаваемые вопросы

Что такое разделитель записей DNS?

Программа для разбиения записей DNS — это утилита, предназначенная для разбиения длинных записей DNS типа TXT на отдельные сегменты длиной 255 символов. Этот этап форматирования необходим для того, чтобы ваши записи могли быть правильно сохранены на хостингах с жесткими требованиями к DNS, которые не выполняют автоматическое внутреннее разбиение строк. Абсолютное значение вашей записи остается полностью неизменным; она просто форматируется в виде структурированных, более коротких блоков, которые принимающие системы сразу же соединяют обратно при запросе.

Какие провайдеры DNS требуют ручного разделения записей?

Некоторые крупные поставщики корпоративных решений строго соблюдают ограничение в 255 символов на уровне своего интерфейса, что требует предварительного форматирования длинных текстовых значений перед сохранением:

• AWS Route 53: выдаёт сообщение об ошибке CharacterStringTooLong, если длинные строки не разбиты на отдельные блоки, заключённые в кавычки.
• Google Cloud DNS: полностью отклоняет длинные непрерывные строки, что приводит к появлению предупреждения «неверные данные записи».
• Azure DNS: при добавлении строк напрямую через панель управления Azure Portal или Azure CLI требуется вручную разделить и разбивать текстовые поля.
• DigitalOcean: не разбивает длинные строки записей TXT на части в своей стандартной веб-панели управления.

Зачем мне нужно разделить запись DKIM?

Основной причиной для разделения записи TXT является использование надежного открытого ключа DKIM длиной 2048 бит. В то время как 1024-битные ключи достаточно коротки, чтобы поместиться в одной строке, 2048-битный ключ по своей сути содержит от 350 до 500+ символов криптографических данных в кодировке base64. Поскольку раздел 3.3.14 RFC 1035 ограничивает длину одной непрерывной строки ровно 255 октетами, эти длинные ключи необходимо разбивать на отдельные сегменты, чтобы они помещались в стандартную архитектуру хранения DNS.

Не повлияет ли разбиение моего записи на ее данные или не нарушит ли это проверку адреса электронной почты?

Нет. Разбиение длинной записи TXT не приводит к повреждению или изменению её криптографического значения. Когда входящий почтовый сервер запрашивает настройки аутентификации вашего домена, его DNS-резолвер автоматически считывает разбитые сегменты и объединяет (конкатенирует) их обратно в одно непрерывное значение без разделителей. Разбиение на сегменты является исключительно технической деталью внутреннего хранения; оцениваемое содержимое остается неизменным.

В чём заключается разница между форматами вывода «Quoted» и «Plain»?

• Формат с кавычками (рекомендуется): каждый отдельный сегмент длиной 255 символов заключается в отдельную пару двойных кавычек («chunk1» «chunk2»), которые либо разделяются пробелом в одной строке, либо вводятся в последовательные поля/строки данных. Именно такой формат требуется для таких строгих интерфейсов, как AWS Route 53 и Google Cloud DNS, чтобы предотвратить повреждение ключей.
• Простой формат: разбивает длинную строку на отдельные блоки без добавления охватывающих двойных кавычек или лишних пробелов и знаков препинания. Такая компоновка предназначена для современных панелей управления, поддерживающих обработку необработанных многострочных потоков строк, или для системных сред самохостинга BIND (Berkeley Internet Name Domain).

Безопасно ли использовать этот инструмент для работы с конфиденциальными ключами или личными данными?

Да. Инструмент PowerDMARC DNS Record Splitter работает исключительно в вашем локальном веб-браузере с помощью клиентских скриптов. Введенные вами текстовые строки никогда не покидают ваше устройство, никакие данные не отправляются через Интернет на внешние серверы обработки, и не требуется ведение журналов отслеживания или обязательная регистрация. Кроме того, важно отметить, что инструмент предназначен исключительно для общедоступных конфигураций, таких как общедоступные ключи DKIM, включения SPF, политики DMARC или записи проверки домена, которые уже доступны в открытом доступе в Интернете. Частные ключи подписи ни в коем случае не следует вставлять в какие-либо онлайн-инструменты.

• О сайте
• Последние сообщения

Юнес Тарада

Эксперт по безопасности доменов и электронной почты в PowerDMARC

Юнес - руководитель группы операций в PowerDMARC, обладающий экспертными знаниями в области аутентификации и безопасности электронной почты. Юнес имеет сертификат Microsoft Azure Administrator Associate, а также сертификаты CompTIA A+ и многие другие.

Последние сообщения Юнеса Тарады (см. все)

• Как разделить запись DKIM - 5 июня 2026 г.
• compauth=fail: обзор композитной аутентификации Microsoft - 1 июня 2026 г.
• Достаточно ли Windows Defender для обеспечения безопасности малого бизнеса? - 14 мая 2026 г.