Jak Przeczytać Politykę DMARC Firmy w Dziesięć Sekund (I Co Ci Ona Nie Powie)

Jedno wyszukiwanie DNS mówi ci, co firma poprosiła światowe serwery pocztowe, aby robiły z podrobionymi wiadomościami wysłanymi w jej imieniu. Rekord jest publiczny, a polecenie to jeden wiersz: dig +short TXT _dmarc.example.com. To, co wraca, to krótki ciąg ustawień, a wewnątrz niego znajduje się jedna instrukcja — p=none, p=quarantine lub p=reject — która określa preferencję właściciela domeny, gdy wiadomość korzystająca z tej domeny nie przejdzie uwierzytelnienia.

Aktualna specyfikacja RFC 9989, opublikowana w maju 2026 jako dokument IETF Standards Track, zastąpiła starszą RFC 7489. Definiuje trzy wartości niemal lakonicznie:

• p=none — „Właściciel domeny nie wyraża żadnej preferencji."
• p=quarantine — „Właściciel domeny uważa taką wiadomość za podejrzaną. Jest możliwe, że wiadomość jest ważna, chociaż błąd uwierzytelnienia stanowi znaczący powód do niepokoju."
• p=reject — „Właściciel domeny uważa wszystkie takie błędy za wyraźny dowód na to, że użycie nazwy domeny nie jest ważne."

Przeczytaj te słowa jeszcze raz, bo są słabsze niż większość wyjaśnień DMARC przyznaje. Polityka to preferencja publikowana przez nadawcę, aby odbiorcy mogli ją rozważyć. Nie jest to instrukcja, którą odbiorca jest zobowiązany wykonać. RFC 9989 mówi o tym w jednym zdaniu: „Ostateczna obsługa dowolnej wiadomości zawsze jest kwestią lokalnej polityki i jest pozostawiona do uznania odbiorcy poczty". Ta sama sekcja dodaje obie strony konsekwencji — odbiorcy „MOGĄ zdecydować się odrzucić lub umieścić wiadomość w kwarantannie, nawet jeśli przejdzie sprawdzenie walidacji DMARC", a „NIE POWINNI odrzucać wiadomości wyłącznie z powodu opublikowanej polityki „reject"", dokładnie po to, aby uzasadnione wiadomości wysyłane w sposób, który DMARC nie może opisać, i listy mailingowe, nie zostały zniszczone w procesie.

Co więc faktycznie przyznaje p=none? Mniej niż zwykle się od niego wymaga. W warunkach specyfikacji to Tryb Monitorowania: właściciel domeny zbiera raporty zagregowane i „nie wyraża żadnej preferencji obsługi dla wiadomości, które nie przejdą walidacji DMARC", podczas gdy odbiorca wdrażający DMARC „może nadal" walidować użycie domeny. To, czego nie robi, to wyłączanie czegokolwiek po stronie odbiorcy. Filtrowanie spamu dostawcy, ocena reputacji, kontrola adresów URL i analiza załączników to osobna maszyna, która działa niezależnie od tego, co nadawca opublikował. Podrobiona wiadomość docierająca do domeny p=none nie jest promowana do twojej skrzynki odbiorczej przez rekord; jest po prostu przekazana odbiorcy bez wyrażonej preferencji, a odbiorca decyduje.

Druga połowa nieporozumienia biegnie w drugą stronę. DMARC nie czyta niebezpiecznej części wiadomości phishingowej. Jej własna specyfikacja wymienia, co jest celowo poza zakresem, a „analiza zawartości" znajduje się na tej liście, w tych słowach. Stwierdza również, że DMARC „nie dotyczy użycia wizualnie podobnych nazw domen ani nadużywania nazwy wyświetlanej czytelnej dla człowieka w RFC5322.From" — dwóch sztuczek, które niosą większość wiadomości podszywających się pod markę. A na temat wartości przebiegu: „przebieg DMARC sam w sobie nie gwarantuje, że dostarczenie do skrzynki odbiorczej odbiorcy byłoby bezpieczne lub pożądane." Prawidłowo uwierzytelniona wiadomość z tymczasowej domeny przechodzi DMARC czysto. DMARC odpowiada na pytanie, kto został upoważniony do użycia domeny w nagłówku From:. Nic więcej.

Tu właśnie zasady masowych nadawców z 2024 roku są rutynowo błędnie zgłaszane, w tym w pierwszej wersji tego artykułu. Wytyczne nadawcy Google wymagają, aby nadawcy wysyłający 5000 lub więcej wiadomości dziennie na konta Gmail „Skonfigurować uwierzytelnienie DMARC dla domeny wysyłającej", a następnie mówią w tym samym oddechu: „Twoja polityka egzekwowania DMARC może być ustawiona na none". Yahoo's Sender Hub, który musi być czytany oddzielnie, a nie zakładany, że kopiuje Google, określa wymóg jako „Opublikuj ważną politykę DMARC z co najmniej p=none — DMARC musi przejść", i nie publikuje żadnego progowego progu ilości liczbowej. Oba zestawy wymagań weszły w życie w lutym 2024. Żaden nie zmusza nikogo do opuszczenia p=none. To, co faktycznie wymuszają oba, to uwierzytelnienie, które się uzupełnia: Google wymaga, aby „domena w nagłówku From: nadawcy była wyrównana z domeną SPF lub domeną DKIM", a Yahoo mówi, że wyrównanie rozluźnione jest akceptowalne. Wyrównanie, nie surowość, jest bramą.

Co zostaje rzeczywistym powodem, dla którego domeny znajdują się w monitorowaniu, i jest to raczej operacyjne niż tchórzliwe. Przejście do quarantine lub reject oznacza najpierw znalezienie każdej usługi, która wysyła wiadomości w twoim imieniu — pensje, ticketing, marketing, biuro obsługi, które nikt nie udokumentował — i uwierzytelnienie każdej z nich, aby się wyrównała. Standard sam przyznaje zagrożenia, które czynią to wolnym: nadawcy trzecich stron nie są wprowadzeni ani wykluczeni przez DMARC, przekazywanie i listy mailingowe mogą złamać wyrównanie bez winy nadawcy, a specyfikacja wskazuje odbiorców na RFC 7960 dokładnie dla tych trybów awarii. Organizacja, która publikuje p=none i czyta jej raporty, wykonuje pracę w kolejności, którą opisuje specyfikacja. Jedna, która publikuje p=none i ignoruje raporty, tego nie robi. Z zewnątrz sam rekord nie może ci powiedzieć, którym z nich się patrzysz.

Nie potrzebujesz terminala, aby sprawdzić. Bezpłatne narzędzia wyszukiwania — dmarcian's domain checker, MXToolbox's DMARC check — pobierają rekord i drukują politykę dla ciebie. Zrób to dla twojego banku, dostawcy wynagrodzeń, linii lotniczej, którą latasz. Po prostu przeczytaj odpowiedź za to, czym jest: oświadczenie intencji przez właściciela domeny, jedno wejście wśród wielu w decyzję, którą twój dostawca poczty podejmuje samodzielnie, na temat jednego konkretnego rodzaju fałszerstwa. To jest naprawdę użyteczna rzecz, którą można przeczytać w dziesięć sekund. To nie werdykt na temat tego, czy następna wiadomość twierdząca, że pochodzi od tej marki, jest bezpieczna.

Sprostowanie, 20 października 2026. Wcześniejsza wersja tego artykułu opisywała p=none jako dostarczanie fałszerstw do skrzynki odbiorczej i p=reject jako jedyne ustawienie, które blokuje podróbkę, mówiła, że reguły masowych nadawców Google i Yahoo z 2024 roku zmusiły nadawców do opuszczenia p=none, i cytowała liczbę mniej więcej jednej na trzy domeny w egzekwowaniu. Opisy polityki zostały poprawione w oparciu o RFC 9989; zarówno Google, jak i Yahoo faktycznie akceptują p=none, cytując powyżej z ich własnej dokumentacji; a liczba egzekwowania została usunięta, ponieważ raport źródłowy nie publikuje swojej próbki ani mianownika. Artykuł teraz również stwierdza, czego DMARC nie bada.

@@END@@