Политика поддоменов DMARC sp=
dmarc sp tag · subdomain dmarc policy · sp=reject
Когда sp= важен для mail.example.com, как наследуется от p= и почему отдельные subdomain senders требуют явного alignment.
Автор: DN01 Network Team
Тег sp= задаёт политику для organizational subdomains, когда From использует поддомен DMARC-домена. DN01 DMARC Analyzer получает TXT _dmarc, разбирает теги и подсвечивает policy и alignment до включения enforcement. Операторы используют его при миграциях, разборе инцидентов и onboarding вендоров, когда нужны повторяемые доказательства вместо разовых скриншотов.
Marketing-платформы, support и product mailers часто шлют с поддоменов, которые не наследуют родительскую политику, как вы ожидали.
Проверьте sp= в DN01 рядом с p=, перечислите все активные subdomain senders и опубликуйте aligned SPF или DKIM для каждого до ужесточения enforcement. Сочетайте вывод DMARC со SPF и DKIM validators для того же домена, чтобы исправления authentication шли вместе. Сохраняйте permalink результата в тикете, фиксируйте время проверки и сравнивайте вывод до и после изменения конфигурации или обновления клиента.
Повторяйте проверку после каждого значимого изменения и храните ссылку на guide в runbook команды, чтобы новые операторы следовали тому же порядку диагностики.
Теги, которые подсвечивает DN01
Policy p= и subdomain sp= задают действия получателей; pct= ограничивает долю почты под политикой во время rollout.
Режимы aspf и adkim определяют relaxed или strict matching между authenticated domains и видимым From header.
Ошибки rollout
Публикация reject, пока marketing или ticketing шлют с vendor DKIM, ломает легитимную почту через spam folders.
Игнорирование aggregate reports означает, что misaligned источники обнаруживаются только после жалоб на пропавшие квитанции.
Безопасный путь enforcement
Начните с p=none и rua, исправьте alignment для каждого approved sender, затем quarantine и только потом reject.
Используйте pct<100 лишь как временный мост; зафиксируйте дату полного enforcement в mail operations runbook.
Документация и следующие шаги
Сохраняйте вывод checker в change tickets, vendor review и инцидентах, чтобы следующий оператор видел те же parsed-данные, а не только скриншот.
Добавьте ссылку на этот guide и landing инструмента в wiki команды и сочетайте результат с другими утилитами DN01, если проблема затрагивает DNS, почту, TLS или security. Укажите, кто запускал проверку, какой input использовался и был ли permalink результата передан заявителю.
Когда эскалировать или комбинировать проверки
Если вывод DMARC Analyzer всё ещё расходится с отчётом пользователя после restart или очистки кэша, зафиксируйте timestamps, raw inputs и permalink DN01 до изменений production DNS, почты, TLS или auth.
Эскалируйте platform или identity owners, когда enterprise policy блокирует fix; иначе сочетайте guide с соседними DNS, mail, TLS или security утилитами DN01, чтобы закрыть цикл в одном тикете.
| Политика | Типичное применение |
|---|---|
| p=none | Мониторинг и сбор rua |
| p=quarantine | Смягчение failures в spam |
| p=reject | Блок spoofed после чистого alignment |
| pct<100 | Только постепенный enforcement |
Частые вопросы
- DMARC заменяет SPF или DKIM?
Нет. DMARC зависит от результатов SPF и DKIM плюс alignment с From-доменом.
- Каждому домену нужен p=reject?
Многим отправляющим доменам да, но только после отчётов с aligned легитимной почтой и без сюрпризов по источникам.
- Зачем показывать pct отдельно?
reject с pct=20 — не полный enforcement. DN01 показывает pct, чтобы операторы не переоценивали защиту.
- Можно ли делиться результатами с командой?
Да. Скопируйте вывод DN01 или permalink в тикет, чтобы все смотрели на одни и те же parsed-данные, а не на отдельные скриншоты.