DMARC checker: покрокова перевірка DMARC-запису домену перед розсилкою

Перед будь-якою холодною розсилкою домен має пройти базову перевірку: SPF, DKIM і DMARC записи повинні існувати й узгоджуватися між собою. Без цього навіть якісний персоналізований лист провайдер може відправити в спам або взагалі відхилити. Розберемо, які dmarc checker інструменти використовувати, як читати результат і які помилки трапляються найчастіше.

Навіщо перевіряти DMARC перед холодною розсилкою

DMARC (Domain-based Message Authentication, Reporting and Conformance) — це запис у DNS, який каже поштовим серверам одержувача, що робити з листом, якщо він не пройшов SPF або DKIM перевірку. Для холодних B2B-листів це критично: Gmail, Outlook і корпоративні поштові шлюзи все частіше блокують або позначають спамом пошту з доменів без коректної автентифікації, навіть якщо контент листа абсолютно легітимний.

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

Це не разова дія. Перевіряти DMARC потрібно перед запуском кожної нової кампанії з нового піддомену, після зміни поштового провайдера і періодично для основного корпоративного домену — записи іноді ламаються після оновлення DNS-хостингу чи міграції пошти.

Які інструменти check spf dmarc dkim records використовувати

Для перевірки не потрібен спеціальний софт — достатньо браузера. Ось перевірені варіанти, які покривають більшість практичних задач.

• MxToolbox DMARC Lookup — класичний dmarc checker mxtoolbox, показує сирий запис, розбір тегів (p=, rua=, pct=) і базові попередження про помилки синтаксису
• dmarcian DMARC Inspector — детальніший розбір політики з поясненнями кожного параметра людською мовою, зручно для тих, хто вперше стикається з DMARC
• Google Admin Toolbox Check MX — швидка перевірка SPF, DKIM і DMARC одразу для домену, зручна якщо пошта на Google Workspace
• dig або nslookup у терміналі — команда dig TXT _dmarc.domain.com +short показує сирий запис напряму з DNS без проміжних сервісів, корисно коли потрібно перевірити, чи запис вже поширився після зміни
• Вбудовані перевірки поштових платформ (наприклад, панель домену в LDM або Postmark) — показують статус автентифікації в контексті конкретної кампанії, а не абстрактно

Як читати результат dmarc checker online

Результат перевірки складається з кількох частин, і важливо розуміти кожну, а не просто бачити «зелену галочку».

Перше — наявність запису. Якщо TXT-запис за адресою _dmarc.вашдомен.com відсутній, поштові сервери вважають, що власник домену взагалі не думав про автентифікацію, і це саме по собі знижує довіру до відправника.

Друге — політика (тег p=). Значення none означає «тільки моніторинг, нічого не робити з листами, що провалили перевірку» — це стартова позиція, а не робоча конфігурація для розсилок. Quarantine відправляє підозрілі листи в спам, reject блокує їх повністю. Для домену, з якого йде холодна розсилка, розумний мінімум — quarantine з поступовим переходом до reject після кількох тижнів стабільної роботи.

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

Приклад перевірки та типові помилки

Розглянемо типову ситуацію. Компанія реєструє піддомен mail.company.com.ua спеціально для холодної розсилки — правильний підхід, щоб не ризикувати репутацією основного корпоративного домену. Але забуває додати DMARC-запис для піддомену окремо, покладаючись на запис батьківського домену.

Якщо перевірити через MxToolbox, checker покаже, що DMARC успадковується від company.com.ua, але фактична політика там p=none — тобто ніякого реального захисту немає, і поштові сервіси одержувачів це бачать. Після додавання власного запису для піддомену з p=quarantine ситуація змінюється: провайдери починають довіряти піддомену як окремій сутності з чіткими правилами.

Чек-лист перед запуском кампанії

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

• SPF-запис існує, включає всі сервери відправки (ESP, CRM, бекап-провайдер) і не перевищує ліміт 10 DNS lookups
• DKIM-селектор налаштований у ESP і опублікований у DNS, підпис проходить перевірку в тестовому листі
• DMARC-запис існує окремо для піддомену розсилки, політика не нижче quarantine
• Домен From і домен DKIM-підпису збігаються (alignment strict або relaxed, але не порушений)
• Адреса rua= активна і хтось реально переглядає звіти, а не просто збирає їх
• Піддомен для холодної розсилки прогрітий поступовим збільшенням обсягу перед основним запуском

Як це працює в LDM

У LDM перевірка DMARC — обов'язковий крок перед підключенням будь-якого клієнтського домену до кампанії, а не опційна рекомендація. Система автоматично прогонює check spf dmarc dkim records при додаванні нового домену і показує статус прямо в панелі — без потреби вручну відкривати сторонній dmarc checker online.

Для холодних розсилок LDM рекомендує окремий піддомен з власним DMARC-записом, поступовий прогрів і поетапний перехід від p=none до p=quarantine — так основний корпоративний домен ніколи не ризикує репутацією через розсилку, а відповіді від зацікавлених лідів все одно потрапляють у CRM менеджера.

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