Як перевірити DKIM-підпис і не втратити доставленість пошти

Коли команда починає відправляти холодні листи не з одного домену, а з п'яти-десяти, DKIM-підпис — перше, що ламається непомітно: розсилка йде, відкриття є, але частина листів осідає у спамі без жодної помилки в інтерфейсі ESP. DKIM checker показує це до того, як постраждає репутація домену, а не після. У цьому гіді — як перевірити SPF, DKIM, DMARC записи вручну і через готові інструменти, які помилки трапляються найчастіше і як побудувати перевірку в щоденний процес.

Чому DKIM-підпис ламається саме тоді, коли ви масштабуєте розсилки

DKIM (DomainKeys Identified Mail) — це криптографічний підпис, який додається до заголовків листа і підтверджує, що повідомлення справді відправлене з вашого домену і не змінювалося в дорозі. Публічний ключ для перевірки лежить у DNS як TXT-запис за конкретним селектором — наприклад, «default._domainkey.vashdomen.com». Поки компанія відправляє з одного домену через одну поштову скриньку, цей запис створюється один раз і про нього забувають.

Проблема виникає, коли команда починає масштабувати таргетовані B2B-розсилки: додає нові домени для «прогріву», підключає кілька поштових скриньок на субдоменах, змінює ESP або платформу для холодних листів. Кожна така зміна означає новий селектор або новий приватний ключ, а сам домен при цьому може взагалі не мати оновленого DKIM-запису. Лист іде, DMARC не блокує його жорстко, але поштові сервіси одержувача бачать невідповідність — і саме такі листи найчастіше осідають у папці «Спам» без будь-якого повідомлення про помилку у відправника.

Як перевірити SPF, DKIM, DMARC записи: покроковий гід

Перевірка DKIM завжди прив'язана до селектора — рядка перед «._domainkey» у DNS-записі. Селектор задає ESP або поштовий сервер при генерації ключа, і його треба знати заздалегідь: подивитися в налаштуваннях платформи розсилок або в заголовках уже надісланого листа (поле DKIM-Signature, параметр «s=»).

Далі перевірка SPF, DKIM, DMARC записів робиться або вручну через dig/nslookup, або через готовий spf dkim dmarc checker — наприклад, DKIM Inspector від dmarcian чи аналогічні онлайн-інструменти, які одразу показують, чи запис існує, чи ключ валідний і чи є розбіжність з тим, що реально підписано в листі.

• Знайдіть селектор у заголовку листа (DKIM-Signature: … s=selector1) або в панелі ESP
• Перевірте TXT-запис за адресою «selector._domainkey.домен» через dig TXT або онлайн spf dkim dmarc checker
• Переконайтеся, що запис містить публічний ключ у форматі «v=DKIM1; k=rsa; p=…» без обривів рядка
• Надішліть тестовий лист на скриньку, що показує заголовки (наприклад, сервіс перевірки пошти), і перевірте результат «dkim=pass»
• Перевірте вирівнювання (alignment) DKIM-домену з доменом у полі «From» — DMARC вимагає збіг за замовчуванням у strict-режимі
• Повторіть перевірку після будь-якої зміни ESP, домену відправки або міграції поштового сервера

Що показує DKIM checker і як читати результат

Результат перевірки — це не «так/ні», а набір статусів: запис знайдено чи ні, ключ валідний за форматом чи ні, підпис у конкретному листі пройшов перевірку чи ні. Ці три речі можуть розходитися: DNS-запис існує, але лист все одно проходить з «dkim=fail», якщо приватний ключ на сервері не відповідає публічному в DNS — типова ситуація після зміни постачальника пошти без оновлення запису.

Для команд, які ведуть кілька доменів одночасно (основний бренд-домен плюс декілька для холодних розсилок), варто дивитися не на один лист, а на агреговану картину: скільки листів з кожного домену проходять DKIM valid, і як це корелює з потраплянням у Вхідні. Орієнтовний вплив стану DKIM на доставленість — нижче.

Типові помилки при перевірці DKIM для кількох доменів

Найчастіша помилка — перевіряти сам домен замість конкретного селектора: команда вводить у сервіс перевірки «vashdomen.com» без селектора, отримує «запис не знайдено» і робить висновок, що DKIM взагалі не налаштований, хоча насправді просто не вказано селектор.

• Перевірка домену без селектора — DKIM завжди прив'язаний до конкретного «selector._domainkey», загального запису не існує
• Ігнорування вирівнювання з DMARC — валідний DKIM з доменом, що не збігається з полем «From», не рятує від жорсткої DMARC-політики
• Один раз перевірили при налаштуванні й забули — після зміни ESP старий селектор часто лишається в DNS, а новий не додається
• Плутанина між скринькою для розсилок і доменом, на який вказує SPF-запис — SPF перевіряє IP відправника, DKIM перевіряє підпис, це різні механізми, і валідність одного не гарантує іншого
• Перевірка тільки на одному тестовому листі — краще прогнати кілька листів з різних скриньок домену, бо селектор може відрізнятися по підрозділах компанії

Чек-лист перед запуском нової розсилки: як це робить LDM

У практиці таргетованих B2B-розсилок перевірку DKIM варто вбудувати в чек-лист запуску, а не робити разово при купівлі домену. Наприклад, компанія «Технобуд-Партнер» додавала третій домен для розсилок відділу продажу — SPF і DMARC скопіювали з основного домену, а DKIM-запис забули, бо він генерується окремо для кожного домену в ESP. Перші два тижні розсилка йшла без помилок у панелі, але відкриття впали вдвічі — причину знайшли лише прогнавши перевірку через DKIM checker.

У LDM перед підключенням нового домену до розсилки перевірка SPF, DKIM, DMARC записів — обов'язковий крок прогріву, і вона повторюється щотижня протягом перших місяців активного використання домену, поки репутація не стабілізується.

• DKIM-запис створено з правильним селектором для кожного домену розсилки окремо
• SPF включає всі IP та сервіси, з яких реально йде пошта, без переліку понад 10 механізмів include
• DMARC-політика хоча б у режимі «p=none» з надсиланням звітів — щоб бачити розбіжності до переходу на «quarantine» чи «reject»
• Тестовий лист з кожного нового домену перевірено на «dkim=pass» і «spf=pass» перед масовим запуском
• Перевірка повторюється після будь-якої зміни постачальника пошти, IP-адреси чи структури субдоменів

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