DMARC alignment с SPF и DKIM
dmarc alignment · spf dkim dmarc · email deliverability
Почему валидный SPF или DKIM всё равно может не пройти DMARC при несовпадении envelope, From и signing domains.
Автор: DN01 Network Team
DMARC проверяет, совпадает ли прошедшая SPF или DKIM идентичность с доменом, видимым получателю, а не просто статус pass. DN01 DMARC Analyzer получает TXT _dmarc, разбирает теги и подсвечивает policy и alignment до включения enforcement. Операторы используют его при миграциях, разборе инцидентов и onboarding вендоров, когда нужны повторяемые доказательства вместо разовых скриншотов.
Forwarding часто ломает SPF, поэтому команды опираются на DKIM alignment с From-доменом клиента.
Читайте в DN01 aspf, adkim и режимы alignment, затем исправьте signing domains или envelope senders до quarantine или reject. Сочетайте вывод 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-данные, а не на отдельные скриншоты.