DMARC policy explained
dmarc policy · p=reject · email authentication
Understand p=, sp=, pct=, and how policy changes affect spoofed mail before you move from monitoring to enforcement.
Autor: DN01 Network Team
DMARC policy tells receivers what to do when SPF and DKIM alignment fail for the visible From domain. Analizator DMARC DN01 pobiera TXT _dmarc, parsuje tagi i podkreśla politykę oraz alignment przed enforcement. Operatorzy używają go przy migracjach, triage incydentów i onboardingu dostawców, gdy potrzebują powtarzalnych dowodów zamiast pojedynczych zrzutów ekranu.
A published TXT record at _dmarc.example.com is useless without aligned SPF or DKIM success paths for legitimate senders.
Run the DMARC Analyzer on your domain, read p= and pct= separately, and only tighten policy after aggregate reports look stable. Połącz wynik DMARC z walidatorami SPF i DKIM tej samej domeny, aby naprawiać uwierzytelnianie razem. Zapisz permalink wyniku w tickecie, odnotuj czas sprawdzenia i porównaj wynik przed i po zmianach konfiguracji lub aktualizacjach klienta.
Powtarzaj sprawdzenie po każdej istotnej zmianie i przechowuj link przewodnika w runbooku zespołu, aby nowi operatorzy stosowali tę samą kolejność diagnostyki.
Tagi podświetlane przez DN01
Polityka p= i subdomena sp= definiują działania odbiorców; pct= ogranicza, ile poczty obejmuje polityka podczas rolloutu.
Tryby aspf i adkim kontrolują dopasowanie relaxed lub strict między uwierzytelnionymi domenami a widocznym nagłówkiem From.
Błędy rolloutu
Publikowanie reject, gdy marketing lub ticketing wysyłają z DKIM dostawcy, psuje legalną pocztę w folderach spam.
Ignorowanie raportów agregowanych oznacza odkrycie niedopasowanych źródeł dopiero po skargach na brakujące potwierdzenia.
Bezpieczna ścieżka enforcement
Zacznij od p=none z rua, napraw alignment dla każdego zatwierdzonego nadawcy, potem quarantine przed reject.
Używaj pct<100 tylko jako tymczasowego mostu; udokumentuj docelową datę pełnego enforcement w runbooku poczty.
Dokumentacja i kolejne kroki
Archiwizuj wynik checkera w ticketach zmian, recenzjach dostawców i incydentach, aby kolejny operator widział te same przeanalizowane dowody.
Podlinkuj ten przewodnik i stronę narzędzia w wiki zespołu i łącz wyniki z innymi narzędziami DN01, gdy problem dotyczy DNS, poczty, TLS lub warstw bezpieczeństwa. Zapisz, kto uruchomił sprawdzenie, jakie dane wejściowe użyto i czy permalink wyniku trafił do zgłaszającego.
Kiedy eskalować lub łączyć sprawdzenia
Jeśli wynik Analizator DMARC nadal nie zgadza się ze zgłoszeniem użytkownika po restarcie lub wyczyszczeniu cache, zapisz znaczniki czasu, surowe dane wejściowe i permalink DN01 przed zmianą produkcyjnego DNS, poczty, TLS lub auth.
Eskaluj do właścicieli platformy lub tożsamości, gdy polityka firmowa blokuje poprawkę; w przeciwnym razie połącz ten przewodnik z sąsiednimi narzędziami DN01 DNS, poczty, TLS lub bezpieczeństwa, aby zamknąć pętlę w jednym tickecie.
| Polityka | Typowe użycie |
|---|---|
| p=none | Monitorowanie i zbieranie rua |
| p=quarantine | Łagodzenie błędów do spamu |
| p=reject | Blokada spoof po czystym alignment |
| pct<100 | Tylko stopniowe enforcement |
Najczęściej zadawane pytania
- Czy DMARC zastępuje SPF lub DKIM?
Nie. DMARC zależy od SPF i DKIM plus alignment z domeną From.
- Czy każda domena powinna używać p=reject?
Wiele domen wysyłających powinno, ale dopiero po raportach z wyrównaną legalną pocztą bez niespodzianek.
- Dlaczego pokazywać pct osobno?
reject z pct=20 to nie pełne enforcement. DN01 pokazuje pct, by nie przeceniać ochrony.
- Czy mogę udostępnić wyniki zespołowi?
Tak. Skopiuj wynik DN01 lub permalink do ticketu, aby wszyscy widzieli te same przeanalizowane dowody zamiast pojedynczych zrzutów ekranu.