DMARC none to reject migration
dmarc reject migration · dmarc enforcement · dmarc rollout
A staged rollout using reports, pct= sampling, and alignment fixes before full spoofing protection.
Autor: DN01 Network Team
Jumping straight to p=reject without aligned legitimate mail causes false positives that block invoices, password resets, and product notifications. 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.
Healthy rollouts fix envelope and DKIM signing paths, monitor rua for two to four weeks, then raise pct= in steps while watching bounce and spam-folder rates.
Document each policy change in change management, re-run the DMARC Analyzer after every TXT edit, and keep p=none rollback ready until metrics stabilize. 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.