DMARC не лечит доставляемость сам по себе — он убирает шум

DMARC не лечит доставляемость сам по себе — он убирает шум

Я часто вижу одну и ту же ошибку: бренд внедряет DMARC, гордится политикой `p=reject`, а потом удивляется, почему письма всё ещё попадают в промоакции или задерживаются. Мой вывод простой: DMARC — это не «кнопка доверия», а санитарный фильтр для домена.

Что он реально делает:
— снижает риск подделки домена и фишинга от вашего имени;
— даёт провайдерам сигнал, что вы контролируете инфраструктуру;
— помогает стабилизировать репутацию, но только если у вас в порядке SPF, DKIM и выровнены поддомены.

Но есть важный нюанс из практики: **самый частый провал — не в политике, а в дисциплине отправки**. За последний год я несколько раз видел, как после включения DMARC у бренда начинала «сыпаться» часть транзакционных писем, потому что:
— один сервис рассылал через чужой поддомен без согласования;
— CRM, support и product-уведомления использовали разные From-домены;
— маркетинг отправлял с нового домена, который не успели прогреть на репутацию.

И вот здесь становится видно, что deliverability в 2026 году — это уже не про отдельную кампанию, а про **целостность доменной архитектуры**. Когда у вас RevOps-модель, почта, CRM и продуктовые цепочки должны жить в одной системе координат: кто отправляет, с какого домена, с какой целью и что видит получатель.

Если коротко, я бы ставил DMARC не как финальный этап, а как старт ревизии:
— кто реально отправляет от имени бренда;
— какие домены и поддомены участвуют;
— нет ли «теневых» сервисов;
— совпадает ли техническая схема с тем, как вы строите прогрев.

Мой практический ориентир: если вы видите больше 3–5 источников отправки под одним брендом без единой схемы аутентификации, у вас уже не deliverability, а архитектурный долг. И он всегда вылезает в репутации домена.

По этой же теме советуем @AdOpsRoom