Настраиваем политику DMARC для защиты рабочей почты

DMARC закрывает именно этот разрыв. Он связывает SPF и DKIM с доменом в видимом From, задает политику обработки отказов и дает отчеты. Вопрос не в том, «включить ли DMARC». Вопрос — как проверить, настраиваем политику DMARC для защиты рабочей почты корректно или просто публикуем TXT-запись, которая ничего не защищает.

Фундамент: SPF и DKIM должны работать до DMARC

DMARC не является отдельной проверкой отправителя. Он опирается на два механизма: SPF и DKIM. Без них политика превращается в декоративную запись DNS.

SPF проверяет, имеет ли IP-адрес отправляющего сервера право отправлять почту от имени домена в SMTP envelope. DKIM проверяет криптографическую подпись письма. DMARC добавляет главное условие: выравнивание доменов. Проверяется связь между доменом в видимом From и доменом, прошедшим SPF или DKIM.

Минимальная логика такая:

1. В письме есть From: `user@example.com`.

2. Получающий MTA проверяет SPF для домена из envelope sender.

3. Получающий MTA проверяет DKIM-подпись и домен `d=`.

4. DMARC смотрит, совпадает ли домен From с доменом SPF или DKIM в допустимом режиме выравнивания.

5. Если хотя бы один механизм прошел проверку и выравнивание — DMARC pass.

6. Если оба механизма не прошли или не выровнены — применяется политика `p=`.

Это важнее, чем сама строка `_dmarc`. Большая часть поломок начинается не в DMARC, а ниже: неверный SPF, отсутствующий DKIM на одном из сервисов рассылки, пересылка без SRS, сторонний Helpdesk, CRM или биллинг, который отправляет письма от корпоративного домена без подписи.

Проверьте источники исходящей почты до публикации строгой политики. Не по памяти. По логам MTA, по заголовкам реальных писем, по отчетам провайдера, по списку SaaS-сервисов.

Типовые источники:

• основной почтовый сервер организации;

• облачная почта;

• сервис транзакционных писем;

• CRM;

• Helpdesk;

• система мониторинга;

• бухгалтерская платформа;

• маркетинговая платформа;

• сайты и формы обратной связи;

• внутренние приложения, отправляющие через SMTP relay.

Если сервис отправляет письмо с From корпоративного домена, он должен быть закрыт SPF и/или DKIM. Лучше DKIM. SPF ломается при пересылке. DKIM переживает пересылку, если тело и подписанные заголовки не модифицированы.

DMARC не исправляет SPF и DKIM. Он делает их ошибки видимыми и дорогими.

Для доменов, связанных с платежами, доступами и финансовыми уведомлениями, цена ошибки выше. В смежных системах, включая цифровой банкинг и финтех-инфраструктуру, доверие к домену отправителя часто является частью антифрод-контроля. Почтовая аутентификация там не украшение, а базовый слой.

DNS-запись DMARC: структура без лишних тегов

Политика DMARC публикуется в DNS как TXT-запись с именем `_dmarc.example.com`. Для домена `example.com` имя записи будет именно `_dmarc.example.com`, а не `example.com`.

Минимальная запись для старта:

`v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com`

Разбор:

Запись должна быть одной TXT-записью для `_dmarc`. Не публикуйте две политики одновременно. Получающие MTA могут трактовать это как ошибку и игнорировать DMARC.

Пример стартовой записи:

`_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"`

Пример политики карантина:

`_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com"`

Пример строгой политики:

`_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com"`

Не начинайте с `p=reject`, если домен уже используется для рабочей почты. Это прямой способ заблокировать легитимные уведомления. Сначала собирайте агрегированные отчеты через `rua`. Срок зависит от объема трафика и состава отправителей. Универсального числа нет. Для малого домена достаточно увидеть полный цикл бизнес-процессов. Для крупной организации нужны данные по всем подразделениям, регионам и сервисам.

Что делать с `rua`

`rua` указывает адрес для агрегированных отчетов. Это XML-отчеты от принимающих систем. Они показывают:

• кто отправлял письма от имени домена;

• какие IP участвовали в отправке;

• прошли ли SPF и DKIM;

• было ли выравнивание;

• какая политика была применена;

• сколько сообщений попало в конкретный результат.

Создайте отдельный ящик. Не используйте личный адрес администратора. Отчеты объемные. Их нужно парсить, хранить и анализировать.

Нормальная схема:

1. Создайте `dmarc-agg@example.com`.

2. Ограничьте доступ к ящику.

3. Настройте разбор XML через выбранный инструмент.

4. Отмечайте легитимные источники.

5. Отдельно фиксируйте неизвестные IP и сервисы.

6. Не меняйте политику, пока не классифицирован основной поток.

Если отчеты приходят на внешний домен, потребуется подтверждение приема отчетов со стороны этого домена. Иначе часть провайдеров не будет отправлять данные. Это защита от злоупотреблений.

Что делать с `ruf`

`ruf` предназначен для forensic-отчетов о сбоях. На практике он менее предсказуем. Поддержка зависит от принимающей стороны. Содержимое может затрагивать данные писем. В корпоративной среде включайте `ruf` только после согласования с политикой обработки данных.

Для большинства внедрений достаточно `rua`. Он дает картину по источникам и отказам. Этого достаточно для перехода от мониторинга к строгой политике.

Стратегия внедрения: от `p=none` к `p=reject`

DMARC нужно вводить ступенчато. Это не вопрос осторожности. Это вопрос сохранения доставки легитимной почты.

Три режима работают по-разному:

Стартовая запись с `p=none` не защищает домен от спуфинга на уровне блокировки. Но она запускает телеметрию. Это ее функция. Ошибка — оставить домен в `p=none` навсегда и считать задачу выполненной.

Порядок внедрения:

1. Опубликуйте SPF для всех разрешенных отправителей.

2. Включите DKIM на основном почтовом сервисе.

3. Включите DKIM на SaaS-сервисах, которые отправляют от домена.

4. Опубликуйте DMARC с `p=none` и `rua`.

5. Соберите отчеты.

6. Сопоставьте IP и домены с реальными системами.

7. Устраните источники с DMARC fail.

8. Перейдите на `p=quarantine`.

9. Продолжайте анализ отчетов.

10. Перейдите на `p=reject`, когда легитимные источники стабильно проходят проверку.

Не переносите в SPF все подряд. Лимит DNS lookup у SPF жесткий. Перегруженная SPF-запись ломает проверку. Если сторонний сервис поддерживает DKIM, используйте DKIM. SPF должен описывать инфраструктуру, а не быть мусорным списком всех подряд платформ.

Строгая политика без инвентаризации отправителей — не защита. Это отказоустойчивость, сломанная через DNS.

Выравнивание доменов

DMARC требует выравнивания. Это отдельная проверка, которую часто пропускают.

Пример нормальной ситуации:

• From: `user@example.com`

• DKIM: `d=example.com`

• DKIM pass

• DMARC pass

Пример проблемной ситуации:

• From: `user@example.com`

• DKIM: `d=mailer.example-cdn.net`

• DKIM pass

• SPF pass для технического домена сервиса

• DMARC fail, если нет выравнивания с `example.com`

Сервис может честно подписывать письмо своим доменом. Но для DMARC это не подтверждает право использовать видимый From вашей организации. Настройте DKIM с доменом компании или делегированным поддоменом.

Для массовых рассылок лучше использовать отдельный поддомен: `news.example.com`, `mail.example.com`, `notify.example.com`. Это снижает риск влияния маркетингового трафика на репутацию основного домена. Но политика поддоменов должна быть управляемой.

В DMARC существует отдельный тег для поддоменов — `sp`. Если он не задан, поддомены наследуют основную политику. Вводите его осознанно. Если организация активно использует поддомены для отправки, сначала соберите данные по ним.

Анализ отчетов: что считать ошибкой, а что атакой

Агрегированные отчеты DMARC не предназначены для чтения глазами в почтовом клиенте. Это XML. Нужен парсер. Но логика анализа должна быть понятна инженеру, иначе инструмент будет только рисовать графики.

Разделяйте события на четыре класса.

1. Легитимный источник, SPF/DKIM pass, DMARC pass

Это нормальный поток. Зафиксируйте источник. Проверьте, какой механизм дает pass. Если проходит только SPF, а DKIM отсутствует, это слабое место. Включите DKIM. Пересылка может сломать SPF.

2. Легитимный источник, SPF/DKIM pass, DMARC fail

Обычно проблема в выравнивании. Сервис отправляет от вашего From, но SPF или DKIM проходят для чужого технического домена. Исправление: настроить кастомный DKIM-домен или изменить envelope sender на выровненный домен.

3. Легитимный источник, SPF fail, DKIM fail

Это не готово к строгой политике. Частые причины:

• новый SaaS-сервис подключили без согласования с почтовой инфраструктурой;

• сайт отправляет письма напрямую с веб-сервера;

• CRM использует общий SMTP без DKIM;

• у сервиса изменились IP, а SPF не обновлен через include;

• DKIM-ключ не опубликован или опубликован с ошибкой;

• письмо модифицируется шлюзом после подписи DKIM.

Такие источники нужно исправлять до `p=reject`.

4. Неизвестный источник, DMARC fail

Это потенциальный спуфинг. Не добавляйте IP в SPF без проверки владельца и назначения. Сначала определите ASN, обратную зону, заголовки доступных образцов, географию, объем. Если источник не принадлежит инфраструктуре организации и не связан с подрядчиком, он должен остаться под блокировкой будущей политики.

При `p=none` эти письма могут доставляться. При `p=quarantine` часть уйдет в спам. При `p=reject` они должны быть отклонены. Это цель внедрения.

Типовые ошибки при внедрении

DMARC ломают не сложные атаки. Его ломают административные упрощения.

Публикация политики без SPF и DKIM

Запись `_dmarc` есть. SPF неполный. DKIM отсутствует у половины отправителей. Результат: отчеты показывают мусор, переход на строгую политику невозможен. Исправление: сначала привести отправителей к аутентификации.

Немедленный `p=reject`

Это допустимо только для нового домена без легитимного трафика или для домена, по которому уже собрана полная картина отправки. Для рабочего домена — риск отказа уведомлений, счетов, тикетов, сбросов пароля и внутренних системных писем.

Одна SPF-запись на все случаи

SPF с десятком `include` быстро упирается в ограничение DNS-запросов. Часть проверок начинает возвращать permerror. Получающий MTA не обязан быть снисходительным. Уберите лишнее. Переведите сервисы на DKIM. Разделите потоки по поддоменам.

Отсутствие владельца отчетов

`rua` настроен, но отчеты никто не читает. Через три месяца домен все еще в `p=none`. Это не внедрение. Назначьте владельца процесса. Отчеты должны попадать в систему, где видны изменения по источникам и отказам.

Смешивание корпоративной и маркетинговой отправки

Основной домен используется для всего: переписка сотрудников, рассылки, формы сайта, акции, транзакционные письма. Репутация смешивается. Разбор отчетов усложняется. Используйте поддомены. У каждого потока должен быть понятный владелец и своя аутентификация.

Игнорирование пересылки

SPF часто не проходит при пересылке. Это нормально для архитектуры SPF. Поэтому DKIM обязателен. Если DKIM стабильно проходит и выровнен, DMARC пройдет даже при SPF fail. Не стройте защиту только на SPF.

Практическая схема проверки перед ужесточением политики

Перед переходом на `p=quarantine` или `p=reject` выполните техническую проверку. Не по интерфейсу DNS-панели. Проверяйте снаружи.

1. Проверьте наличие DMARC-записи для корневого домена. Запрос должен возвращать одну TXT-запись с `v=DMARC1`.

2. Проверьте SPF. У домена должна быть одна корректная SPF-запись. Несколько SPF-записей — ошибка.

3. Проверьте DKIM-селекторы для всех отправителей. Не только основной почтовый сервис.

4. Отправьте тестовые письма на внешние ящики и изучите заголовки Authentication-Results.

5. Сравните домен From с DKIM `d=` и SPF-доменом.

6. Откройте агрегированные отчеты за период наблюдения.

7. Найдите все источники с объемом больше единичного шума.

8. Классифицируйте неизвестные IP.

9. Исправьте легитимные источники с DMARC fail.

10. Только после этого меняйте `p=`.

Для рабочего домена нормальная зрелая запись может выглядеть так:

`v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com`

Если нужны промежуточные режимы, используйте `pct`. Он позволяет применять политику к части сообщений. Но не используйте его вместо анализа. Это вспомогательный механизм, а не защита от ошибок конфигурации.

Пример промежуточного варианта:

`v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-agg@example.com`

Смысл: политика карантина применяется не ко всему потоку. Но поведение принимающих систем может отличаться. Поэтому отчеты все равно являются основным источником контроля.

Что считать готовностью к `p=reject`

Переход к `p=reject` допустим, когда выполнены условия:

• все известные легитимные источники проходят DMARC;

• DKIM включен на основных потоках;

• SPF не возвращает permerror;

• маркетинговые и транзакционные сервисы подписывают письма выровненным доменом;

• отчеты `rua` обрабатываются регулярно;

• неизвестные источники классифицированы как нелегитимные или низкорисковые;

• владелец домена понимает последствия блокировки;

• есть процедура подключения новых отправителей.

Последний пункт критичен. DMARC ломается после внедрения, когда бизнес подключает новый сервис и начинает отправлять от домена без DKIM. Запретите такие подключения без почтовой проверки. Для внутренних команд это должно быть правилом изменения инфраструктуры.

Новый отправитель должен пройти короткую процедуру:

1. определить домен или поддомен отправки;

2. включить DKIM;

3. проверить SPF, если сервис требует envelope sender;

4. отправить тест на внешний ящик;

5. подтвердить DMARC pass в заголовках;

6. проверить появление источника в `rua`;

7. только потом включать продуктивную отправку.

Это дешевле, чем разбирать недоставленные счета и уведомления после изменения DNS.

Финальная проверка и базовые команды

DMARC — не галочка в DNS. Это контур контроля отправителей. Сначала SPF и DKIM. Затем `p=none` и отчеты. Затем исправление легитимных источников. Затем `quarantine`. Затем `reject`. Другого безопасного порядка для рабочего домена нет.

Минимальный набор проверок с консоли:

• `dig TXT _dmarc.example.com` — проверьте DMARC-запись.

• `dig TXT example.com` — проверьте SPF-запись домена.

• `dig TXT selector._domainkey.example.com` — проверьте DKIM-ключ по селектору.

• `nslookup -type=TXT _dmarc.example.com` — альтернативная проверка TXT.

• `host -t TXT _dmarc.example.com` — быстрый вывод TXT-записи.

• `dig -x 192.0.2.10` — проверьте PTR для отправляющего IP.

• `grep -i "Authentication-Results" message.eml` — проверьте результаты SPF, DKIM и DMARC в сохраненном письме.

• `grep -i "dmarc=pass" message.eml` — подтвердите успешное прохождение DMARC.

• `grep -i "dkim=pass" message.eml` — подтвердите DKIM.

• `grep -i "spf=pass" message.eml` — подтвердите SPF.

Если после этих проверок домен остается в `p=none`, защиты от спуфинга на уровне политики нет. Есть только наблюдение. Рабочее состояние для домена, который используется в корпоративной переписке, — контролируемый `p=reject` с работающими отчетами и процедурой подключения новых отправителей.