Как DMARC меняет судьбу письма после отправки?
Получающий сервер сопоставляет домен в поле From с доменом, который подтвердил SPF или DKIM. Если вы пишете от sales@company.ru, а подпись DKIM относится к чужому или техническому домену, проверка может не пройти. Политика DMARC подсказывает серверу: принять такое письмо, пометить подозрительным или отклонить.
| Сигнал | Что видит получатель | Практический итог |
|---|---|---|
| SPF или DKIM совпадают с From | Отправитель подтверждён | Письмо проходит техническую проверку |
| Проверка не совпадает | Адрес отправителя вызывает сомнение | Растёт риск фильтрации или отклонения |
| Есть DMARC-отчёты | Видны источники отправки | Можно найти лишний сервис или ошибку |
DMARC не делает слабое предложение убедительным и не гарантирует попадание во «Входящие». Он закрывает другой участок задачи: подтверждает право отправлять письма с домена. Проверять его вместе с SPF и DKIM стоит до загрузки первой очереди контактов.
С какой политики начинать, чтобы не остановить рабочую почту?
Резкая политика reject на домене без инвентаризации отправителей способна отсечь не только рассылку, но и письма системы учёта клиентов, формы сайта, кадрового сервиса или бухгалтерии. Сначала собирают все легитимные источники, затем проверяют выравнивание доменов и только после этого усиливают правило.
- Разместите DMARC-запись в режиме наблюдения p=none и укажите адрес для агрегированных отчётов.
- В отчётах найдите все IP-адреса и сервисы, которые отправляют письма от домена.
- Для каждого источника настройте SPF или DKIM так, чтобы домен совпадал с From.
- После нескольких циклов отчётов решите, можно ли перейти к quarantine или reject.
Для отдельного домена под исходящие касания схема та же: сначала верификация, потом объём. Если в отчёте появился сервис, которого команда не подключала, не меняйте запись вслепую — сначала установите, не является ли это старой интеграцией. Полный порядок DNS-проверок собран в гайде по SPF, DKIM и DMARC.
Какие ошибки ломают DMARC в холодной кампании?
Типовая ошибка — настроить DKIM у провайдера, но оставить в From основной домен, когда подпись идёт от другого. Вторая — добавить второй SPF-записью вместо объединения механизмов: сервер может увидеть конфликт и не подтвердить отправителя. Третья — включить строгую политику, не проверив письма сайта и системы учёта клиентов.
Компания отправляет письмо с адреса hello@new-company.ru. В заголовках DKIM подписан доменом mailer-service.net, SPF проходит для сервиса, но не выровнен с new-company.ru. ЛПР отвечает: «Письмо ушло в подозрительные, продублируйте». Проблема не в теме «Идея для отдела закупок», а в том, что домен отправителя не подтверждён связанной подписью. После настройки собственной DKIM-подписи сначала проверяют заголовки тестового письма, а не запускают новую волну.
Не смешивайте технический диагноз с качеством базы. Недействительный адрес даст отскок (отказ доставки) даже при безупречном DMARC, а неуместное письмо может получить отказ при полностью пройденной проверке. Для разбора обеих частей кампании полезна проверка доставляемости.
Где DMARC не сработает как решение?
DMARC не подходит как быстрый способ поднять ответы или исправить репутацию домена, который уже получил негативные сигналы. Он также не заменяет валидацию адресов, корректный обратный адрес и понятную причину написать конкретному человеку. Если письмо отправлено не тому ЛПР или содержит общий оффер, техническая аутентификация лишь докажет, что это письмо отправили именно вы.
- Не включайте reject, пока не проверены сайт, система учёта клиентов, рассылочный сервис и корпоративная почта.
- Не считайте отсутствие DMARC единственной причиной спама без просмотра заголовков и отказов.
- Не используйте основной домен для эксперимента, если его рабочие отправители ещё не описаны.
Когда задача — подготовить отдельную инфраструктуру под кампанию, DMARC настраивают в связке с прогревом доменов и ящиков и тестовой отправкой. Это регламент, а не волшебная кнопка.