Як створити DMARC-запис за допомогою генератора: покрокова інструкція

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

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

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

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

Як працює dmarc generator і що він насправді робить

DMARC generator — це форма, яка збирає значення (політика, адреса для звітів, відсоток охоплення, вирівнювання SPF/DKIM) і на виході видає готовий рядок для TXT-запису на домені _dmarc.вашдомен.com. Сам генератор нічого не перевіряє на вашому сервері — він просто формує синтаксично коректний текст за вашими параметрами, тому корисність такого інструменту, як dmarc generator mxtoolbox чи аналогічних, обмежена саме складанням рядка, а не діагностикою.

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

• Перевірте, що SPF-запис існує і включає всі сервіси, з яких реально надсилаються листи
• Перевірте, що DKIM-підпис активний для домену або субдомену розсилки
• Визначте адресу, на яку приходитимуть агреговані звіти (тег rua)
• Оберіть початкову політику — для нового домену завжди p=none
• Скористайтеся генератором, щоб зібрати рядок без помилок у синтаксисі

Покрокове створення запису через генератор

Типова форма dmarc generator просить заповнити кілька полів. Розберемо кожне з них окремо, оскільки саме тут найчастіше роблять помилки новачки.

Політика (p=) — головне поле. Для щойно налаштованого домену під розсилку правильне значення — none: запис буде збирати звіти, але не втручатиметься в доставку листів. Це дає час побачити реальну картину проходження SPF/DKIM, перш ніж вмикати жорсткіші правила.

Адреса для звітів (rua=mailto:) — сюди поштові провайдери щодня надсилатимуть XML-звіт про те, скільки листів з вашого домену пройшли або не пройшли автентифікацію. Без цього тега ви публікуєте DMARC, але не бачите жодних даних — а саме дані потрібні, щоб зрозуміти, чи готовий домен до жорсткішої політики.

Вирівнювання (aspf=, adkim=) — параметр r (relaxed) підходить для більшості компаній, s (strict) вимагає точного збігу домену в заголовку From з доменом SPF/DKIM і зазвичай зайвий для перших тижнів роботи.

Pct (pct=) — відсоток листів, до яких застосовується політика вище за none. На старті має сенс лишити 100, оскільки при p=none цей параметр все одно не впливає на доставку.

Скільки часу займає перехід від none до reject

Орієнтовна логіка руху по політиках — від м'якої до жорсткої, з паузами на перевірку звітів. Ці цифри — практичний орієнтир з досвіду ведення B2B-розсилок, а не фіксований регламент.

Швидкий перехід одразу на p=reject — найпоширеніша причина того, що легітимна корпоративна пошта (наприклад, лист від бухгалтерії або сповіщення CRM) раптом перестає доходити. Тому кожен крок варто витримувати щонайменше два-три тижні спостереження за звітами.

Типові помилки при роботі з dmarc checker tool

Після публікації запису варто прогнати домен через будь-який dmarc checker tool або перевірити dmarc record check вручну командою dig TXT _dmarc.вашдомен.com. Найчастіші помилки, які виявляє така перевірка, повторюються з домену в домен.

• Два DMARC-записи на одному домені — DNS дозволяє це технічно, але специфікація вимагає рівно один запис, інакше поведінка непередбачувана
• Запис опубліковано на вашдомен.com замість _dmarc.вашдомен.com — найпоширеніша помилка новачків
• Відсутня крапка в кінці v=DMARC1 через копіювання з іншого генератора з несумісним форматуванням
• Адреса rua на іншому домені без дозволу на прийом звітів (потрібен додатковий TXT-запис на домені-отримувачі)
• Політика p=reject виставлена одразу, без жодного тижня спостереження за звітами

Як це виглядає у роботі LDM з клієнтськими доменами

У LDM перед запуском холодної розсилки на новий домен ми завжди перевіряємо не тільки наявність DMARC-запису, а й те, які звіти він реально збирає за перший тиждень. Генератор — лише перший крок; далі важливо прочитати агреговані звіти й переконатися, що процент проходження SPF/DKIM близький до 100% ще на етапі p=none.

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

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