DMARCbis zmienia sposób, w jaki części DMARC są określone i wdrożone. Nie prosi o zmianę nazwy rekordu na DMARC2. Podstawowa specyfikacja, RFC 9989, ukazało się w maju 2026 r., natomiast RFC 9990 I RFC 9991 obejmują raportowanie zbiorcze i raportowanie awarii oddzielnie.
Praktycznym zadaniem jest sprawdzenie, jakie zmiany dotyczą Twojej domeny, usług wysyłania i oprogramowania przetwarzającego Twoje dane uwierzytelniające. Zaczyna się od zrozumienia bieżących specyfikacji, a następnie porównania ich z konfiguracją i procesami już używanymi. Rezultatem powinien być przejrzysty rejestr gotowości zawierający dowody, właścicieli i decyzję dotyczącą każdego ustalenia.
Przypisz trzy specyfikacje do swoich systemów
Skorzystaj z aktualnych dokumentów dla odpowiednich stanowisk:
| Dokument | Co recenzować |
|---|---|
| RFC 9989 | Podstawowa ocena DMARC , odkrywanie zasad, wyrównanie i zapisz semantykę |
| RFC 9990 | Format, generowanie i przetwarzanie zbiorczego raportowania |
| RFC 9991 | Zgłaszanie awarii i kwestie związane z obsługą |
Zacznij od istniejącej historii rekordów i konfiguracji. Nie usuwaj zapisu operacyjnego tylko dlatego, że cytuje go starszy przewodnik RFC 7489. Zidentyfikuj instrukcje, które uległy zmianie, i oprogramowanie, które je implementuje.
Główne obszary przeglądu obejmują:
- Odkrycie domeny: RFC 9989 sekcja 4.10 definiuje przechodzenie po drzewie DNS . Przejrzyj systemy, które zakładają starszy model wykrywania list publicznych.
- Tagi zasad: Sprawdź aktualny rejestr IANA . The
proc,rfIritagi są historyczne. Oceniaćt,npIpsdwedług ich rzeczywistego zakresu, zamiast dodawać je jako listę kontrolną aktualizacji. - Testowanie: Ustal, w jaki sposób odpowiedni oceniający implementuje plik binarny
tsygnał. Deklarowany stan testowy i ostateczna dyspozycja odbiorcy to różne obserwacje. - Raportowanie: Upewnij się, że moduły zbierające i parsery obsługują formaty raportów i pola, które spodziewasz się otrzymać, bez utraty odpowiednich starszych obserwacji.
Znacznik wersji pozostaje v=DMARC1. Nie zastępuj DMARC2 lub mechanicznie zastąp stary procent flagą testową.
Przetłumacz zmienione tagi na testy
The t flaga domyślnie ustawiona na n, z prośbą o zastosowanie zadeklarowanej oceny do awarii DMARC . Ustawienie t=y sygnalizuje, że właściciel testuje, zamiast prosić o bezpośrednie zastosowanie zadeklarowanej oceny. RFC 9989 sekcja 4.7 definiuje jednopoziomową redukcję w przypadku wiadomości, które nie zostały wysłane: odrzucenie staje się kwarantanną, a kwarantanna brakiem. Wdrożenia mogą również wymagać odpowiedniego specjalnego traktowania.
Flaga nie zmienia wyniku nieudanego uwierzytelnienia na pozytywny, nie zmienia generowania raportu ani nie wpływa na zasadę braku. Jest to plik binarny, a nie żądanie pobrania dowolnego procentu poczty. Zapewnij wsparcie wdrożeniowe, zanim zaczniesz na nim polegać w przypadku rzeczywistego ruchu, i oddziel filtrowanie lokalne od odbiorcy od wyników testów na poziomie zasad.
Na zakres oceny wpływają dwa kolejne tagi:
- np: Określa ocenę dla nieistniejących subdomen dominujących domena organizacyjna. W przypadku braku, obowiązującą rezerwą jest sp, jeśli jest obecna, w przeciwnym razie p. Zaginiony Rekord MX samo w sobie nie stwierdza nieistnienia.
- psd: Oznacza informacje o granicach domeny używane podczas wykrywania. Domyślnie u pozostawia określenie granic regułom wykrywania; y identyfikuje sufiks publiczny, podczas gdy n identyfikuje granicę organizacyjną sufiksu niepublicznego dla siebie i swoich subdomen. Nie ustawiaj żadnej jawnej wartości granicznej bez sprawdzenia, czy poprawnie opisuje ona domenę.
Zwykła organizacja nie powinna oznaczać swojej domeny publicznym sufiksem jedynie w celu zapewnienia gotowości. Przejrzyj faktyczne założenia dotyczące wykrywania i delegowane przestrzenie nazw. The przewodnik po zasadach subdomen obejmuje węższą kwestię dziedziczenia.
Zidentyfikuj pocztę, która musi nadal działać
Domena może reprezentować znacznie więcej niż pocztę pracowniczą. Może pojawiać się na fakturach, linkach do logowania, alertach dla klientów i wiadomościach wysyłanych przez agencje zewnętrzne. Aktualizacja standardów daje możliwość sprawdzenia tych zależności, zanim pośpieszna zmiana konfiguracji je zakłóci.
Poproś o trzy elementy: wykaz usług korzystających z Twojej tożsamości, wyjaśnienie konkretnych zmian, które Cię dotyczą oraz plan testów dla krytycznych wiadomości. Odpowiedź powinna odróżniać opublikowaną specyfikację od funkcji już wdrożonej przez konkretny odbiornik lub usługę oprogramowania.
Przydziel własność i budżet. Zmiana w przetwarzaniu raportów wymaga osoby odpowiedzialnej za proces raportowania. Nadawca, który nie może poprawnie uwierzytelnić, potrzebuje zaangażowania właściciela firmy. Wywołanie obu elementów aktualizacją DNS ukrywa pracę.
Zbuduj rejestr gotowości
Poniżej znajduje się przykładowy rejestr planowania, a nie ocena rzeczywistej domeny:
| Odkrycie | Wymagana praca | Dowód ukończenia |
|---|---|---|
| Instrukcje wdrażania zakładają pobieranie próbek procentowych | Przetestuj flagę binarną, korzystając z kontrolowanych urządzeń poniżej | Zapisana ocena zadeklarowana, ocena po flagi testowej i niezależna decyzja odbiorcy |
| Analizator raportów zakłada jeden starszy schemat | Przejrzyj akceptowane formaty, pola i obsługę błędów | Wersjonowano ważne, starsze i zniekształcone urządzenia |
| Aplikacja krytyczna nie ma znanego właściciela | Ustanów usługę biznesową i obsługiwane tożsamości | Nazwany właściciel i zweryfikowana próbka odebranej wiadomości |
| Edytor DNS jest kontrolowany przez zewnętrzny zespół | Uzgodnij obowiązki związane z zatwierdzaniem i odzyskiwaniem | Dokładny podgląd zmian, zatwierdzenie i materiał do renowacji |
Poniższe syntetyczne urządzenia określają oczekiwane wyniki dla kontrolowanego oceniającego wdrażającego RFC 9989 . Są to dane wejściowe do testów, a nie szablony dokumentacji produkcyjnej lub już wykonane testy. Załóżmy, że odnaleziono prawidłową, mającą zastosowanie politykę i wiadomość testowa nie przeszła DMARC .
| Osprzęt | Wejście | Oczekiwane obserwacje na poziomie polityki |
|---|---|---|
| Flaga testowa | p=reject; t=y | Walidacja pozostaje nieudana; ocena po t=y oznacza kwarantannę, a nie zadeklarowane odrzucenie |
| Oznacz brak | p=none; t=y | Flaga pozostawia brak oceny i zachowanie generowania raportów bez zmian |
| Nieistniejące dziecko | Dominująca polityka dotycząca domeny organizacyjnej ma p=none; sp=quarantine; np=reject, domyślnie t=n; dziecko zostaje uznane za nieistniejące i nie ma bezpośredniej polityki | Obowiązująca ocena podrzędna jest odrzucana, a nie istniejąca wartość sp dla podrzędnego |
Rejestruj oddzielnie wersję oceniającego, dane wejściowe, zaobserwowaną walidację, wybraną ocenę i wszelkie końcowe postępowanie. Kontrolowane urządzenie ustala testowane zachowanie; nie dowodzi to, że każdy odbiorca Internetu realizuje te same zasady. Obserwacja kwarantanny na poziomie zasad nie stanowi uniwersalnej obietnicy umieszczenia folderu ze spamem.
Sprawdź także przydatność zasad. RFC 9989 sekcja 7.4 odradza odrzucanie domen e-mailowych ogólnego przeznaczenia, ponieważ legalne trasy pośrednie, w tym listy mailingowe, mogą zostać uszkodzone. Przed zaproponowaniem silniejszej polityki w ramach przeglądu gotowości należy zidentyfikować te trasy i ocenić mające zastosowanie wytyczne dotyczące interoperacyjności.
Zmiany konfiguracji należy przechowywać oddzielnie od zmian w oprogramowaniu lub procesach. Niektóre wyniki nie wymagają natychmiastowej edycji DNS . Inne wymagają aktualizacji dostawcy, poprawki parsera lub kontrolowanego testu wdrożenia.
Sprawdź interoperacyjność i ograniczenia deklaracji gotowości
Oświadczenie o gotowości powinno określać jego zakres. Czy obejmuje portfel domen, osobę oceniającą zasady, osobę przetwarzającą raporty, czy tylko rekord sprawdzać? To są różne oceny.
Użyj rejestru, aby śledzić wersje implementacji i nierozwiązane różnice. Wybierz odpowiednie przypadki spośród istniejących i nieistniejących subdomen, trybów wyrównania, niepowodzeń poczty pośredniej i DNS .
Traktuj dyskrecję odbiorcy jako część modelu operacyjnego. Publikacja specyfikacji nie powoduje, że każdy odbiorca zachowuje się identycznie. Opublikowana preferencja odrzucenia również nie jest dowodem na to, że każdy odbiorca odrzucał każdą nieudaną wiadomość.
Utrzymuj niezależną kontrolę nad zhakowanymi kontami, zwodniczymi wyświetlanymi nazwami, podobnymi domenami i wrażliwymi zgodami biznesowymi. Gotowość DMARC nie powoduje, że uwierzytelnienie domeny staje się werdyktem dotyczącym bezpieczeństwa treści wiadomości.
Wprowadź i zweryfikuj wymagane zmiany
Przed zmianą produkcji należy zachować poprzedni stan, zidentyfikować dotknięte przepływy, uzyskać odpowiednią zgodę i określić warunki odzysku. Następnie sprawdź opublikowaną konfigurację i reprezentatywne komunikaty na całej trasie wysyłania.
Jeśli wynik nie zgadza się z oczekiwanym zachowaniem, wstrzymaj ekspansję na inne domeny i rozwiąż lub wyraźnie zaakceptuj ustalenie zgodności.
W przypadku tożsamości podstawowych użyj metody poradnik diagnostyki zbieżności. Aby uzyskać wstępną konfigurację, wykonaj poniższe czynności proces tworzenia i weryfikacji DMARC. W warstwie raportowania użyj przewodnik dotyczący raportu zbiorczego.
Praktyczne dania na wynos
Zakończ ocenę, gdy każde mające zastosowanie ustalenie ma właściciela, uzasadnioną decyzję i powtarzalne dowody. Zachowaj widoczność nierozwiązanych różnic w implementacji, weryfikuj krytyczne komunikaty i przetwarzanie raportów oraz zachowaj zatwierdzone warunki odzyskiwania. Etykieta gotowości powinna wskazywać na ten zapis, a nie go zastępować.