Co to jest DMARC? Alignment, polityki, RFC 2026 i wdrażanie

Co to jest DMARC? Alignment, polityki i RFC 2026

Co to jest DMARC? To rekord DNS, który informuje serwery pocztowe odbiorcy, co zrobić, gdy wiadomość rości sobie prawo do Twojej domeny w nagłówku From, ale nie przejdzie autoryzacji, oraz gdzie wysłać raporty na ten temat. DMARC nie autentykuje niczego samodzielnie. Sprawdza, czy SPF lub DKIM przeszły i czy domena, którą zatwierdziły, zgadza się z domeną, którą widzi odbiorca.

Tę zgodność między domenami nazywamy alignment, i to jest część, którą większość zespołów wykonuje źle. Wiadomość może przejść test SPF, przejść test DKIM i wciąż zawieść test DMARC. Zrozumienie tego mechanizmu jest kluczowe do właściwej konfiguracji Twojej infrastruktury pocztowej.

DMARC to warstwa polityki na szczycie SPF i DKIM

SPF wymienia, które adresy IP mogą wysyłać dla domeny. DKIM podpisuje wiadomość, aby odbiorca mógł zweryfikować, że nie była zmieniana i że domena podpisu ją zatwierdziła. Żaden z nich nie patrzy na adres From, który widzi człowiek.

DMARC zamyka tę lukę. Zadaje jedno pytanie: czy domena w widocznym nagłówku From zgadza się z domeną, która przeszła SPF lub DKIM? Jeśli tak, wiadomość przechodzi. Jeśli nie, odbiorca stosuje Twoją politykę. Działa to na poziomie infrastruktury, bez ingerencji w treść wiadomości.

Rekord znajduje się w _dmarc.domena.pl jako rekord TXT. Minimalny, ważny wygląda tak:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Trzy tagi wykonują prawdziwą pracę. p to polityka, rua to miejsce, gdzie trafiają raporty zbiorcze, a adkim / aspf ustawiają, jak rygorystyczne jest alignment. Wszystko inne jest opcjonalne.

Alignment to gdzie porządne konfiguracje zawodzą

SPF autentykuje adres nadawcy kopertą, domenę Return-Path. DKIM autentykuje domenę w tagu d= podpisu. DMARC wymaga, aby przynajmniej jeden z nich zgadzał się z domeną From, dokładnie (strict) lub na poziomie domeny organizacyjnej (relaxed, domyślnie).

Tu widzimy najczęstszą porażkę w śladach diagnostycznych. Zespół wysyła przez dostawcę trzeciej strony, dostawca podpisuje swoją domeną (d=provider-mail.net) i używa swojej domeny zwrotnej. SPF przechodzi, DKIM przechodzi, DMARC zawodzi, ponieważ żadna domena nie zgadza się z example.com.

Rozwiązaniem jest własna domena wysyłająca: klucz DKIM opublikowany pod Twoją domeną i idealnie niestandardowy return-path na subdomenie. Każdy poważny dostawca to obsługuje. Niewielu włącza to domyślnie. Wymaga to zaplanowania, ale skutek to kontrola pełna nad autentykacją.

Trzy polityki: none, quarantine, reject

Tag p ma trzy wartości i nie są one drabiną, którą wspinasz się według harmonogramu. Każda ma konkretny cel i moment wdrażania.

• p=none: odbiorca dostarczy normalnie i wysyła Ci raporty. Używaj przez pierwsze 2-4 tygodnie, podczas gdy inventaryzujesz nadawców. To faza obserwacji.

• p=quarantine: odbiorca kieruje porażki do spamu lub kosza. Używaj gdy raporty pokażą wszystkich legalnych nadawców wyrównanych. Pierwszy krok egzekucji.

• p=reject: odbiorca odmawia porażek na etapie SMTP. Używaj gdy quarantine przebiegł czysty przez pełny cykl wysyłania. Ochrona maksymalna.

p=none to monitoring, nie ochrona. Domena siedząca w none przez dwa lata ma pole sprzeciwu compliance i żadną obronę przed spoofingiem. Pomiń pokusę, by tam zostać, bo „nic się nie złamało".

p=reject to cel dla każdej domeny, która wysyła tylko kontrolowaną pocztę. Domeny z dużym ruchem list mailowych lub starszymi forwarderami wymagają więcej uwagi, ponieważ forwarding często łamie SPF i może złamać DKIM, jeśli pośrednik edytuje treść.

Dlaczego reguły Gmail i Yahoo uczyniły to pilne

Od lutego 2024 roku wytyczne nadawcy Google wymagają od każdego wysyłającego więcej niż 5000 wiadomości dziennie na konta Gmail opublikowania rekordu DMARC, ze SPF i DKIM. Polityka może być none. Google prosi również nadawców zbiorowych, aby utrzymywać zgłaszaną przez użytkowników stawkę spamu w Postmaster Tools poniżej 0,30% i rekomenduje trzymanie się poniżej 0,10%.

Centrum Nadawcy Yahoo określa ten sam główny wymóg: opublikowany rekord DMARC z polityką co najmniej p=none, z domeną From wyrównaną do domeny SPF lub DKIM. Wyrównanie relaxed jest dopuszczalne.

Zwróć uwagę na to, co jest i nie ma w tych regułach. Wymóg to opublikowany rekord i alignment, nie egzekucja. To podłoga. Nie jest to linia mety. Znaczenie ma dla każdego, kto wysyła pocztę transakcyjną, produktową lub marketingową.

Raporty zbiorcze to produkt, polityka to przełącznik

Adres rua otrzymuje dzienne raporty XML od każdego odbiorcy, który honoruje DMARC. Każdy raport wymienia źródłowe IP, liczby wiadomości, wyniki SPF i DKIM oraz czy alignment się utrzymał. To jak znaleźć zapomnianego nadawcę: stary eksport CRM, narzędzie rozliczeniowe, które operator podłączył w 2022, formularz marketingowy na subdomenie, którą nikt nie posiada.

Surowy XML jest nieczytelny na dużą skalę. Skieruj rua do skrzynki, którą parser może przetwarzać, lub do hostowanej usługi raportowania DMARC, i spójrz na dane zgrupowane po źródle. Co chcesz zobaczyć, to każde legalne źródło wykazujące 100% alignment i wszystko inne wyraźnie nieznane. Dane z raportów stanowią fundament Twojego planu działania.

Praktyczne wdrażanie przebiega w tej kolejności:

1. Opublikuj p=none z adresem rua.

2. Zbieraj raporty przez 2-4 tygodnie. Zbuduj inwentarz nadawców.

3. Napraw każde wyrównane źródło legalnym za pomocą niestandardowej domeny DKIM lub return-path.

4. Przejdź do p=quarantine. Obserwuj zgłoszenia o brakującej poczcie.

5. Przejdź do p=reject gdy quarantine pokazuje żadne legalne porażki.

Wyślij każdy krok osobno. Zmiana polityki i dodanie nowego dostawcy wysyłającego w tym samym tygodniu powoduje, że każda regresja jest niemożliwa do przypisania.

DMARCbis zmienia tagi, nie Twój rekord

W 2026 roku IETF opublikował RFC 9989, RFC 9990 i RFC 9991, które zastępują RFC 7489. RFC 9989 to główna specyfikacja DMARC. Raportowanie zbiorcze i raportowanie porażek przeniosło się do własnych dokumentów.

Praktyczne zmiany dla właściciela rekordu są małe, ale znaczące:

• pct, rf i ri są usuwane.

• t (tryb testowania) zastępuje pct jako przełącznik wszystko albo nic: t=y raporty bez egzekucji.

• np ustawia politykę dla nieistniejących subdomen, co blokuje spoofing adresów takich jak abc123.example.com.

• psd oznacza publiczne sufiksy domenowe, a chód drzewa DNS zastępuje stare wyszukiwanie Public Suffix List.

Istniejące rekordy v=DMARC1 pozostają ważne. Nic się nie łamie, jeśli dziś niczego nie zmienisz. Obsługa dostawcy dla nowych tagów będzie się rolować nierównomiernie, więc nowy tag, który wydaje się nic nie robić, zwykle oznacza, że odbiorca go jeszcze nie wdrożył.

Tag np wart jest wczesnego przyjęcia. Ustawienie np=reject podczas gdy p jest wciąż none wyłącza ścieżkę nadużycia fałszywych subdomen bez zatwierdzania reszty poczty do egzekucji.

Subdomeny i dlaczego domyślnie dziedziczą

Rekord DMARC na domenie organizacyjnej stosuje się też do subdomen, chyba że zastąpisz to za pomocą sp. To dziedziczenie jest przydatne i też pułapką. Wymaga zrozumienia hierarchii i planowania.

Jeśli marketing wysyła z news.example.com przez oddzielnego dostawcę, dziedziczy politykę rodzica. Przenieś rodzica do p=reject zanim dostawca będzie miał wyrównany DKIM i newsletter wypadnie na ziemię. Opublikuj oddzielny rekord _dmarc.news.example.com, gdy subdomena ma swoją flotę wysyłających i własne tempo wdrażania.

Czystsza architektura oddziela strumienie poddomenami od samego początku. Poczta transakcyjna na jednej, lifecycle na drugiej, poczta człowieka na głównej. Każdy ma swoje klucze DKIM, swoją reputację i własny rekord DMARC. Ta separacja upraszcza diagnostykę i wdrażanie polityk.

Przeczytaj nagłówek Authentication-Results zanim zgadniesz

Gdy wiadomość zawodzi, serwer odbiorczy rejestruje dlaczego. W Gmailu „Pokaż oryginał" odsłania nagłówek Authentication-Results i mówi więcej niż każdy pulpit. To podstawowe narzędzie diagnostyczne.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.provider-mail.net;
  dkim=pass header.d=provider-mail.net;
  dmarc=fail (p=NONE) header.from=example.com

Przeczytaj od lewej do prawej. SPF przeszedł dla bounce.provider-mail.net. DKIM przeszedł dla provider-mail.net. DMARC zawiódt, ponieważ nagłówek From mówi example.com i żadna przechodząca domena nie pasuje.

Notatka (p=NONE) pokazuje politykę, którą widział odbiorca. W none ta wiadomość została dostarczana mimo wszystko. W reject powinna być odrzucona z błędem 5.7.x i nadawca dowiedziałby się od klienta.

Dwa sprawdzenia łapią większość tych przypadków. Potwierdź wartość header.d w wyniku DKIM to Twoja domena. Następnie potwierdź domenę smtp.mailfrom to Twoja domena lub jej subdomena.

SPF ma limit wyszukiwań, który DMARC ujawnia

SPF pozwala dziesięciu wyszukiwaniom DNS na ocenę. Każdy include: dla dostawcy wydaje kilka z nich, a zagnieżdżone include wydają więcej. Przekrocz dziesięć a SPF zwraca błąd trwały, który liczy się jako porażka. To ograniczenie techniczne ma konsekwencje biznesowe.

Zespoły z pięcioma lub sześcioma narzędziami wysyłającymi trafiają tu bez zauważenia, bo porażki SPF były niewidoczne przed raportowaniem DMARC. Gdy raporty rua się pojawią, wzór jest oczywisty: jedno źródło nagle zawodzące SPF u wszystkich odbiorców w dniu, gdy ktoś dodał kolejny include:.

To jeszcze jeden powód, aby polegać na alignment DKIM jako główna ścieżka. DKIM przetrwa większość forwarding, nie ma budżetu wyszukiwań i wiąże się z wiadomością niż z połączeniowym IP. Zachowaj SPF ważny, ale nie buduj DMARC przejdź na nim samym.

Co DMARC nie robi

DMARC zapobiega exact-domain spoofingowi. Nie uniemożliwia lookalike domen (examp1e.com), nie osądza zawartości i nie naprawia złej reputacji nadawcy. Doskonale wyrównana domena, która wysyła na kupione listy wciąż ląduje w spamie. DMARC to narzędzie autentykacji, nie reputacji.

Nie zastępuje też monitoringu. Alignment może się zepsuć w ciszy: zmiana DNS usuwa selektor DKIM, dostawca rotuje klucze, nowe narzędzie zaczyna wysyłać bez Twojej wiedzy. Raporty to jak dowiadujesz się zanim Twoi użytkownicy.

Traktuj rekord DMARC jak każdą inną konfigurację produkcji. Należy do kontroli wersji, zmiany przechodzą przez przegląd, a skrzynka rua potrzebuje właściciela. Wersjonowanie zmian jest czymś, co warto zaplanować z góry.

Zanim opublikujesz rekord

Przejdź przez to raz. Zajmuje to mniej niż godzinę dla jednej domeny. To lista kontrolna przed wdrażaniem:

• Wymień każdy system, który wysyła pocztę jako Twoja domena: produkt, rozliczenia, pomoc, CRM, marketing, zaproszenia kalendarza.

• Potwierdź każdy podpisuje DKIM Twoją domeną, nie domeną dostawcy.

• Ustaw niestandardowy return-path tam gdzie dostawca to pozwala.

• Wybierz destinację rua, którą ktoś będzie czytać.

• Zacznij w p=none i umieść datę przeglądu na kalendarzu.

• Sprawdzaj stawkę spamu w Google Postmaster Tools co tydzień podczas wdrażania.

Te kroki przedtem uratują Ci tygodnie debugowania później.

Gdzie pójść dalej

Jeśli nigdy nie patrzyłeś na swoje raporty, opublikuj p=none z adresem rua dziś i przeczytaj co przyjdzie za dwa tygodnie. Pierwszy raport prawie zawsze wymienia przynajmniej jednego nadawcę, którego nikt nie pamiętał. Następnym konkretnym krokiem jest decyzja, których z nich utrzymujesz. To połączenie danych i działania, które mówi Ci, czy Twoja infrastruktura pocztowa jest bezpieczna.