DMARC RUA задаёт в записи DMARC адрес для агрегированных отчётов от участвующих получателей. Без него теряется важная обратная связь об аутентификации и неизвестных источниках, но даже с отчётами охват остаётся неполным. Для основ доменной почты начните с материала о почте для малого бизнеса.
Неверная настройка CRM, забытый плагин WordPress или ошибка SPF при пересылке затрудняют поиск причины. RUA делает часть такого трафика видимой, чтобы вы могли проверять конфигурацию по данным, а не предположениям.
Здесь разобраны тег RUA, публикация в DNS, смысл XML-отчётов и порядок исправления проблем.
Что такое DMARC RUA?
RUA указывает адреса для агрегированных отчётов об аутентификации. Они обобщают SPF, DKIM, выравнивание, IP отправки и обработку DMARC за период, часто ежедневно, но только для трафика, наблюдаемого получателями, присылающими отчёты.
В записи DMARC rua=mailto:... означает запрос агрегированных отчётов на этот адрес. Согласно RFC 7489, тег rua задаёт адреса для отправки отчётов. Отчёты содержат результаты аутентификации, выравнивание, домены, количество сообщений и применённую обработку.
Для ввода ограничений нужны подтверждённые данные. Выбирать p=none, p=quarantine или p=reject следует по отчётам, списку отправляющих систем и реальным тестам. RUA сам по себе не доказывает полную готовность.
Что на самом деле показывают отчёты RUA
Это агрегированные сводки, а не копии отдельных писем. Они показывают наблюдаемые источники, исходные результаты SPF и DKIM и важное для DMARC выравнивание доменов. Раздел auth_results содержит исходные проверки, policy_evaluated оценивает их с выравниванием для DMARC.
Отчёты полезны для регулярной эксплуатационной проверки. Тела сообщений в них нет, но можно получить признаки ошибок сервисов, возможных подделок и проблем выравнивания.
| Тег | Задача | Содержимое | Применение |
|---|---|---|---|
rua | Запрашивает агрегированные отчёты | XML-сводки по IP и результатам проверки | Регулярное наблюдение и ввод политики |
ruf | Запрашивает отчёты об ошибках | Детали отдельных ошибок при поддержке получателем | Дополнительная целевая диагностика |
Обычно стоит начать с RUA. ruf используйте при конкретной необходимости: поддержка ограничена, а подробные отчёты требуют внимания к приватности.
Пример: домен отправляет через Google Workspace, приложение выставления счетов и поддержку. Отчёты могут показать эти источники, если их видят участвующие получатели. Ошибка выравнивания поддержки требует проверки. Но неизвестный источник или другая страна сами по себе не доказывают подделку.
Как опубликовать адрес RUA в DNS
Создайте TXT под _dmarc.yourdomain.com с действительным адресом rua=mailto:. Если отправители ещё не проверены, начните с наблюдения, а не немедленных ограничений.
Следующий пример использует необязательное строгое выравнивание, которое не является подходящим стандартом для всех доменов:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"Более простой альтернативный вариант без строгого выравнивания выглядит так. Не публикуйте обе записи одновременно:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Выделите отдельный ящик или сервис анализа, чтобы сжатые XML-вложения не мешали обычной работе поддержки.
Настройку объясняют обязательные записи DNS TrekMail. Встроенная проверка SPF, DKIM и DMARC может обнаружить ошибки DNS, но не заменяет тестирование реальных писем всех отправителей.
Как проверить запись RUA
Запросите DNS напрямую, затем проверьте поступление отчётов. Ошибка записи может сделать адрес недоступным для отчётности, но отсутствие данных также бывает связано с неучаствующими получателями или недостающей авторизацией.
Используйте dig или nslookup:
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comОтвет должен содержать опубликованную запись DMARC. В RFC 7489 описан, например, такой корректный формат:
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"Отчёты часто приходят ежедневно, но сроки и участие различаются. Ожидание без данных не доказывает ни правильность DNS, ни отсутствие трафика.
Как последовательно читать отчёт RUA
В XML найдите источник, проверьте SPF и DKIM, затем выравнивание и обработку. Для DMARC хотя бы один механизм должен одновременно пройти проверку и обеспечить выравнивание.
Возможный порядок:
- Изучите IP и обратный DNS, сравните с вашими системами. Само имя PTR не удостоверяет источник.
- Сравните объём: 2 сообщения и 20,000 сообщений различаются масштабом, но и малый источник может быть критичен для бизнеса.
- Проверьте SPF, DKIM и выравнивание. Успешная проверка без выравнивания недостаточна, если нет другого успешного выровненного пути.
- Изучите обработку:
noneне доказывает конкретную доставку или только наблюдение;quarantineне задаёт гарантированную папку;rejectне гарантирует блокировку без исключений. - Классифицируйте источник как законный, ошибочно настроенный, подозрительный или пока неизвестный.
Google требует SPF или DKIM для обычной прямой отправки в личные ящики Gmail. Массовым отправителям нужны оба механизма и DMARC с выравниванием хотя бы одного успешного пути к домену заголовка From:. RUA помогает увидеть ошибки реального выравнивания, но не гарантирует попадание во входящие.
Три важных вида проблем в отчётах RUA
Типичные направления проверки: законные отправители без нужной аутентификации, ошибки SPF при пересылке и возможная подделка. Используйте дополнительные сведения до принятия мер.
1. Законный отправитель, неверная настройка
Известный сервис отправляет вашим доменом, но нет нужного SPF или выровненного DKIM. Для DMARC достаточно успешного выровненного SPF либо DKIM; отсутствие DKIM всё же может сказаться при пересылке. Сначала исправьте источник.
При собственном отправителе настройте DNS по фактическому пути. См. собственный SMTP. Для управляемой отправки в соответствующих платных тарифах Managed TrekMail SMTP поясняет настройку и подпись.
2. SPF не проходит из-за пересылки
Новый IP может нарушить SPF без подделки сообщения. DKIM может сохраниться, если подписанные данные остаются неизменными с учётом каноникализации. При успешном выровненном DKIM DMARC проходит. Проверяйте конкретный путь вместо автоматического игнорирования любых ошибок SPF.
Полезны настройка пересылки почты и пересылка доменной почты в Gmail. SPF fail и DMARC fail являются разными результатами.
3. Неизвестный источник, возможная подделка
Неизвестный IP может принадлежать неучтённому сервису, общему ретранслятору, пересылке или злоумышленнику. Не добавляйте его в SPF или список разрешений без проверки. Ужесточайте политику после подтверждения настройки законных источников.
Стоит ли направлять RUA стороннему сервису?
Внешний сервис может упростить разбор XML. Но важно проверить требования DNS и обращение с данными. Для внешнего адреса нужна авторизация, которую некоторые получатели проверяют перед отправкой.
RFC 7489 описывает для адреса rua вне организационного домена подтверждающую запись в DNS домена назначения, например:
example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"Без подтверждения создатели отчётов могут игнорировать внешний адрес. Выполните точные указания анализатора и проверьте авторизацию на стороне назначения.
Когда переходить с p=none на quarantine или reject
Перед сменой политики используйте отчёты, учёт систем и тесты. Необъяснённая ошибка не обязательно означает подделку. Строгую обработку стоит запрашивать после достаточной проверки законных процессов.
Возможный порядок:
- Опубликуйте RUA с
p=none. - Наблюдайте отчёты, например, от 1 до 2 недель, отдельно проверяя редкие циклы отправки.
- Обеспечьте каждому законному отправителю успешный выровненный SPF или DKIM.
- После проверки рассмотрите
p=quarantine. p=rejectрассматривайте после тестирования критичных писем и анализа оставшихся ошибок.
Без наблюдения и тестов пропущенную настройку первым может обнаружить клиент. Предусмотрите проверки и действия при ошибках законных сообщений.
Общий процесс эксплуатации RUA
XML можно анализировать вручную или передать сервису обработки. Единые процедуры DNS и общая панель помогают работать с доменами, ящиками, миграцией и отправкой, но сами по себе не интерпретируют отчёты.
| Разрозненный подход | Общий процесс с TrekMail |
|---|---|
| Разные процедуры SPF, DKIM и DMARC для каждого домена | Общая панель DNS доменов и почтовых ящиков |
| Неясно, какой отправитель нарушил выравнивание | Процесс настройки DNS и документация диагностики |
| Проблемы пересылки объясняют только SPF | Совместная проверка DMARC, DKIM и реальных путей пересылки |
| Оплата за пользователя усложняет расчёт нескольких доменов | Тарифная модель с ориентиром от $3.50/месяц и общим хранилищем без оплаты за каждого пользователя |
TrekMail не является анализатором DMARC. В зависимости от тарифа доступны собственные домены, ящики IMAP, catch-all, пересылка, миграция IMAP и собственный либо управляемый SMTP. Это может упростить инфраструктуру, но не заменяет анализ данных отчёта.
Платные тарифы предлагаются от $3.50/месяц. Nano предлагается бесплатно без карты. Платные тарифы могут предоставлять 14-дневный пробный период с обязательной кредитной картой. Уточните текущие цены, функции и условия.
Итог: RUA создаёт обратную связь
RUA может показать ошибки отправителей, последствия пересылки и возможные подделки. Это ценное дополнение к проверке, но не полный вывод о готовности домена ко всем этапам ограничений.
Для одного домена, пятидесяти или пятисот полезны регулярный анализ и актуальный список отправляющих систем. Настройте RUA, читайте данные и тестируйте законные источники до ужесточения политики.
TrekMail предлагает хостинг нескольких доменов с фиксированной оплатой и общим хранилищем, создание ящиков по приглашению и миграцию IMAP, если выбранный тариф предусматривает эти функции. Начало работы и актуальные условия доступны на trekmail.net.
