Невідповідність селектора DKIM: виправлення за 2 хвилини

Що насправді означає невідповідність селектора DKIM

DKIM використовує криптографію з відкритим ключем, щоб отримувач міг підтвердити, що повідомлення підписане тим, хто контролює домен.
Отримувач витягує заголовок DKIM-Signature, знаходить d= (домен) і s= (селектор), а потім шукає DNS TXT запис за адресою:

<selector>._domainkey.<domain>

Коли кажуть «невідповідність селектора DKIM», зазвичай мають на увазі одне з нижченаведеного:

• Повідомлення підписане селектором s=foo, але в DNS є тільки bar._domainkey.
• Підписувач налаштований використовувати селектор foo, але опублікований у foo._domainkey відкритий ключ не відповідає приватному ключу, що використовується для підпису.
• Домен у підписі d= не збігається з доменом, де ви опублікували запис (часто трапляється з піддоменами і «bounce»-доменами).
• DNS правильний, підписувач правильний, але видимість DNS неправильна (split-horizon DNS, застарілі резолвери, кешування або некоректна делегація).

Невідповідності DKIM — це не «пошта не працює» у звичному розумінні. Вони гірші: пошта ще йде, але знижується довіра. Тому ваш інцидент не виглядає як чистий аутедж. Він виглядає як «канал працює», а комерційні листи потрапляють до спаму.
Класична проблема надійності: відмова мовчить, поки не почне дорого коштувати.

Одна операційна деталь: приймачі часто розглядають DKIM як один із сигналів. Невідповідність може не відразу відкинути лист, але може зіштовхнути на межі — особливо якщо репутація IP посередня або ви розсилаєте великі хвилі.

Жарт №1: селектори DKIM — як багажні бирки: загубив бирку й ваш email ще подорожує, просто не туди, куди ви хотіли.

Швидкий план діагностики (перша/друга/третья перевірки)

Коли приходить повідомлення «DKIM не працює», ваше завдання — швидко знайти вузьке місце: це проблема DNS, підписування чи вирівнювання домену?
Не починайте з ротації ключів. Не починайте панічно редагувати DNS. Почніть з читання того, що пошта сама про себе каже.

Перше: підтвердіть, який селектор і домен використовуються зараз

• Візьміть свіжий лист із постраждалого потоку (не зразок з минулого тижня).
• Витягніть d= і s= з DKIM-Signature.
• Подивіться Authentication-Results, щоб побачити, як це оцінив отримувач.

Якщо селектор у заголовку не той, який ви думаєте, що налаштували — задача вже вирішена: ви налагоджуєте не того відправника або не той шлях підписування.
У великих організаціях існує кілька підписувачів (хмарний шлюз, MTA, тикетингова система, CRM). Лист, який ви тримаєте, підказує, хто саме підписує.

Друге: опитайте DNS для того точного селектора

• Запитайте TXT для <selector>._domainkey.<domain>.
• Опитайте принаймні два різні резолвери (ваш корпоративний і публічний).
• Перевірте, чи NXDOMAIN, порожня відповідь чи уривчастий/зламаний запис.

Якщо DNS не повертає ключ DKIM для селектора в заголовку — виправте DNS або виправте селектор у підписувачі. Зазвичай одна стрічка.

Третє: переконайтеся, що відкритий ключ відповідає приватному ключу підписувача

• На хості підписування знайдіть файл приватного ключа у вашій конфігурації OpenDKIM/OpenSMTPD/Haraka/тощо.
• Отримайте відкритий ключ із приватного та порівняйте його з тим, що в DNS (або перевипустіть правильний).

Якщо в DNS є ключ, але перевірка підпису провалюється — найімовірніше у вас невідповідність ключів (опубліковано неправильний ключ, розгорнутий не той файл, селектор вказує на старий ключ або декілька підписувачів не синхронізовані).

Парафразована ідея (атрибутовано): «Ви не можете покращити те, що не можете виміряти», часто пов’язана з Пітером Друкером. В світі email-автентифікації «виміряти» означає «читати заголовок і опитувати DNS».

Виправлення за 2 хвилини (нудна правда)

Більшість інцидентів із невідповідністю селектора закінчуються однаково: хтось змінив селектор в одному місці і забув, що інше місце існує.
Ви виправляєте це, зробивши селектор послідовним у:

1. Тому, що видає підписувач (те, що в s= у DKIM-Signature)
2. Що публікує DNS (TXT-запис для цього селектора)
3. Який файл ключа використовує підписувач (приватний ключ, прив’язаний до цього селектора)

Найшвидше «2-хвилинне виправлення» залежить від того, яка сторона неправильна:

• DNS не має селектора, який у продукційній пошті: опублікуйте TXT-запис для цього селектора (скопіюйте відкритий ключ, який очікує підписувач).
• Підписувач використовує неправильний селектор: оновіть конфігурацію підписувача, щоб використовувався селектор, який вже в DNS, і перезавантажте сервіс.
• Невідповідність ключів: опублікуйте правильний відкритий ключ для використовуваного селектора або розгорніть правильний приватний ключ для селектора, що вже опублікований.

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

Не забувайте про кешування. Якщо ви публікуєте новий TXT-запис, отримувачі не обов’язково побачать його негайно. Важливий ваш авторитетний TTL, а також поведінка кешування отримувача.
Але: якщо запису не існувало (NXDOMAIN) і ви його додаєте, багато систем швидко підхоплять зміни; негативне кешування може все ще дошкуляти декілька хвилин.

Факти та історичний контекст (чому це трапляється)

1. DKIM стандартизований у 2007 році: він виник з DomainKeys (Yahoo) та Identified Internet Mail (Cisco), що об’єдналися в один стандарт. Саме через це ви бачите і «domainkey» у назвах, і термінологію DKIM.
2. Селектори призначені для ротації ключів: селектор дозволяє публікувати декілька ключів одночасно і перемикати підписувачів без негайного видалення старих ключів.
3. Обмеження довжини TXT сформували DKIM: рядки TXT мають практичні обмеження за розміром, і довгі ключі часто розбивають на кілька рядків у лапках. Деякі інструменти погано з цим працюють і створюють «невидимі» поломки.
4. Отримувачі часто використовують relaxed-канонізацію за замовчуванням: DKIM підтримує «simple» і «relaxed» канонізації, щоб терпіти зміни пробілів у дорозі. Саме тому багато листів і далі проходять перевірку навіть після деяких змін форматування заголовків.
5. DMARC (2012) зробив проблеми DKIM помітними для керівництва: DKIM існував раніше, але DMARC-звіти й застосування політик зробили автентифікацію темою на рівні правління.
6. 2048-бітні ключі стали очікуваним стандартом: 1024-бітні ключі все частіше вважають слабкими; деякі отримувачі їх штрафують. Ротації часто супроводжуються зміною розміру ключа, що підвищує ймовірність помилок із селекторами.
7. Деякі провайдери автоматично ротають селектори: хмарні платформи можуть генерувати селектори на кшталт selector1/selector2 або вендорно-специфічні рядки. Люди потім «стандартизують» їх і ламають систему.
8. Split-horizon DNS — постійний антагоніст: внутрішні резолвери, що повертають інші відповіді, ніж зовнішні, можуть робити DKIM коректним всередині компанії і некоректним в інтернеті.

Три корпоративні міні-історії (як дорослі ламають пошту)

Міні-історія №1: Інцидент через хибне припущення

Середній SaaS-проєкт мігрував з on-prem Postfix + OpenDKIM на хмарний реле для вихідних сповіщень.
План міграції мав акуратну таблицю: «Оновити SPF, налаштувати DKIM, перевірити DMARC». Усі кивнули. У календарі стояло «30 хвилин».

Інженер, що робив роботу з DNS, припустив, що назва селектора довільна, тому обрав щось пам’ятне: prod2025.
Вони опублікували prod2025._domainkey.example.com з ключем, який показував інтерфейс реле. Чисто.

Але реле вже підписувало повідомлення з s=selector1. На сторінці налаштувань DKIM UI було два селектори і перемикач для ротації.
Інженер побачив «prod2025» в документації і подумав, що треба назвати його самостійно, тож зробив. Вони ніколи не змінили фактичний селектор реле.

Результат: аутентифікація впала для всієї вихідної пошти, політика DMARC була «quarantine», і найважливіші листи для скидання пароля почали потрапляти у спам. Кількість звернень у службу підтримки зросла. Ніхто не міг відтворити проблему локально, бо їхні тестові поштові скриньки мали правила білих списків.

Виправлення було майже образливим: опублікувати TXT-запис для selector1 і припинити вигадувати назви селекторів, якщо ви одночасно не змінюєте підписувача.
Ретроспектива дала одну хорошу пораду: коли автентифікація пошти падає, спочатку читайте заголовок. Не довіряйте тому, що ви мали на увазі налаштувати.

Міні-історія №2: «Оптимізація», що відбилася бумерангом

Глобальна компанія мала охайний парк шлюзів у двох регіонах. Хтось вирішив «оптимізувати» оновлення DNS, зменшивши TTL для всіх DKIM-записів до 60 секунд.
Ідея: швидша ротація ключів, швидший відкат, менше ризику. Звучить адекватно на зустрічі.

Насправді: їхній авторитетний DNS-провайдер почав лімітувати трафік деяких резолверів і час від часу повертати SERVFAIL під час піку.
Це не був повний аутедж; це було переривчасто і залежало від навантаження. Шлюзи продовжували підписувати тим самим селектором, але отримувачі іноді не могли отримати ключ через тимчасові збої DNS.

DKIM почав іноді падати у великих споживчих провайдерів. Команди з доставлянності бачили «деякі кампанії в порядку, деякі ні», що породжує плутанину і конфлікти.
SRE на чергуванні не бачив помилок на шлюзах. Сервіс підписування був здоровим. Проблема була вниз по ланцюгу: отримання ключа.

Вони повернули TTL до розумного значення (години, а не секунди), виправили налаштування провайдера DNS і припинили трактувати DKIM як систему прапорців функцій.
«Оптимізація» збільшила обсяг запитів, загострила слабке місце і дала режим відмови, який важко виявити зсередини мережі.

Міні-історія №3: Сумна, але правильна практика, що врятувала день

Фінансова компанія мала нудну практику: кожна система вихідної пошти щотижня відправляла канарковий лист на спеціальну зовнішню скриньку у двох провайдерів.
Скриньку стежив скрипт, який парсив заголовки, записував результати DKIM/SPF/DMARC і сигналив про зміни.

Постачальник провів ротацію селектора DKIM у п’ятницю вночі в рамках «рутинного техобслуговування».
Вже в суботу вранці канарка сповістила: DKIM fail (селектор не знайдено). Ніхто не був на великому інцидентному бріджі, бо продакшн-системи були в порядку — лише довіра до пошти була порушена.

На чергуванні діяли за планом: читали заголовок, побачили s=vendor2026, опитали DNS, NXDOMAIN.
Команда DNS опублікувала новий запис за кілька хвилин, бо вже мала процедуру зміни і попередньо погоджений список піддоменів для DKIM.

Ніякого впливу на клієнтів, вартого поста — саме це й важливо.
Вони не «рухалися швидко». Вони рухалися передбачувано.

Практичні завдання: команди, очікуваний вивід і рішення

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

Завдання 1: Витягніть селектор і домен з заголовка DKIM-Signature

cr0x@server:~$ grep -i '^DKIM-Signature:' -m1 -n /tmp/message.eml
42:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

Що це означає: Живий лист стверджує d=example.com і s=selector1.

Рішення: Припиніть сперечатися. Ваш DNS-запит має бути спрямований на selector1._domainkey.example.com.

Завдання 2: Перевірте оцінку на стороні отримувача в Authentication-Results

cr0x@server:~$ grep -i '^Authentication-Results:' -n /tmp/message.eml | head
12:Authentication-Results: mx.google.com;
13:       dkim=fail header.i=@example.com header.s=selector1 header.b=AbCdEf;
14:       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
15:       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Що це означає: DKIM для selector1 не пройшов; SPF пройшов, але DMARC не пройшов (ймовірно проблема вирівнювання або політика вимагає DKIM).

Рішення: Спочатку зосередьтеся на доступності й коректності DKIM-запису; після відновлення DKIM перевірте вирівнювання DMARC.

Завдання 3: Опитайте DKIM TXT-запис за замовчуваним резолвером

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com

Що це означає: Відсутній вивід звично означає NXDOMAIN або відсутність TXT-запису (залежить від опцій dig).

Рішення: Запустіть повторно з докладнішими параметрами, щоб відрізнити «немає запису» від «помилка DNS».

Завдання 4: Відрізнити NXDOMAIN від SERVFAIL від порожньої відповіді

cr0x@server:~$ dig TXT selector1._domainkey.example.com +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51234
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Що це означає: NXDOMAIN: ім’я не існує публічно (або не з цього резолвера).

Рішення: Опублікуйте відсутній запис, або виправте селектор, який використовує підписувач, якщо в DNS вже є інший.

Завдання 5: Опитайте авторитетний DNS напряму (щоб виключити «мій резолвер бреше»)

cr0x@server:~$ dig +short NS example.com
ns1.dns-provider.net.
ns2.dns-provider.net.

cr0x@server:~$ dig +noall +answer TXT selector1._domainkey.example.com @ns1.dns-provider.net
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Що це означає: Авторитетний сервер має запис.

Рішення: Якщо отримувачі і далі бачать помилку, підозрюйте кешування резолверів, затримку пропагування або те, що отримувач бачить інший вигляд DNS (split-horizon, проблеми делегації).

Завдання 6: Порівняйте відповіді з публічним резолвером (зовнішня перевірка реальності)

cr0x@server:~$ dig +noall +answer TXT selector1._domainkey.example.com @8.8.8.8
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Що це означає: Публічний резолвер бачить ключ. Добре.

Рішення: Якщо DKIM іще падає, переходьте до невідповідності ключів / шляху підписування / канонізації та змін заголовків.

Завдання 7: Перевірте, чи запис не зламаний лапками, пробілами або відсутніми тегами

cr0x@server:~$ dig TXT selector1._domainkey.example.com +noall +answer
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." "morekeymaterial..."

Що це означає: Розбиті рядки TXT нормальні. Отримувачі їх об’єднують. Відсутність k=rsa зазвичай прийнятна (є значення за замовчуванням), але неправильно сформовані теги або «криві» лапки — ні.

Рішення: Якщо запис містить не ASCII-лапки, зайві крапки з комою або переноси рядків, вставлені UI DNS, виправте форматування запису.

Завдання 8: Перевірте, що OpenDKIM дійсно підписує і який селектор він використовує

cr0x@server:~$ sudo opendkim-testkey -d example.com -s selector1 -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'selector1._domainkey.example.com'
opendkim-testkey: key OK

Що це означає: З цього хоста OpenDKIM може отримати відкритий ключ і він парситься коректно.

Рішення: Якщо віддалені отримувачі іще падають, або вони не можуть дістати DNS, або підписувач фактично не використовує цей ключ/селектор для проблемного потоку.

Завдання 9: Визначте, яке правило KeyTable/SigningTable застосовується (поширене джерело невідповідності)

cr0x@server:~$ sudo grep -R --line-number -E 'SigningTable|KeyTable|Selector|Domain' /etc/opendkim.conf /etc/opendkim/*
/etc/opendkim.conf:12:KeyTable           /etc/opendkim/KeyTable
/etc/opendkim.conf:13:SigningTable       refile:/etc/opendkim/SigningTable
/etc/opendkim/KeyTable:5:selector1._domainkey.example.com example.com:selector1:/etc/opendkim/keys/example.com/selector1.private
/etc/opendkim/SigningTable:3:*@example.com selector1._domainkey.example.com

Що це означає: Для пошти з @example.com ви плануєте підписувати селектором selector1 використовуючи конкретний приватний файл ключа.

Рішення: Якщо в заголовку інший селектор, фактичний шлях пошти обходить цього підписувача або інший підписувач додає DKIM пізніше.

Завдання 10: Підтвердіть, що файл приватного ключа існує і права доступу коректні

cr0x@server:~$ sudo ls -l /etc/opendkim/keys/example.com/selector1.private
-r-------- 1 opendkim opendkim 1704 Jan  4 10:12 /etc/opendkim/keys/example.com/selector1.private

Що це означає: Файл існує, читається тільки користувачем/групою opendkim. Добре.

Рішення: Якщо права неправильні (доступні всім або недоступні opendkim), виправте їх і перезапустіть; недоступні ключі можуть призводити до непідписаної пошти або помилок під час виконання.

Завдання 11: Отримайте відкритий ключ з приватного ключа (доведіть, чи DNS збігається)

cr0x@server:~$ sudo openssl rsa -in /etc/opendkim/keys/example.com/selector1.private -pubout -outform PEM | sha256sum
0d7f3b6c6c2e3a9d93d8c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5  -

Що це означає: Тепер у вас є стабільний відбиток відкритого ключа, виведений із приватного.

Рішення: Порівняйте його з матеріалом ключа, який, як ви вважаєте, знаходиться в DNS (наступне завдання). Якщо відрізняється — у вас невідповідність ключів, а не «назви селектора».

Завдання 12: Витягніть відкритий ключ з DNS і отримайте для нього такий же відбиток

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com | tr -d '"' | sed 's/.*p=//' | tr -d ' ' | base64 -d 2>/dev/null | sha256sum
0d7f3b6c6c2e3a9d93d8c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5  -

Що це означає: Якщо хеш збігається із Завданням 11, DNS і приватний ключ співпадають. Якщо ні — ви публікуєте неправильний ключ для цього селектора.

Рішення: Опублікуйте правильний ключ або розгорніть правильний приватний ключ. Не перезапускайте все підряд, поки хеші не співпадуть.

Завдання 13: Перевірте, що Postfix дійсно відправляє через DKIM milter

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_milters|non_smtpd_milters|milter_protocol|milter_default_action'
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891
milter_protocol = 6
milter_default_action = accept

Що це означає: Postfix налаштований використовувати DKIM milter на localhost порті 8891.

Рішення: Якщо ці опції пусті, або налаштовано тільки smtpd_milters, деякі шляхи пошти (наприклад submission або reinjection) можуть обходити підписування. Виправте конфігурацію, щоб покривати всі потоки.

Завдання 14: Підтвердіть, що milter-сервіс слухає порт

cr0x@server:~$ sudo ss -ltnp | grep 8891
LISTEN 0      128        127.0.0.1:8891      0.0.0.0:*    users:(("opendkim",pid=2145,fd=6))

Що це означає: OpenDKIM працює і слухає.

Рішення: Якщо нічого не слухає — перезапустіть OpenDKIM і перевірте логи. Якщо OpenDKIM лежить, ви можете бачити непідписану пошту замість невідповідності селектора — інший симптом, інше рішення.

Завдання 15: Перевірте, що селектор існує під час ротації ключів (перелічіть, що опубліковано)

cr0x@server:~$ for s in selector1 selector2 prod2026; do echo "== $s =="; dig +noall +answer TXT ${s}._domainkey.example.com; done
== selector1 ==
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
== selector2 ==
== prod2026 ==

Що це означає: У DNS існує тільки selector1; selector2/prod2026 відсутні.

Рішення: Не перемикайте підписувач на selector2/prod2026, поки DNS не буде готовий, якщо вам не подобається дивитися на графіки доставлянності, що падають.

Жарт №2: DNS-пропагування — єдина частина інтернету, яка офіційно працює за принципом «ви пробували почекати?» як дійовий крок у відлагодженні.

Чек-листи / покроковий план

Інцидентний чек-лист (15 хвилин до стабільності)

1. Отримайте свіжий невдалий лист. Не пересланий, не повторно відправлений, не скриншот.
2. Витягніть d= і s=. Це ваш невід’ємний факт.
3. Опитайте DNS для цього селектора і домену. Використовуйте ваш резолвер і публічний резолвер.
4. Якщо NXDOMAIN: опублікуйте відсутній TXT-запис або поверніть підписувача до існуючого селектора.
5. Якщо запис існує: запустіть opendkim-testkey (або еквівалент вашого підписувача) з хоста підписування.
6. Якщо локально «key OK», але отримувачі падають: підозрівайте видимість DNS, делегацію або переривчасті SERVFAIL при масштабі.
7. Перевірте шлях підписування: підтвердіть, що пошта йде через очікуваний шлюз/milter.
8. Підтвердіть вирівнювання DMARC: коли DKIM пройде, перевірте, що d= вирівнюється з доменом у From: для вашої політики.
9. Відправте канарку. Перевірте заголовки з боку отримувача і зафіксуйте докази для постмортему.

Чек-лист змін (безпечна ротація селектора/ключа без драм)

1. Згенеруйте нову пару ключів. Використайте нову назву селектора, яка не колідує (наприклад, s2026a).
2. Спочатку опублікуйте новий селектор у DNS. Почекайте, поки він стане видимим зовні.
3. Розгорніть приватний ключ на всіх підписувачах. Підтвердіть права доступу і відповідність у конфігурації (SigningTable/KeyTable).
4. Переключіть підписування на новий селектор. Перезавантажте сервіси, перевірте канарковим листом.
5. Тримайте старий селектор опублікованим. Принаймні кілька днів; довше, якщо у вас є відкладені черги або архівні системи.
6. Видаляйте старий селектор лише після перевірки. Не прибирайте його в той же день. Так ви створюєте хайзенбаги у журналах відповідності.

Дизайн чек-лист (зменшіть ймовірність невідповідності селектора)

• Один власник за вихідне підписування. Якщо п’ять команд можуть міняти DKIM, ніхто не відповідальний за доставлянність.
• Централізувати зміни DNS з код-рев’ю. DKIM-записи — це production-конфіг, а не заявка в службу підтримки.
• Канарковий моніторинг зовні вашої мережі. Внутрішні перевірки пропускають split-horizon DNS і поведінку зовнішніх резолверів.
• Запишіть селектор у вашому рукбуці. Не «DKIM налаштовано», а «селектор X; процедура ротації Y».

Поширені помилки: симптом → причина → виправлення

1) Симптом: «dkim=fail (no key for signature)»

Причина: DNS не має TXT-запису для селектора з заголовка повідомлення, або отримувач не може його резолвити.

Виправлення: Опублікуйте TXT-запис <selector>._domainkey.<domain>. Перевірте через авторитетні та публічні резолвери. Перевірте TTL негативного кешу, якщо «все ще падає» короткий час.

2) Симптом: «dkim=fail (bad signature)» при наявності DNS-запису

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

Виправлення: Порівняйте відбитки відкритого ключа (Завдання 11–12). Переінсталюйте правильний ключ скрізь або оновіть DNS, щоб відповідати розгорнутому ключу. Потім протестуйте свіжим листом.

3) Симптом: DKIM інколи проходить, інколи ні

Причина: Декілька вихідних шляхів або декілька підписувачів з несинхронізованими конфігураціями; або переривчасті помилки резолвингу DNS у масштабі (SERVFAIL, ліміти).

Виправлення: Корелюйте невдалі повідомлення з IP/хостами відправника; перевірте, хто додає DKIM. Забезпечте ідентичну конфігурацію селекторів/ключів на всіх вузлах. Якщо проблема в DNS — стабілізуйте TTL і надійність провайдера.

4) Симптом: SPF проходить, DKIM проходить, але DMARC не проходить

Причина: Проблема вирівнювання: DKIM d= домен не вирівнюється з видимим доменом From:, або SPF mailfrom домен не вирівнюється.

Виправлення: Переконайтесь, що DKIM підписує з d=, що відповідає (або є піддоменом, дозволеним режимом вирівнювання) домену From. Не «виправляйте DMARC» шляхом послаблення політики, якщо це не потрібно.

5) Симптом: Всередині все виглядає коректно, але зовнішні отримувачі кажуть, що селектор відсутній

Причина: Split-horizon DNS, зламана делегація або зміни DNS застосовані лише до внутрішнього вигляду.

Виправлення: Опитайте авторитетні сервери і публічні резолвери ззовні корпоративної мережі. Виправте публічні записи зони і делегацію. Автентифікацію пошти оцінюють у публічному інтернеті, а не через ваш VPN.

6) Симптом: DKIM падає після «дрібної» зміни інфраструктури електронної пошти

Причина: Пошта тепер обходить хоп підписування (новий маршрут реле, змінений порт для submit, новий шлюз, змінені налаштування milter).

Виправлення: Прослідкуйте шлях повідомлення. Переконайтесь, що milters застосовуються до всіх точок інжекції (smtp і non-smtp). Переконайтесь, що заголовок DKIM присутній і створений очікуваною системою.

7) Симптом: DKIM падає тільки для одного піддомену або підрозділу

Причина: Несумісність SigningTable: правила підписують @example.com, але не @alerts.example.com, або підписувач використовує d=example.com, а From — піддомен і політика вимагає строгого вирівнювання.

Виправлення: Оновіть правила SigningTable; опублікуйте ключі для правильного домену; підтвердіть вирівнювання відповідно до режиму DMARC (relaxed vs strict).

8) Симптом: Отримувач каже «key too short» або вважає DKIM слабким

Причина: Досі використовується 1024-бітний ключ або застаріла конфігурація.

Виправлення: Перейдіть на 2048-бітні ключі. Опублікуйте новий селектор, розгорніть новий ключ, переключіть підписування, а потім виведіть старий селектор. Не намагайтесь «редагувати» старий ключ на місці.

Питання та відповіді

1) Що таке селектор DKIM простими словами?

Це ім’я ключа. Селектор підказує отримувачам, який DNS-запис шукати для відкритого ключа, що використовується для перевірки підпису.
Один домен може мати декілька селекторів, щоб ви могли ротаціювати ключі або щоб різні системи підписували різними ключами.

2) Як знайти селектор, який використовує моя система?

Не вгадуйте. Подивіться на реальний лист і прочитайте заголовок DKIM-Signature: s=....
Якщо повідомлення не має DKIM-Signature, у вас інша проблема: підписування не відбувається.

3) Чому невідповідність селектора часто виявляється як збій DMARC?

DMARC вимагає, щоб або SPF, або DKIM пройшли і були вирівняні з доменом From.
Якщо DKIM не проходить через відсутній селектор або невідповідність ключів, а SPF не вирівняний (часто з сторонніми відправниками), DMARC не проходить.

4) Чи можна «просто змінити селектор» на підписувачі?

Так, але лише якщо DNS уже публікує ключ для цього селектора і підписувач має відповідний приватний ключ.
Зміна підписувача першою — найшвидший шлях створити глобальний інцидент доставлянності.

5) Чому іноді я бачу два селектори, наприклад selector1 і selector2, на деяких платформах?

Багато провайдерів підтримують безшовну ротацію, тримаючи два ключі опублікованими і переключаючись між ними.
Платформа може підписувати одним, а інший — бути в стадії підготовки. Люди часто видаляють «неактивний» і викликають переривчасті збої.

6) Як довго тримати старий селектор опублікованим після ротації?

Довше, ніж ви думаєте. Зазвичай принаймні кілька днів; довше, якщо у вас є відкладені черги, повторні спроби, пересилання або дотримання регуляторних вимог.
Перевірка DKIM відбувається під час отримання, тому затримана доставка може все ще потребувати старого відкритого ключа.

7) Що робити, якщо DNS із мого ноутбука виглядає коректно, але отримувачі іще падають?

Перевірте ззовні вашої мережі і опитайте авторитетні сервери напряму.
Split-horizon DNS, зламана делегація і проблеми провайдера DNS проявляються як «в мене працює», поки зовнішній світ бачить інше.

8) Чи залежить DKIM від IP-адреси відправника, як SPF?

Прямо — ні. Перевірка DKIM базується на підписі і DNS-запиті ключа, а не на IP.
Але отримувачі комбінують сигнали: якщо репутація IP погана, невелика проблема з DKIM травмує сильніше.

9) Чи невідповідність селектора те саме, що «bad signature»?

Ні. Невідповідність селектора часто означає «ключ не знайдено для цього селектора» (відсутній запис або неправильна назва).
«Bad signature» зазвичай означає, що запис існує, але відкритий ключ не підтверджує підпис (невідповідність ключів або модифікація повідомлення).

10) Чи варто автоматизувати перевірку DKIM?

Так. Простий зовнішній канарковий тест, який захоплює заголовки і оповіщає про зміни DKIM/SPF/DMARC, зловить проблеми селектора до того, як їх помітять клієнти.
Це одне з тих місць, де нудний моніторинг кращий за героїчні дії.

Наступні кроки, щоб запобігти повторенню інциденту

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

Зробіть це наступним кроком, поки біль ще свіжий:

1. Запишіть ваші живі селектори для кожного домену і кожної системи відправки.
2. Додайте зовнішню канарку, що сповіщає про зміни DKIM/SPF/DMARC.
3. Уніфікуйте ротацію: спочатку опублікуйте новий селектор, потім розгорніть ключі, потім переключіть підписування, а потім пізніше виведіть старі ключі.
4. Припиніть імпровізувати з назвами селекторів, якщо ви не контролюєте конфігурацію підписувача наскрізь.

Аутентифікація електронної пошти не приваблива. Через це вона ламається.
Ставтеся до DKIM як до продакшн-інфраструктури, а не як до галочки в порталі постачальника, і невідповідність селектора стане двохвилинним виправленням — один раз, а не щоквартально.