DMARC не лечит репутацию домена. Он лишь перестаёт врать о причине отказа

DMARC не лечит репутацию домена. Он лишь перестаёт врать о причине отказа

За последние годы я слишком часто вижу одну и ту же ошибку: команды ставят DMARC, включают p=quarantine или p=reject и ждут, что доставка «сама подтянется». Не подтягивается. DMARC решает задачу подлинности письма, а не доверия к отправителю.

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

DMARC полезен как рельс безопасности. Он закрывает подмену отправителя, помогает вытащить теневые домены, даёт отчётность по выравниванию SPF/DKIM. Но если у вас прогрев сделан «по календарю», без связи с вовлечённостью и качеством сегментов, то после перехода на строгую политику вы просто начнёте быстрее видеть свои же ошибки.

Из практики: почти в каждой проверке у клиентов проблема не в самой политике DMARC, а в том, что **один и тот же домен используют для разных сценариев без разделения репутации**. Транзакционные письма, промо, триггеры, холодные касания — всё в одной корзине. В итоге промо-сегмент портит доставку сервисным письмам, а потом команда удивляется, почему квитанции и сбросы пароля падают в промо или спам.

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

В 2026-м, когда выживают не объёмы, а точность и удержание, репутация домена — это не настройка. Это операционная дисциплина. DMARC здесь важен, но он работает только в системе.

— @DeliverabilityRoom