A DMARC Polityka powinna odzwierciedlać to, co robi domena i co organizacja może ustalić na temat swojej poczty. Ściśle kontrolowana domena powiadomień, domena korespondencji pracowniczej i domena, która nic nie wysyła, mogą wymagać odmiennych decyzji.
Zacznij od celu domeny i legalnych tras. Następnie oceń konsekwencje żądanej polityki, dostępne dowody na jej poparcie oraz zachowania odbiorcy, na które nie masz wpływu.
Zanim wybierzesz polisę, opisz domenę
Odniesienia do protokołu: RFC 5321 §5.1. Poniższe operacyjne listy kontrolne i decyzje stanowią wskazówki redakcyjne.
Rejestruj, czy domena wysyła korespondencję pracowniczą, wiadomości transakcyjne, kampanie lub nie wysyła autoryzowanej poczty. Uwzględnij subdomeny, nabyte systemy i usługi zakupione poza centralnym IT.
Jakiś Rekord MX opisuje trasę odbiorczą. Nie inwentaryzuje każdego systemu, który może korzystać z domeny w lokalizacji From. Podobnie brak skrzynek pocztowych nie oznacza, że żadna aplikacja nie wysyła powiadomień.
Nadaj każdej trasie materiału cel biznesowy i właściciela. Nieznane źródło pozostaje nieznane, dopóki nie zostanie zbadane. Znana nazwa dostawcy lub duża sieć w chmurze nie są wystarczającym dowodem zatwierdzenia.
Określ, co oznacza żądana polityka
Odniesienia do protokołu: RFC 9989 §4.7, RFC 9989 §5.4. Poniższe operacyjne listy kontrolne i decyzje stanowią wskazówki redakcyjne.
Polityka informuje o ocenie właściciela wiadomości, które nie spełniają wymagań DMARC . Nie konfiguruje uwierzytelniania nadawcy ani nie określa ostatecznej akcji każdego odbiorcy.
- Polityka: brak; Kontekst decyzji: Właściciel nie wyraża preferencji dotyczących postępowania w przypadku awarii
- Polityka: kwarantanna; Kontekst decyzji: W ocenie właściciela nieprawidłowe użycie jest traktowane jako podejrzane
- Polityka: odrzucić; Kontekst decyzji: Właściciel uważa nieprawidłowe użycie za nieważne
Odbiorca nadal łączy uwierzytelnianie i zasady z własnymi decyzjami dotyczącymi obsługi. Etykieta panelu kontrolnego lub opublikowany ciąg DNS nie potwierdzają, że każda wiadomość, która zakończyła się niepowodzeniem, została odrzucona lub że przekazywane wiadomości dotarły do skrzynki odbiorczej.
Przed zmianą oddziel wybór zasad od naprawy legalnych nadawców, którzy nie wysyłają wiadomości. Poruszający rekord pomiędzy tymi wartościami nie może stworzyć wyrównanie dla aplikacji korzystającej z niepowiązanej tożsamości.
Oceń legalne trasy, które mogą zostać zakłócone
Odniesienia do protokołu: RFC 9989 §7.4. Poniższe operacyjne listy kontrolne i decyzje stanowią wskazówki redakcyjne.
Testuj usługi o znaczeniu krytycznym, w tym zdarzenia o małej objętości, takie jak płace, resetowanie i odnawianie haseł. Korzystaj z rzeczywistych przepływów pracy aplikacji i sprawdzaj otrzymane wyniki po bramkach lub pośrednikach.
Korespondencja o charakterze ogólnym wymaga szczególnej ostrożności. Aktualny RFC 9989 ostrzega przed odrzucaniem takich domen i wyjaśnia problemy ze współdziałaniem list mailingowych. Jej wytyczne dotyczące domen, których użytkownicy publikują posty na listach, obejmują szczegółowe obserwacje, porównania i rozważania dotyczące polityki użytkownika.
Przeczytaj wytyczne dotyczące odpowiedniego przypadku. Nie zastępuj go automatyczną progresją siedmiodniową lub trzydziestodniową obowiązującą dla każdej domeny.
Porównaj dwa różne cele domeny
To jest syntetyczny przykład planowania.
Dedykowana domena paragonów ma jedną zatwierdzoną aplikację, która jest utrzymywana DKIM konfiguracji i braku korespondencji personelu. Jego operator może testować reprezentatywne przepływy pracy związane z paragonami, monitorować awarie i definiować zmiany o określonym zakresie.
Domena staff obsługuje konwersacje, adresy ról i internetowe listy mailingowe. Test bezpośredniej poczty pracowniczej obejmuje tylko część tej czynności. Przegląd polityki wymaga dowodów dotyczących tras pośrednich i wpływu na użytkowników.
Różnica nie polega na tym, że jeden zespół bardziej ceni bezpieczeństwo. Domeny mają różne uzasadnione zastosowania i różne konsekwencje, gdy odbiorca podejmie działania w przypadku awarii.
Określ dowody i warunki odzyskiwania
Przygotuj zapis decyzji zawierający zakres domeny, zamierzoną politykę, przetestowane legalne usługi, nierozwiązane trasy, odpowiednie ograniczenia raportowania, osobę zatwierdzającą i plan weryfikacji.
Zdecyduj, co spowodowałoby dochodzenie lub przywrócenie wcześniej zatwierdzonego stanu. Zachowaj stary zapis i historię zmian. Przywrócenie jest decyzją operacyjną podejmowaną przez właściciela, a nie improwizowaną reakcją na pierwszy nieznany wiersz w raporcie.
Unikaj progu procentowego, który ukrywa populację. Wysoki ogólny wskaźnik przepustowości może współistnieć z całkowicie zawodzącą usługą krytyczną. Skorzystaj z przewodnik dotyczący raportu zbiorczego aby zachować mianownik i kontekst atrybucji.
Zapisz przyczynę i przejrzyj ją, gdy domena się zmieni
Rezultatem może być zmiana polityki, korekta nadawcy, dalsza obserwacja, separacja domeny lub decyzja o utrzymaniu istniejącej polityki. Wyjaśnij przyczynę i jej dowody.
Powróć do tej decyzji, gdy nowa aplikacja, przejęcie, brama lub zastosowanie biznesowe zmienią legalną populację poczty. The przewodnik po zasobach nadawcy zapewnia zapis operacyjny, podczas gdy kwarantanna kontra odrzucenie dokładniej analizuje kompromis w zakresie obsługi.
Zastosuj dowody, nie wyolbrzymiając ich
W przypadku domeny fikcyjnych potwierdzeń samo utrzymywane ustawienie DKIM nie wystarczy: wymaga potwierdzenia odebranej wiadomości o przejściu dopasowanego podpisu i innych kontroli uczestnictwa. W przypadku domeny personelu zachowaj nierozwiązany wpływ na listę mailingową jako wyraźne ograniczenie decyzyjne. Żaden scenariusz nie autoryzuje zmiany DNS ani nie żąda wykonania testu.