Запись DMARC сообщает почтовым серверам получателей, как проверять письма, отправленные от имени вашего домена, и что делать с подделками. Она опирается на SPF и DKIM: эти механизмы проверяют подлинность письма, а DMARC сопоставляет результат с доменом в поле «From» и публикует политику. Типичная ошибка в том, что компания включает DMARC сразу с p=reject, а на следующий день счета, уведомления о заказах с сайта и рассылки из CRM перестают доходить до клиентов. Поэтому внедрять DMARC нужно поэтапно, опираясь на отчёты.
Как устроена запись DMARC
DMARC — это обычная TXT-запись, но размещается она не на самом домене, а на поддомене _dmarc. Для домена example.uz имя записи будет _dmarc.example.uz. Внутри записи теги разделяются точкой с запятой, и у каждого своя задача. Главный тег — p, у него три значения: none означает только наблюдение, quarantine — отправку подозрительного письма в спам, а reject — полный отказ в приёме.
_dmarc.example.uz. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.uz; fo=1"Тег rua указывает адрес для агрегированных отчётов. Gmail, Yahoo и другие крупные провайдеры обычно присылают их раз в сутки в формате XML: там видно, с каких IP-адресов приходили письма от имени вашего домена, сколько их было, каковы результаты SPF и DKIM и есть ли выравнивание (alignment). Тег fo=1 касается подробных отчётов об ошибках, но многие провайдеры их вообще не отправляют, поэтому основная опора — агрегированные отчёты.
Этап 1: наблюдение с p=none
На первом этапе ни одно письмо не блокируется, вы только собираете данные. Цель — выявить все системы, которые отправляют почту от имени домена. Руководитель компании обычно знает только про корпоративную почту, но в отчётах внезапно обнаруживаются форма обратной связи на сайте, бухгалтерская программа, онлайн-касса, сервис рассылок и даже старый МФУ, отправляющий сканы.
Заведите для отчётов отдельный ящик: у активного домена их может приходить десятки в день. Читать XML вручную неудобно, поэтому удобнее пользоваться бесплатными или платными сервисами анализа DMARC, которые показывают данные в виде таблиц и графиков. Если отчёты должны приходить на адрес в другом домене, в этом домене нужна разрешающая запись, иначе провайдеры отчёты не отправят:
example.uz._report._dmarc.analytics-domen.uz. IN TXT "v=DMARC1"Наблюдайте минимум две–четыре недели. За это время в отчёты должны попасть и редкие письма: ежемесячные счета или квартальные рассылки.
Разбор отчётов и наведение порядка в источниках
Для каждого источника в отчёте ответьте на один вопрос: это легитимная отправка? Если да, письмо должно проходить SPF или DKIM с совпадением домена. Для DMARC достаточно, чтобы с выравниванием прошёл хотя бы один из механизмов. Например, сервис рассылок отправляет письмо со своего сервера и подписывает DKIM своим доменом: подпись проходит, но выравнивания нет, и DMARC фиксирует провал. Решение обычно в том, чтобы включить в настройках сервиса DKIM для своего домена и добавить в DNS выданную им CNAME- или TXT-запись.
| Источник | Типичная проблема | Решение |
|---|---|---|
| Корпоративная почта на хостинге | DKIM не включён | Включить DKIM в панели и добавить ключ в DNS |
| Форма на сайте | PHP mail() отправляет от имени чужого сервера | Перейти на отправку через SMTP с авторизацией |
| Сервис рассылок | DKIM подписан доменом сервиса | Настроить DKIM своего домена в сервисе |
| Неизвестные IP | Поддельные письма от имени домена | Ничего не делать: именно их и заблокирует DMARC |
Если в отчётах видны письма с незнакомых зарубежных IP, не пугайтесь: это и есть фишинг, который DMARC должен остановить. «Чинить» их не нужно, важно лишь убедиться, что все легитимные источники проходят проверку.
Этап 2: осторожный переход на quarantine с pct
Когда почти все легитимные источники проходят проверку, политику можно поднять до quarantine. Большинство получателей поддерживает тег pct, позволяющий применять политику лишь к части писем: начать с 25 процентов, понаблюдать неделю-две, затем перейти на 50 и 100. Учтите, что в новой редакции стандарта DMARC этот тег пересматривается, поэтому не полагайтесь на него полностью и продолжайте следить за отчётами.
_dmarc.example.uz. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.uz"На этом этапе полезно опросить сотрудников. Если кто-то говорит, что клиент нашёл его письмо в спаме, выясните, из какой системы оно ушло, и проверьте этот источник в отчёте. Чаще всего виноват забытый скрипт или старая настройка.
Этап 3: p=reject и поддомены
Если отчёты несколько недель стабильны и среди легитимных писем нет провалов, последний шаг — p=reject. Теперь поддельное письмо от имени вашего домена отклоняется сервером получателя и не попадает в ящик клиента. Тег sp задаёт отдельную политику для поддоменов. Строгая политика особенно полезна для поддоменов, которые почту не отправляют: мошенники любят правдоподобные имена вроде billing.example.uz.
_dmarc.example.uz. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.uz"После изменения проверьте запись. Команды ниже должны вернуть её текст; пустой результат означает, что DNS ещё не обновился или имя записи указано неверно:
dig +short TXT _dmarc.example.uz
nslookup -type=TXT _dmarc.example.uzПример: мебельный магазин в Ташкенте
Мебельный магазин в Ташкенте принимает заказы на сайте, менеджеры работают с корпоративной почты, раз в месяц уходит рассылка об акциях. Однажды клиенты получают от имени магазина фальшивое письмо «подтвердите оплату». Магазин начинает с p=none, и в первую же неделю в отчётах видны четыре источника: корпоративная почта, сайт, сервис рассылок и несколько зарубежных IP. Форму на сайте переводят на SMTP, в сервисе рассылок настраивают DKIM. Через месяц ставят quarantine, ещё через три недели — reject, и поддельные письма перестают доходить до клиентов.
На хостинге sayt.uz записи DKIM и SPF для корпоративной почты добавляются через раздел DNS в личном кабинете, а DMARC создаётся там же как обычная TXT-запись.
Частые ошибки
- Две записи DMARC на одном домене: получатели могут проигнорировать обе.
- Пропуск этапа наблюдения и сразу
rejectс потерей легитимных писем. - Адрес для отчётов указан, но их никто не читает, и
p=noneостаётся навсегда без реальной защиты. - Добавление в SPF всех сервисов подряд с превышением лимита в 10 DNS-запросов.
DMARC — не разовая настройка. При подключении новой CRM, сервиса рассылок или сервера в отчётах появится новый источник, и его тоже придётся настроить. Поэтому просматривайте отчёты периодически и после перехода на reject.