DMARC-політика для холодних B2B-розсилок: від none до reject без втрати доставлюваності

Якщо у вашому DMARC record стоїть p=none, домен технічно захищений лише на папері — звіти приходять, а спамери й далі можуть підробляти адресу відправника. Перехід на quarantine чи reject реально закриває цю діру, але зроблений різко він ламає доставлюваність саме тоді, коли йде активна холодна кампанія. Розберемо, чим відрізняються рівні політики і як пройти шлях безпечно.

Чому DMARC не зводиться до одного запису в DNS

DMARC (Domain-based Message Authentication, Reporting and Conformance) працює поверх SPF і DKIM: він каже поштовим серверам, що робити з листом, який не пройшов ці перевірки від імені вашого домену. Сам по собі dmarc record — це один TXT-запис у зоні _dmarc.вашдомен.com, але його реальна дія залежить від значення тега p= — policy.

Проблема в тому, що більшість гайдів радять одразу ставити p=reject «для безпеки», не пояснюючи, що це рішення без відкату вручну: якщо у вас є забутий сервіс розсилки, CRM-інтеграція чи маркетинговий інструмент, що надсилає листи від імені домену без коректного SPF/DKIM, reject просто відхилить ці листи мовчки. Для домену, який одночасно веде холодні B2B-кампанії, це критично — саме нові листи від незнайомих отримувачам відправників найчастіше потрапляють під підозру.

Три рівні політики: none, quarantine, reject

DMARC policy reject vs quarantine — не про «краще/гірше», а про різну жорсткість дії щодо листів, які провалили автентифікацію.

• p=none — моніторинг: лист доставляється як є, ви лише отримуєте агрегований DMARC-звіт (RUA) про те, хто надсилає пошту від вашого домену, включно з нелегітимними джерелами
• p=quarantine — підозрілі листи не відхиляються, а позначаються як спам або йдуть у карантинну папку отримувача; це проміжний рівень, який дає видимість наслідків без повної втрати листа
• p=reject — лист відхиляється на рівні SMTP ще до доставки; отримувач його взагалі не бачить, навіть у спамі
• pct= — тег, що дозволяє застосовувати політику лише до частини трафіку (наприклад pct=10 означає 10% листів), корисний саме для поступового rollout

Як безпечно пройти шлях від none до reject

Правильна послідовність завжди починається зі збору даних, а не з жорсткої дії. Використовуйте dmarc policy checker або будь-який сервіс агрегації DMARC-звітів (є безкоштовні варіанти для малого об'єму пошти), щоб побачити повну картину джерел відправки за вашим доменом.

Тримайте p=none щонайменше 2-4 тижні для домену з помірним трафіком, довше — якщо у вас є сезонні розсилки чи рідко активні інтеграції (наприклад, бухгалтерський сервіс, що шле рахунки раз на квартал). За цей час у звітах мають з'явитися всі легітимні джерела: поштовий провайдер, CRM, платформа для cold email, транзакційні сервіси.

Коли всі легітимні джерела ідентифіковані та проходять SPF або DKIM alignment, переходьте на quarantine з pct=25, поступово піднімаючи відсоток до 100 протягом кількох тижнів. Тільки після стабільного quarantine без нових проблем варто переходити на reject — спочатку теж із частковим pct.

Що станеться, якщо DMARC взагалі не налаштований

Помилка dmarc policy not enabled (або повна відсутність запису _dmarc) означає, що домен не має жодного захисту від спуфінгу. Будь-хто може надіслати лист «від вашого імені» на будь-яку адресу, і без DMARC поштові сервери отримувача не мають чіткої інструкції, що з таким листом робити — рішення лишається на розсуд їхніх внутрішніх алгоритмів.

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

Типові помилки при впровадженні

Найчастіша помилка — ставити p=reject одразу, «щоб не витрачати час на проміжні кроки». Наслідок: частина CRM-сповіщень, автоматичних відповідей чи листів через сторонні сервіси розсилки перестає доходити без жодного попередження, і власник домену дізнається про це тільки зі скарг клієнтів.

Друга поширена помилка — плутати DMARC record із SPF record: без коректно налаштованих SPF і DKIM для всіх джерел відправки (включно з платформою для холодних розсилок) навіть м'яка quarantine-політика почне блокувати легітимну пошту.

• Ігнорування DMARC-звітів (RUA/RUF) — політика без моніторингу — це стрільба наосліп
• Використання одного домену і для холодних кампаній, і для транзакційної пошти без чіткого розмежування SPF/DKIM alignment по джерелах
• Занадто швидкий перехід на pct=100 reject без тестового періоду на частині трафіку
• Відсутність alignment mode (aspf, adkim) — суворий режим strict може відхиляти легітимні листи через субдомени

Як LDM веде домени клієнтів через цей перехід

Для клієнтів, які запускають активні холодні B2B-кампанії, ми радимо окремі піддомени для відправки (наприклад outreach.вашкомпанія.com) — це ізолює репутаційний ризик холодної пошти від основного корпоративного домену, де йдуть рахунки, договори та відповіді клієнтам.

Практичний чек-лист, яким ми користуємось під час впровадження DMARC для нових доменів: перевірити наявність і коректність dmarc records через dmarc policy checker, зібрати мінімум 2-3 тижні звітів на p=none, звірити всі джерела відправки з реальним списком інструментів компанії, і тільки потім переходити на quarantine з поступовим pct.

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