Роль DKIM в автентифікації електронної пошти
DomainKeys Identified Mail (DKIM) є одним із базових методів автентифікації електронної пошти, який дає змогу організаціям брати на себе відповідальність за відправлені повідомлення. Цей метод використовує криптографічний цифровий підпис для підтвердження того, що лист дійсно надіслано з заявленого домену, а його вміст не був змінений під час транспортування.
Для роботи DKIM у DNS-зоні домену публікується спеціальний текстовий запис (TXT), який містить відкритий криптографічний ключ. Коли поштовий сервер отримувача приймає лист, він витягує підпис із заголовків повідомлення та запитує відкритий ключ із DNS-запису відправника для перевірки цього підпису. Якщо підпис валідний, це підтверджує цілісність листа та його джерело.
Структура та компоненти запису DKIM TXT
Запис DKIM TXT складається зі списку тегів, розділених крапкою з комою. Кожен тег є парою «назва=значення». Основними компонентами, які аналізує інструмент, є:
- Версія (
v): Визначає версію протоколу. Якщо цей тег присутній, він обов'язково має бути першим у записі. - Тип ключа (
k): Визначає алгоритм шифрування, що використовується для створення пари ключів. - Відкритий ключ (
p): Закодований у Base64 публічний ключ, який використовується серверами отримувачів для перевірки підписів. - Сервіси (
s): Визначає типи сервісів, які використовують цей запис (наприклад, електронна пошта). - Хеш-алгоритми (
h): Обмежує список дозволених алгоритмів хешування.
Обмеження розміру DNS TXT та робота з фрагментами
Згідно зі стандартами DNS, один текстовий рядок у записі TXT обмежений розміром у 255 байтів. Якщо довжина криптографічного ключа та супутніх тегів перевищує цей ліміт, запис доводиться розбивати на кілька цитованих фрагментів.
Під час публікації у файлі зони ці фрагменти беруться в лапки та можуть об'єднуватися круглими дужками. DNS-сервер автоматично збирає ці частини в один суцільний рядок перед тим, як віддати його клієнту, що запитує інформацію. Інструмент перевірки підтримує введення таких сегментованих записів обсягом до 20 000 символів, автоматично об'єднуючи цитовані фрагменти для подальшого аналізу.
Локальний аналіз без запитів до DNS
Цей інструмент виконує виключно локальний аналіз тексту запису безпосередньо у вашому браузері. Процес перевірки має такі особливості:
- Конфіденційність: Ваш запис DKIM залишається у вашому браузері. BroBroGo не завантажує та не зберігає його.
- Відсутність мережевих запитів: Інструмент не робить запитів до DNS-серверів для перевірки реального існування запису на вашому домені.
- Без перевірки підписів: Робота інструменту обмежена синтаксичним аналізом структури та ключів; він не перевіряє підписи конкретних листів.
Такий підхід дозволяє адміністраторам безпечно перевірити правильність формування запису перед його публікацією в DNS, уникаючи витоку конфіденційних даних.
Правила валідації та криптографічні вимоги
Для забезпечення надійного захисту поштового листування до записів DKIM висуваються суворі криптографічні та синтаксичні вимоги:
Типи та розміри ключів
Інструмент розпізнає публічні ключі типів RSA та Ed25519. Для ключів RSA діють такі правила безпеки:
- Ключі розміром менше ніж 1024 біти вважаються недійсними та небезпечними.
- Ключі розміром від 1024 до 2047 бітів є робочими, але визначаються як слабші за рекомендовані.
- Рекомендованим стандартом є використання ключів розміром 2048 біт або більше.
Для ключів Ed25519 довжина декодованого значення має становити рівно 32 байти.
Вимоги до тегів та алгоритмів
- Тег
v: Має містити виключно значенняDKIM1. Будь-які інші варіанти є помилковими. - Тег
k: Дозволені значення — лишеrsaабоed25519. - Тег
s: Значення сервісу має міститиemailабо загальний символ*. - Тег
h: Повинен обов'язково дозволяти використання алгоритмуsha256. Використання застарілого алгоритмуsha1заборонено, оскільки він є вразливим. - Відкликання ключа: Якщо тег
pє порожнім (наприклад,p=), це сигналізує про публікацію відкликаного ключа, що робить його недійсним для підписання нових листів.
Помилки та попередження при перевірці
Під час аналізу введеного значення інструмент може виявити низку синтаксичних та структурних проблем. Нижче наведено таблицю можливих помилок та попереджень, які генерує аналізатор:
| Категорія проблеми | Текст помилки або попередження в інтерфейсі | Опис проблеми |
|---|---|---|
| Проблеми з презентацією | Цитована презентація TXT пошкоджена. Залиште всі цитовані блоки і видаліть текст поза цитатами. | Некоректне використання лапок у введеному тексті. |
Блок ‹detail› TXT перевищує обмеження в 255 байтів для одного рядка символів DNS. |
Один із фрагментів запису перевищує ліміт довжини для DNS-рядка. | |
| Синтаксис тегів | Не вистачає обов'язкового тегу відкритого ключа p. | У записі відсутній публічний криптографічний ключ. |
Тег ‹tag› зустрічається більше одного разу. |
Дублювання параметрів у межах одного запису. | |
У полі “‹tag›” відсутній знак рівності. |
Порушено формат оголошення тегу. | |
Назва тегу “‹tag›” пошкоджена. |
Використано неприпустимі символи в назві тегу. | |
| Помилки версії та типу | Тег v=DKIM1 повинен бути першим, коли він присутній. | Порушено порядок розташування тегу версії. |
Тег v має бути точно DKIM1, а не “‹detail›”. |
Вказано непідтримувану версію протоколу. | |
Тип ключа “‹detail›” не підтримується. Використовуйте rsa або ed25519. |
Вказано невідомий алгоритм шифрування. | |
| Проблеми з ключем | Значення p не є дійсним відкритим ключем для обраного типу ключа. | Помилка кодування Base64 або невідповідність структури ключа. |
| Значення p порожнє, що публікує відкликаний ключ DKIM. | Індикатор того, що цей ключ більше не є активним. | |
Ключ RSA має ‹detail› біт. DKIM вимагає принаймні 1024 біт. |
Ключ занадто короткий і є недійсним. | |
Ключ RSA має ‹detail› біт. Рекомендується 2048 біт або більше. |
Ключ працює, але має недостатній рівень стійкості. | |
Ключ Ed25519 декодується у ‹detail› байт замість 32. |
Невідповідність довжини для алгоритму Ed25519. | |
| Параметри сервісів та хешів | Значення s “‹detail›” містить непідтримувану службу. Використовуйте email або *. |
Вказано некоректну область застосування ключа. |
| Тег h має дозволяти sha256 для поточних підписів DKIM. | Обмеження алгоритмів виключає обов'язковий стандарт безпеки. | |
| sha1 застарілий для підписів DKIM і не повинен використовуватися. | Використання небезпечного застарілого алгоритму хешування. | |
| Інші нотатки | Невизнана мітка ‹tag› збережена, але не інтерпретується. |
Виявлено нестандартний тег, який ігнорується аналізатором. |
FAQ
Чому довгі записи DKIM розбиваються на цитовані рядки?
Запис DNS TXT може містити кілька рядкових символів, кожен рядок обмежений 255 байтами. DNS об'єднує рядки за порядком, тому всі фрагменти мають залишатися в межах одного запису TXT.
Які типи ключів DKIM розпізнає цей перевірник?
Він розпізнає публічні ключі RSA і Ed25519, перевіряє їхню форму Base64 і повідомляє, що ключі RSA з менше ніж 1024 бітами є недійсними, а ключі з менше ніж 2048 бітами — слабшими за рекомендовані.
Чи свідчить чистий результат про те, що DKIM працює?
Ні. Ця сторінка перевіряє лише текст запису, який ви вставляєте. Вона не запитує DNS, не перевіряє підпис повідомлення, не підтверджує ім'я селектора і не доводить, що отримувачі пошти можуть отримати запис.