DMARC-запись (Domain-based Message Authentication, Reporting & Conformance)

Что такое DMARC-запись?

DMARC-запись (Domain—based Message Authentication,Reporting &Conformance) — это DNS-запись типа TXT, которая определяет, как почтовые серверы-получатели должны обрабатывать письма с вашего домена, не прошедшие проверку SPF или DKIM, и задаёт адрес для получения агрегированных отчётов о таких письмах.

С 2024 года Google, Yahoo, а с 2025 года Microsoft требуют наличия DMARC для всех массовых отправителей (более 5 000 писем в день). К 2026 году отраслевым стандартом стала политика p=reject для полной защиты от подделок, что снижает количество фишинговых писем с вашего домена на 90–95%. Рекомендуемый TTL для DMARC-записи — 3600 секунд (1 час), а политику внедряют поэтапно: сначала p=none (только мониторинг), затем p=quarantine, и финально p=reject.

Как это работает?

Почтовый сервер-получатель, получив письмо от вашего домена, сначала проверяет SPF и DKIM. Затем он ищет DMARC-запись для домена в DNS (по адресу _dmarc.ваш-домен). Если запись найдена, сервер сопоставляет результаты SPF и DKIM с доменом, указанным в заголовке From (видимый адрес отправителя). Если ни одна из проверок не пройдена (или есть несоответствие), сервер применяет политику, указанную в DMARC: none — без действий (только отчёт), quarantine — отправить в спам, reject — отклонить письмо полностью. Также DMARC включает механизм отправки отчётов (агрегированных и судебных) на указанный email-адрес, что позволяет администратору видеть, откуда идёт неаутентифицированный трафик.

Метрики и стандарты

• Политика (p) — обязательный параметр: p=none (только мониторинг), p=quarantine (спам), p=reject (отклонять). В 2026 году для коммерческих доменов рекомендуется p=reject.
• Процент отклонённых писем — при p=reject до 95% поддельных писем блокируются, что предотвращает репутационные и финансовые потери.
• Агрегированные отчёты (rua) — указываются через rua=mailto:адрес. Рекомендуется получать отчёты на специальный ящик (например, dmarc-reports@домен).
• Судебные отчёты (ruf) — опционально, содержат информацию о каждом неудавшемся письме; требуют осторожности из-за конфиденциальности.
• Процент (pct) — доля писем, к которым применяется политика (по умолчанию 100). Используется для поэтапного внедрения, но в финале должно быть 100.
• Поддомены (sp) — отдельная политика для поддоменов (по умолчанию наследуется от основной).
• TTL — стандартно 3600 с; при изменениях политики снижайте до 300 с заранее.

Почему это важно для бизнеса?

DMARC является завершающим звеном в цепочке аутентификации электронной почты (SPF + DKIM + DMARC). Без DMARC даже правильно настроенные SPF и DKIM не защищают от спуфинга видимого адреса «От», так как злоумышленники могут подменить именно это поле, оставляя корректным Return-Path. Результат — клиенты и партнёры получают фишинговые письма с вашим отображаемым именем, что наносит урон репутации и доверию. Кроме того, DMARC-отчёты дают прозрачность: вы видите все источники, которые отправляют письма от вашего домена, что позволяет обнаружить несанкционированные рассылки, утечки учётных данных или забытые старые сервисы. Внедрение DMARC с p=reject также повышает репутацию домена у почтовых провайдеров, улучшая доставляемость легитимных писем.

Пример применения

Сценарий: Банк «Надёжный» зафиксировал несколько жалоб клиентов на фишинговые письма с адреса info@nadezhny-bank.ru. Администратор проверяет: SPF и DKIM уже настроены, но DMARC отсутствует. Он создаёт запись _dmarc.nadezhny-bank.ru с содержимым v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@nadezhny-bank.ru; pct=100. Через неделю он анализирует отчёты и видит, что часть писем не проходит аутентификацию из-за старого маркетингового сервиса, который забыли обновить. Он исправляет SPF для этого сервиса, а затем переводит политику на p=reject. В результате поддельные письма блокируются, жалобы прекращаются, а доставляемость официальных писем улучшается на 15%.

Как это реализуется в WordPress?

DMARC-запись, как и другие DNS-записи, настраивается в панели управления DNS, а не внутри WordPress. Однако администратор WordPress-сайта должен понимать, что DMARC влияет на отправку писем с сайта, и координировать настройку с разработчиками или провайдером почты.

• НастройкаDNS: создайте запись типа TXT с именем _dmarc.ваш-домен (например, _dmarc.example.com) и значением, начинающимся с v=DMARC1;. Пример базовой записи: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; sp=reject; pct=100.
• ПлагиныWordPress не создают DMARC напрямую, но многие плагины для почты (например, WP Mail SMTP, Post SMTP) в своих инструкциях рекомендуют добавить DMARC и могут проверить его наличие через API.
• Мониторинг отчётов: после добавления записи настройте получение и анализ отчётов. Для этого можно использовать бесплатные сервисы (например, DMARC Analyzer, URIports, MxToolbox) или собственные скрипты для обработки XML-отчётов. В WordPress нет встроенных инструментов для этого, но можно настроить пересылку писем с отчётами на ящик и использовать внешние парсеры.
• Серверный уровень: веб-сервер (Nginx/LiteSpeed) не участвует в DMARC, но если на сервере установлен почтовый агент (Postfix), он должен корректно подписывать письма DKIM и иметь правильные SPF, чтобы письма проходили DMARC. Убедитесь, что исходящие письма с WordPress отправляются через SMTP-сервер, который поддерживает все три протокола.

Связанные понятия

• SPF (Sender Policy Framework) — определяет разрешённые IP-адреса отправителей; DMARC учитывает результат SPF вместе с DKIM.
• DKIM (DomainKeys Identified Mail) — добавляет криптографическую подпись; DMARC проверяет, совпадает ли подписанный домен с доменом в заголовке From.
• Агрегированные отчёты — регулярные (обычно ежедневные) отчёты в формате XML, содержащие статистику о прохождении аутентификации писем с вашего домена.
• Судебные отчёты — детальные отчёты о каждом письме, не прошедшем проверку; содержат заголовки письма, поэтому требуют соблюдения конфиденциальности.
• Политика поддоменов (sp) — отдельная политика для поддоменов, может быть строже или мягче основной.

Ошибки:

• Установка p=reject без предварительного анализа отчётов — можно заблокировать легитимные письма, если SPF или DKIM настроены не полностью. Начинайте с p=none и анализируйте отчёты не менее 2–4 недель.
• Указание неверного адреса для rua (например, с опечаткой) — отчёты не будут доставляться, и вы не сможете увидеть проблемных отправителей.
• Использование pct меньше 100 на постоянной основе — часть писем не будет проверяться, что создаёт дыру в безопасности; используйте pct=100 только после проверки.
• Игнорирование политики для поддоменов (sp) — поддомены могут оставаться незащищёнными; всегда указывайте sp=reject или наследуйте, если это уместно.
• Отсутствие обработки отчётов — данные будут накапливаться в почтовом ящике без анализа; внедрите автоматический парсинг или внешний сервис для мониторинга.