Jak skonfigurować DMARC: Kompletny przewodnik konfiguracji krok po kroku (2026)

Dostawcy poczty elektronicznej nie traktują już konfiguracji DMARC jako „miłego dodatku” w zakresie bezpieczeństwa. W związku z tym, że serwisy Gmail, Yahoo i Microsoft wprowadzają coraz surowsze wymagania dotyczące uwierzytelniania, organizacje, które nie wdrożyły protokołu DMARC, narażają się na ryzyko trwałego odrzucania wiadomości, nasilenia ataków typu spoofing oraz problemów z zapewnieniem zgodności z przepisami.

W tym przewodniku dowiesz się, jak skonfigurować DMARC od podstaw, zweryfikować ustawienia SPF i DKIM, opublikować zgodny rekord DMARC oraz stopniowo przejść z trybu monitorowania do pełnego egzekwowania. Omówimy również najnowsze aktualizacje specyfikacji RFC 9989, typowe błędy konfiguracyjne oraz praktyczne wskazówki dotyczące rozwiązywania problemów, które pomogą Ci z pewnością wdrożyć DMARC.

Po przeczytaniu niniejszego przewodnika po konfiguracji DMARC będziesz dysponować jasnym planem działania, który pozwoli zabezpieczyć Twoją domenę przed atakami typu spoofing, a jednocześnie zapewni, że legalne wiadomości e-mail będą nadal docierać do skrzynki odbiorczej.

Zgodność z przepisami z 2026 r.: Egzekwowanie przepisów już trwa

Gmail i Yahoo (listopad 2025 r.): Wprowadzono stałe stosowanie odrzucania z kodem 5xx w przypadku nadawców wysyłających masowo (ponad 5 000 wiadomości e-mail dziennie). Wiadomości niezgodne z zasadami są trwale odrzucane, a nie tylko filtrowane.

Microsoft Outlook (maj 2025 r.): Wymuszanie zgodności z protokołami SPF, DKIM i DMARC jest aktywne. Wiadomości niezgodne z tymi protokołami będą opóźniane lub odrzucane.

PCI DSS v4.0 (marzec 2025 r.): Środki zabezpieczające przed phishingiem wymagane dla wszystkich podmiotów przetwarzających dane kart płatniczych.

• CISA BOD 18-01: Wszystkie agencje federalne Stanów Zjednoczonych muszą wdrożyć protokół DMARC z polityką p=reject.
• Zobacz pełne wymagania: Globalne i regionalne wymagania dotyczące DMARC

Czym jest DMARC i jak działa?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) to protokół uwierzytelniania wiadomości e-mail, który pozwala właścicielom domen poinformować serwery pocztowe odbiorców, jak postępować z wiadomościami, które nie przeszły kontroli uwierzytelniającej SPF i DKIM. Mówiąc prościej, zapobiega to podszywaniu się pod Twoją domenę przez osoby trzecie i wskazuje odbiorcom, jak postępować w przypadku oszustów.

DMARC działa w oparciu o dwa istniejące protokoły: SPF i DKIM. Te trzy protokoły razem stanowią podstawę nowoczesnego zabezpieczenia poczty elektronicznej.

DMARC, SPF i DKIM: jak ze sobą współdziałają

SPF (Sender Policy Framework) określa, które serwery pocztowe mogą wysyłać wiadomości e-mail z Twojej domeny. Jest to rekord DNS, który określa: „Tylko te adresy IP mogą wysyłać wiadomości e-mail podające jako nadawcę domenę example.com”.

DKIM (DomainKeys Identified Mail) nakłada podpis kryptograficzny na Twoje wiadomości e-mail. Potwierdza to, że wiadomość pochodzi od Ciebie i nie została zmodyfikowana podczas przesyłania. Podpis jest weryfikowany za pomocą klucza publicznego opublikowanego w Twoim systemie DNS.

DMARC łączy te elementy. Mówi on: „Oto moje zasady. Jeśli wiadomość e-mail twierdzi, że pochodzi z mojej domeny, musi przejść weryfikację zgodności z SPF lub DKIM. Jeśli weryfikacja zakończy się niepowodzeniem, oto, co chcę, abyście zrobili: nic (tylko monitorowanie), kwarantanna (przesłanie do folderu spam) lub odrzucenie (całkowite zablokowanie)”.

Więcej informacji na temat protokołów DMARC, SPF i DKIM znajdziesz w naszym obszernym przewodniku.

Co się dzieje, gdy wiadomość e-mail nie spełnia wymogów DMARC?

Gdy odbiorca otrzymuje wiadomość e-mail rzekomo pochodzącą z Twojej domeny, porównuje ją z Twoją polityką DMARC. Wynik zależy od treści tej polityki:

• p=none (monitorowanie): Wiadomość e-mail zostanie wysłana niezależnie od wyniku. Otrzymasz raport pokazujący, co przeszło pomyślnie, a co nie.
• p=kwarantanna: Nieprawidłowe wiadomości e-mail są przenoszone do folderu ze spamem/wiadomościami niechcianymi. Prawidłowe wiadomości nadal docierają do odbiorcy.
• p=reject: Nieprawidłowe wiadomości e-mail są od razu odrzucane. Nadawca otrzymuje komunikat o odrzuceniu wiadomości.

Przed skonfigurowaniem DMARC: Warunki wstępne i spis nadawców

Wiele organizacji pośpiesznie wdraża protokół DMARC i szybko przechodzi na ustawienie „p=reject”, by potem odkryć, że blokowani są legalni nadawcy (systemy CRM, dostawcy usług e-mailowych, dział pomocy technicznej, platformy do automatyzacji marketingu). W tej sekcji omówiono proces audytu, który pozwoli uniknąć tego kosztownego błędu.

Krok 1: Sprawdź, czy dla Twojej domeny opublikowano rekord SPF

Aby protokół DMARC mógł działać, Twoja domena musi posiadać prawidłowy rekord SPF w systemie DNS.

1. Skorzystaj z naszego narzędzia do sprawdzania rekordów SPF, aby upewnić się, że Twój rekord SPF istnieje.

2. Upewnij się, że dla Twojej domeny istnieje dokładnie jeden rekord SPF typu TXT. Obecność dwóch rekordów SPF powoduje, że mechanizm SPF przestaje działać, ponieważ odbiorcy zignorują oba rekordy.

3. Wpis powinien wyglądać mniej więcej tak: v=spf1 include:sendgrid.net include:mailchimp.com ~all

Jeśli rekord SPF nie został opublikowany lub istnieją dwa sprzeczne rekordy, należy najpierw to naprawić, zanim przejdziesz dalej. Skorzystaj z naszego bezpłatnego narzędzia, aby utworzyć rekord SPF już teraz.

Krok 2: Sprawdź limit wyszukiwania SPF 10

SPF zezwala na maksymalnie 10 zapytań DNS na każdą ocenę wiadomości. Każdy zewnętrzny nadawca, któremu udzielisz autoryzacji (za pomocą include:), zużywa od 1 do 3 takich zapytań. Przekroczenie tego limitu powoduje, że weryfikacja SPF zakończy się niepowodzeniem w przypadku niektórych nadawców.

1. Skorzystaj z naszego narzędzia SPF Checker, aby sprawdzić liczbę wyszukiwań Twojego rekordu SPF

2. Policz liczbę wymaganych zapytań DNS. Jeśli liczba ta zbliża się do 10 lub ją przekracza, pojawi się komunikat o błędzie.

3. Jeśli przekroczysz limit, zoptymalizuj swój wpis, aby skonsolidować operacje wyszukiwania, zastępując instrukcje `include:` konkretnymi adresami IP. Jest to częsta przeszkoda w przypadku dużych organizacji korzystających z wielu zewnętrznych nadawców.

Krok 3: Sprawdź, czy dla wszystkich nadawców skonfigurowano DKIM

DKIM jest wymagany przez Google, Yahoo i Microsoft w przypadku nadawców masowych – nie jest to opcjonalne.

1. W przypadku domeny głównej: skorzystaj z naszego bezpłatnego narzędzia DKIM Checker, aby sprawdzić, czy rekord DKIM został opublikowany.

2. W przypadku każdego zewnętrznego nadawcy (Salesforce, HubSpot, Klaviyo itp.): należy upewnić się, że włączył on podpisywanie DKIM i opublikował swój klucz publiczny jako rekord DNS. Zazwyczaj wymaga to zwrócenia się do dostawcy z prośbą o „włączenie niestandardowego DKIM dla danej domeny”.

3. Każdy nadawca powinien posiadać unikalny selektor DKIM (np. k1._domainkey.example.com, sendgrid._domainkey.example.com).

Jeśli brakuje DKIM, skonfiguruj go teraz, zanim przejdziesz do egzekwowania DMARC. Skorzystaj z naszego bezpłatnego narzędzia, aby wygenerować rekord DKIM dla swojej domeny.

Krok 4: Sporządzenie wykazu wszystkich zewnętrznych nadawców wiadomości e-mail

Utwórz listę wszystkich usług, które wysyłają wiadomości e-mail z Twojej domeny:

• ESPs (SendGrid, Mailchimp, Klaviyo itp.)
• CRM (Salesforce, HubSpot, Pipedrive itp.)
• Systemy pomocy technicznej/wsparcia (Zendesk, Freshdesk itp.)
• Automatyzacja marketingu (Marketo, Pardot, ActiveCampaign itp.)
• Platformy do wysyłania wiadomości e-mail związanych z transakcjami (Auth0, Stripe, AWS SES itp.)
• Wewnętrzne serwery lub aplikacje wysyłające powiadomienia
• Usługi przesyłania wiadomości lub administratorzy list mailingowych

W przypadku każdego nadawcy należy sprawdzić:

1. Spełniają one wymagania dotyczące zgodności z SPF (zawarte w Twoim rekordzie SPF)
2. Przechodzą weryfikację zgodności z DKIM (podpisywanie DKIM jest włączone dla Twojej domeny)
3. Są one skonfigurowane tak, aby w nagłówku „From:” wykorzystywały Twoją domenę

Skorzystaj z naszego narzędzia DMARC Report Analyzer, aby sprawdzić, czy nie ma wśród nadawców osób nieuprawnionych.

Krok 5: Sprawdź, czy rekord DMARC już istnieje

Skorzystaj z naszego narzędzia do sprawdzania DMARC, aby sprawdzić, czy Twoja domena posiada już rekord DMARC.

• Jeśli widzisz komunikat „p=none”: Twoja domena znajduje się w trybie monitorowania. Niniejszy przewodnik pomoże Ci bezpiecznie przejść do trybu egzekwowania.
• Jeśli zauważysz przestarzałe tagi (pct=, rf=, ri=): nie są one już częścią standardu RFC 9989 i należy je usunąć przy następnej edycji wpisu.
• Jeśli nie znaleziono żadnego wpisu: Zaczynasz od nowa. Przejdź do następnej sekcji.

Jak skonfigurować DMARC: instrukcja krok po kroku

Krok 1: Utwórz rekord DMARC

Skorzystaj z naszego narzędzia DMARC Generator, aby utworzyć swój pierwszy rekord.

Pola obowiązkowe:

• Domena: Twoja domena (np. example.com)
• Zasada: Rozpocznij z ustawieniem p=none (tryb monitorowania, brak egzekwowania)
• Adres do wysyłania raportów: adres e-mail, na który chcesz otrzymywać raporty zbiorcze (np. [email protected])

Zalecane dodatki:

• np=reject: Chroni nieistniejące subdomeny przed spoofingiem (nowość w RFC 9989, zerowy koszt)
• Adres rua: Miejsce docelowe raportu zbiorczego (kluczowe dla monitorowania)

Przykładowy rekord początkowy:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Ten wpis informuje odbiorców: „Monitorujcie wiadomości e-mail z mojej domeny i przesyłajcie mi codzienne raporty, ale na razie niczego nie blokujcie”.

Krok 2: Zapoznaj się z rekordem DMARC przed opublikowaniem

Rekord DMARC to ciąg par „tag-wartość” oddzielonych średnikami. Obowiązkowe są jedynie tagi v= i p= – pozostałe elementy są opcjonalne, ale zalecane. Przed opublikowaniem należy zapoznać się z funkcją każdego z tagów:

Wymagane znaczniki

Tag	Opis i zasady
v= (wersja)	• Wartość: Zawsze v=DMARC1 • Musi to być pierwszy tag w rekordzie • Istnieje tylko jedna prawidłowa wartość
p = (polisa)	• Wartości: none, quarantine, albo reject • Informuje odbiorców, jak postępować z wiadomościami e-mail, które nie przeszły kontroli DMARC • Różnice przedstawiono w poniższej tabeli zasad

Tagi opcjonalne

np = (brak zasad dotyczących subdomen)

• Wartości: brak, kwarantanna lub odrzucenie
• Stosuje politykę do subdomen, które nie posiadają rekordu DMARC
• Chroni przed podszywaniem się pod losowe subdomeny (np. random123.example.com)
• Zalecenie: Ustaw np=reject dla wszystkich domen. Nie wiąże się to z żadnymi kosztami, a pozwala wyeliminować lukę umożliwiającą spoofing.

rua= (adres do celów sprawozdań zbiorczych)

• Format: rua=mailto:[email protected]
• Można podać wiele adresów, oddzielając je przecinkami: rua=mailto:[email protected],mailto:[email protected]
• Raporty zbiorcze to podsumowania w formacie XML wysyłane codziennie przez odbiorniki
• Ma to kluczowe znaczenie dla monitorowania. Bez tego nie masz wglądu w przepływ poczty.

sp= (polityka subdomeny)

• Wartości: brak, kwarantanna lub odrzucenie
• Stosuje politykę do subdomen, które posiadają rekord DMARC
• Jeśli nie podano inaczej, stosowana jest polityka główna (p=)
• Użyj tej opcji, jeśli chcesz zastosować bardziej rygorystyczne zasady w odniesieniu do subdomen (np. mail.example.com)

fo = (opcje zgłaszania awarii)

• Wartości: 0 (domyślnie), 1, d, s lub kombinacje (0:1:d:s)
• Określa, kiedy wysyłane są raporty kryminalistyczne (dotyczące awarii)
• fo=0: Generuj raporty tylko wtedy, gdy zawiodą wszystkie mechanizmy uwierzytelniania
• fo=1: Generuj raporty w przypadku niepowodzenia dowolnego mechanizmu uwierzytelniania (bardziej szczegółowe, przydatne na etapie konfiguracji)
• Zazwyczaj stosowane wraz z tagiem ruf= (patrz poniżej)
• Zalecenie: Podczas wstępnej konfiguracji należy ustawić wartość fo=1, aby wykryć wszystkie usterki; po upewnieniu się co do prawidłowości ustawienia należy zmienić tę wartość na fo=0.

adkim= (tryb dopasowania DKIM)

• Wartości: r (luźne, domyślne) lub s (ścisłe)
• Złagodzone: Domena i domena podpisana za pomocą DKIM należą do tej samej domeny organizacyjnej (np. mail.example.com i example.com są zgodne)
• Ścisłe: Domeny muszą być dokładnie zgodne
• Zalecenie: Zacznij od ustawienia adkim=r (łagodne). Przejdź do trybu ścisłego dopiero wtedy, gdy uzyskasz kontrolę nad wszystkimi źródłami podpisów.

aspf= (tryb wyrównywania SPF)

• Wartości: r (luźne, domyślne) lub s (ścisłe)
• Zmiana: Domena i domena Return-Path w rekordzie SPF należą do tej samej domeny organizacyjnej
• Ścisłe: Domeny muszą być dokładnie zgodne
• Zalecenie: Zacznij od ustawienia aspf=r. Przejdź na tryb ścisły dopiero wtedy, gdy uzyskasz kontrolę nad wszystkimi źródłami wysyłania.

t = (tryb testowy)

• Wartości: y (tryb testowy włączony) lub brak wartości (tryb testowy wyłączony)
• Po ustawieniu wartości t=y sygnalizuje to odbiorcom, aby zastosowali twoje zasady o jeden poziom niżej
• p = kwarantanna; t = y zachowuje się dla odbiorców tak samo jak p = brak
• p = odrzucenie; t = y działa dla odbiorców tak samo jak p = kwarantanna
• Jest to zamiennik przestarzałego tagu pct=
• Należy stosować przy przechodzeniu na bardziej rygorystyczną politykę: opublikować z t=y, monitorować raporty, a następnie usunąć t=y w celu egzekwowania zasad

ruf= (adres raportu kryminalistycznego)

• Format: ruf=mailto:[email protected]
• Wysyła w czasie rzeczywistym kopie wiadomości, których uwierzytelnienie nie powiodło się
• Ważna uwaga: Firmy Google, Microsoft i Yahoo nie wysyłają już raportów kryminalistycznych (zgodnie z RFC 9989). Tag ten można bezpiecznie umieścić, ale nie spowoduje to generowania raportów przez głównych odbiorców.
• Proszę to uwzględnić tylko wtedy, gdy dysponują Państwo zautomatyzowanym systemem do przetwarzania raportów kryminalistycznych

Znaki przestarzałe i usunięte (RFC 9989)

Te tagi były częścią RFC 7489, ale nie są już częścią standardu. Nie należy dodawać ich do nowych rekordów. Jeśli pojawiają się w istniejących rekordach, należy je usunąć przy następnej edycji DNS.

pct=

• Służyło do stosowania reguły wobec określonego odsetka komunikatów, których wysłanie nie powiodło się
• Wyniki uzyskane na różnych odbiornikach były niejednolite
• Zastąpienie: W przypadku stopniowego wdrażania należy zamiast tego użyć t=y
• Jeśli nadal znajduje się w starych rekordach, zostanie pominięte przez odbiorców zgodnych z RFC 9989

rf=

• Czy tag określający format raportu o awarii (który zawsze przyjmował tylko jedną wartość: afrf)
• Usunięto, ponieważ współczesne raportowanie wykorzystuje inny mechanizm

ri=

• Czy był to znacznik interwału raportowania
• Usunięto, ponieważ częstotliwości raportowania zostały ujednolicone

Krok 2: Zaloguj się do serwisu swojego dostawcy usług DNS

Zaloguj się do konsoli zarządzania DNS (GoDaddy, Cloudflare, Namecheap, cPanel, Route 53 itp.).

Krok 3: Dodaj rekord DMARC u dostawcy usług DNS

Znajdź opcję dodania nowego rekordu TXT, skopiuj i wklej wartość z narzędzia, a następnie kliknij ikonę „Zapisz”.

Procedura jest taka sama u wszystkich dostawców: dodaj nowy rekord TXT, ustaw nazwę na _dmarc, wklej swój rekord jako wartość i zapisz. Ścieżki nawigacyjne charakterystyczne dla poszczególnych dostawców oraz najczęstsze pułapki związane z każdym z nich przedstawiono w poniższej tabeli.

Krok 5: Poczekaj na propagację DNS

Propagacja zmian w systemie DNS na całym świecie może potrwać do 48 godzin, ale większość dostawców usług DNS zapewnia propagację w ciągu 1–2 godzin. Aby monitorować propagację w czasie rzeczywistym, możesz skorzystać z naszego narzędzia do sprawdzania propagacji DNS. Wystarczy wpisać nazwę domeny i poszukać rekordu TXT o nazwie _dmarc.

Krok 6: Sprawdź, czy konfiguracja DMARC działa

Po zakończeniu propagacji DNS sprawdź swój wpis za pomocą naszego narzędzia DMARC Checker.

1. Wpisz nazwę swojej domeny
2. Kliknij „Wyszukaj”
3. Powinieneś zobaczyć swój wpis wraz ze wszystkimi przetworzonymi tagami
4. Jeśli narzędzie sprawdzające wyświetla komunikat „Znaleziono rekord DMARC” wraz z Twoją polityką, oznacza to, że wszystko działa poprawnie

Jeśli pojawią się błędy lub po upływie 48 godzin rekord nie zostanie znaleziony, sprawdź wpis DNS pod kątem błędów składniowych i konfiguracyjnych.

Konfiguracja DMARC zgodnie z RFC 9989 – co się zmieniło w 2026 roku

W maju 2026 roku organizacja IETF opublikowała dokument RFC 9989, który zastąpił RFC 7489 jako oficjalny standard DMARC. Istniejące rekordy v=DMARC1 pozostają w pełni ważne, więc nie ma potrzeby przeprowadzania pilnej migracji. Istnieją jednak trzy zmiany, które mają wpływ na wszystkich, którzy konfigurują DMARC w chwili obecnej.

Co norma RFC 9989 oznacza dla Twojej konfiguracji DMARC

1. pct= jest obecnie przestarzałe

Tag „pct=” służył do stosowania zasad wobec określonego odsetka komunikatów, których wysłanie nie powiodło się. Dawał on niespójne wyniki u różnych odbiorców i nie jest już częścią standardu.

Działanie: Usuń „pct=” ze wszystkich nowych wpisów. Jeśli starsze wpisy zawierają ten element, usuń go przy następnej edycji DNS. Odbiorcy zignorują go, ale powoduje on niejasności.

2. np= to nowość

Tag np= (polityka dotycząca nieistniejących subdomen) pozwala chronić subdomeny, które nie istnieją. Atakujący mogą podszywać się pod losowe subdomeny (np. random123.example.com), aby ominąć kontrole DMARC. Ustawienie np=reject pozwala wyeliminować tę lukę bez żadnych kosztów.

Działanie: Jest to opcjonalne, ale można zdecydować się na dodanie tej opcji do wszystkich nowych rekordów.

3. t=y to nowy sposób wprowadzania zmian w polityce

Tag „t=y” sygnalizuje odbiorcom, aby stosowali określoną przez Ciebie politykę o jeden poziom niżej niż zadeklarowano. Dzięki temu możesz przetestować bardziej rygorystyczną politykę, zanim zaczniesz ją egzekwować.

• p = kwarantanna; t = y działa tak samo jak p = brak (odbiorcy nie stosują kwarantanny; dostarczają i zgłaszają)
• p = odrzucenie; t = y działa tak samo jak p = kwarantanna (odbiorcy poddają przesyłkę kwarantannie zamiast ją odrzucać)

Działanie: Przechodząc ze stanu p=none do stanu p=quarantine lub p=reject, należy najpierw ustawić t=y. Należy monitorować raporty przez 1–2 tygodnie. Gdy uzyskasz pewność, usuń t=y, aby wprowadzić zmianę w życie.

Jak wykorzystać t=y w przypadku stopniowego wdrażania

Oto dokładny przebieg pracy:

1. Stan obecny:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

2. Gdy będziesz gotowy do przetestowania kwarantanny, opublikuj:

v=DMARC1; p=kwarantanna; t=y; np=odrzucenie; sp=kwarantanna; rua=mailto:[email protected]

Odbiorcy traktują to jako p=brak, dostarczają wszystko i składają raport. Obserwujesz sytuację przez 1–2 tygodnie.

3. Upewnij się, że nie miało to wpływu na żadną prawidłową pocztę, a następnie usuń „t=y”, aby zastosować zmianę:

v=DMARC1; p=kwarantanna; np=odrzucenie; sp=kwarantanna; rua=mailto:[email protected]

4. Obecnie wiadomości, które nie dotarły, trafiają do folderu spam, podczas gdy na prawidłowe wiadomości nie ma to żadnego wpływu.

5. Gdy będziesz gotowy do przetestowania zasad odrzucania, opublikuj:

v=DMARC1; p=odrzuc; t=y; np=odrzuc; sp=odrzuc; rua=mailto:[email protected]

6. Odbiorcy traktują to jako p = kwarantanna. Należy obserwować przez 1–2 tygodnie.

7. Ostateczne wdrożenie: Usuń t=y:

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

8. Funkcja całkowitego odrzucenia jest teraz aktywna.

Jeśli na którymkolwiek etapie wystąpi błąd: usuń t=y, cofnij się o jeden poziom polityki, napraw nieprawidłowo działającego nadawcę, a następnie kontynuuj.

Jak bezpiecznie rozwijać swoją politykę DMARC

Większość niepowodzeń związanych z DMARC wynika z tego, że organizacje przechodzą od razu do ustawienia p=reject bez uprzedniej weryfikacji przepływu poczty. Prawdziwe wiadomości są blokowane, użytkownicy zgłaszają skargi, a właściciel domeny w panice cofa wprowadzone zmiany. W tej sekcji przedstawiono właściwe podejście: wdrażanie w trzech etapach, w ramach którego przed każdym kolejnym krokiem wykorzystuje się raporty zbiorcze w celu budowania zaufania.

Uwaga: W dokumencie RFC 9989 wyraźnie stwierdzono, że odbiorcy muszą traktować ustawienie p=reject jako p=quarantine w przypadku pośrednich przepływów poczty (przekazywanie dalej, listy mailingowe). W przypadku domen, których użytkownicy uczestniczą w listach mailingowych, p=quarantine stanowi bezpieczniejszą politykę stałego egzekwowania. W przypadku domen przeznaczonych wyłącznie do celów transakcyjnych lub marketingowych, bez skrzynek pocztowych użytkowników, właściwe jest ustawienie p=reject.

Faza 1: Monitorowanie (p = brak)

Czas trwania: co najmniej 2–4 tygodnie. W przypadku złożonych środowisk wysyłkowych (ponad 10 zewnętrznych nadawców) okres ten może być dłuższy.

Jak wygląda Twój wynik:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Co robić:

1. Opublikuj powyższy wpis

2. Poczekaj, aż odbiorcy prześlą zbiorcze raporty (zazwyczaj zaczynają to robić w ciągu 24–48 godzin)

3. Skorzystaj z naszego narzędzia do analizy raportów DMARC, aby przeglądać codzienne raporty

4. Poszukaj:

• Wszystkie znane źródła wysyłające, które pojawiają się w raportach
• Wskaźniki zgodności z SPF i DKIM dla poszczególnych nadawców
• Wszelkie wiadomości od nieznanych nadawców, których nie rozpoznajesz
• Stan zgodności (czy Twoi nadawcy spełniają wymagania dotyczące zgodności, czy nie?)

Kiedy przejść dalej:

• Wszyscy wiarygodni nadawcy spełniają wymagania SPF lub DKIM
• W raportach nie ma żadnych nieznanych źródeł
• Zgromadziłeś dane z co najmniej 2 tygodni, które są spójne
• Naprawiłeś wszystkie nieprawidłowo działające moduły wysyłające

Jeśli dopiero zaczynasz przygodę z raportami DMARC, zapoznaj się z naszym przewodnikiem dotyczącym interpretacji raportów DMARC, w którym znajdziesz proste wskazówki.

Faza 2: Kwarantanna (p = kwarantanna)

Czas trwania: 1–2 tygodnie w trybie testowym (t=y), a następnie w trybie ciągłym.

Krok A: Test z t=y (próba bez obciążenia)

Opublikuj:

v=DMARC1; p=kwarantanna; t=y; np=odrzucenie; sp=kwarantanna; rua=mailto:[email protected]

Gdy t = y, odbiorcy stosują zasady o jeden poziom niżej: kwarantanna działa tak, jakby jej nie było. Nieudane wiadomości są nadal dostarczane; otrzymujesz jedynie raporty pokazujące, które wiadomości zostałyby umieszczone w kwarantannie.

Obserwuj sytuację przez 1–2 tygodnie. Sprawdzaj raporty i monitoruj swoją skrzynkę odbiorczą. Zwróć uwagę na:

• Nadal przychodzą legalne wiadomości e-mail
• Raporty o awariach wskazujące, których nadawców dotyczyłaby ta sytuacja
• Typowe wskaźniki skarg dotyczących spamu

Krok B: Zastosowanie (usunięcie t=y)

Gdy już będziesz pewien, usuń t=y:

v=DMARC1; p=kwarantanna; np=odrzucenie; sp=kwarantanna; rua=mailto:[email protected]

Teraz wiadomości, których dostarczenie się nie powiodło, trafiają do folderu ze spamem. Prawdziwe wiadomości nadal docierają normalnie.

Bieżące monitorowanie:

• Co tydzień przeglądać raporty zbiorcze
• Sprawdzaj folder ze spamem pod kątem prawidłowych wiadomości
• Jeśli wystąpią problemy z prawidłowymi nadawcami: natychmiast przywróć ustawienie p=none, napraw problem z wyrównaniem, a następnie ponownie kontynuuj

Uwaga dotycząca kwalifikacji do BIMI: Jeśli chcesz korzystać z BIMI (Brand Indicators for Message Identification) w celu wyświetlania swojego logo w Gmailu, musisz mieć ustawienie p=quarantine lub p=reject. Ustawienie p=none nie kwalifikuje się do tego. To sprawia, że przyspieszenie wdrożenia tej polityki staje się jeszcze pilniejsze. Oto jak włączyć BIMI dla swojej domeny.

Faza 3: Odrzucenie (p = odrzucenie)

Czas trwania: 1–2 tygodnie przy t = y, a następnie w trybie ciągłym.

Krok A: Test z t=y (próba bez obciążenia)

Opublikuj:

v=DMARC1; p=reject; t=y; np=reject; sp=reject; rua=mailto:[email protected]

Gdy t = y, odbiorcy traktują wiadomości odrzucone jako znajdujące się w kwarantannie. Nieudane wiadomości trafiają do folderu spam, a nie są od razu odrzucane. Należy monitorować sytuację przez 1–2 tygodnie.

Krok B: Zastosowanie (usunięcie t=y)

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

Obecnie wiadomości, których dostarczenie nie powiodło się, są od razu odrzucane. Nadawca otrzymuje komunikat o odrzuceniu wiadomości.

Zalecenia dotyczące polityki:

• Jeśli w Twojej domenie znajdują się skrzynki pocztowe użytkowników, którzy figurują na listach mailingowych (NAR, MLS, listy stowarzyszeń itp.), jako zasadę egzekwowania zastosuj opcję p=quarantine.
• Jeśli Twoja domena służy wyłącznie do obsługi transakcji (SaaS, płatności, fintech, e-maile marketingowe bez skrzynek pocztowych użytkowników): użyj p=reject.

Rozwiązywanie problemów związanych z konfiguracją DMARC: typowe problemy i sposoby ich rozwiązywania

Problem nr 1: Komunikat „Nie znaleziono rekordu DMARC” podczas sprawdzania

Dlaczego tak się dzieje: propagacja DNS nie została jeszcze zakończona lub wpisałeś nieprawidłową nazwę hosta.

Jak to naprawić:

1. Po opublikowaniu należy odczekać 24–72 godziny
2. Upewnij się, że nazwa hosta brzmi dokładnie _dmarc (a nie _dmarc.twojadomena.com, jak to bywa w niektórych narzędziach – sprawdź u swojego dostawcy)
3. Skorzystaj z naszego narzędzia do sprawdzania propagacji DNS, aby zweryfikować stan propagacji
4. Spróbuj ponownie skorzystać z naszego narzędzia do sprawdzania zgodności z DMARC

Problem nr 2: Brak zgodności między SPF a DKIM

Dlaczego tak się dzieje: Domena podana w nagłówku „From:” nie zgadza się z domeną uwierzytelnioną przez SPF lub DKIM.

Przykładowa awaria:

• W polu „Od:” widnieje adres [email protected]
• Domeną uwierzytelnioną przez SPF jest mail.otherdomain.com
• Domeną podpisywania DKIM jest newsletter.anotherdomain.com
• Wynik: Brak zgodności. DMARC nie przeszedł testu.

Jak to naprawić:

1. Zacznij od ustawienia opcji „rozluźnionego dopasowania” (adkim=r; aspf=r) w swoim wpisie. Umożliwi to dopasowanie subdomen.

2. Skorzystaj z naszego narzędzia do sprawdzania DKIM, aby zweryfikować domenę podpisującą każdego nadawcy

3. Skorzystaj z naszego narzędzia do sprawdzania SPF, aby zweryfikować, czy adres nadawcy figuruje w rekordzie SPF

4. W przypadku każdego nadawcy, u którego wystąpiły problemy, poproś dostawcę o skonfigurowanie domeny. Na przykład:

• „Proszę włączyć podpisywanie DKIM dla domeny example.com (nie subdomeny)”
• „Proszę użyć domeny example.com w polu Return-Path/envelope-from”

5. Gdy wszyscy nadawcy spełnią wymagania w trybie łagodnego dopasowania, w razie potrzeby można przejść do trybu ścisłego (adkim=s; aspf=s)

Problem nr 3: Nieudane uwierzytelnienie nadawcy zewnętrznego

Dlaczego tak się dzieje: System ESP, CRM lub platforma marketingowa wysyła wiadomości e-mail z Twojej domeny, ale nie jest uwzględniona w Twoim rekordzie SPF i/lub nie ma włączonego DKIM.

Jak to naprawić:

W przypadku błędów związanych z SPF:

1. Znajdź wpis SPF nadawcy w jego dokumentacji (np. include:sendgrid.net)

2. Dodaj to do swojego rekordu SPF: v=spf1 include:sendgrid.net include:mailchimp.com ~all

3. Sprawdź to za pomocą naszego narzędzia do sprawdzania SPF

W przypadku błędów DKIM:

1. Poproś dostawcę o włączenie niestandardowego DKIM dla Twojej domeny

2. Opublikuj dostarczony przez nich klucz publiczny DKIM (zazwyczaj w formacie: selector._domainkey.yourdomain.com)

3. Sprawdź to za pomocą naszego narzędzia DKIM Checker

Problem nr 4: Wiele rekordów SPF lub przekroczenie limitu 10 zapytań SPF

1. Więcej niż jeden rekord SPF: Posiadanie dwóch rekordów SPF typu TXT w tej samej domenie całkowicie uniemożliwia działanie mechanizmu SPF, a odbiorcy zignorują oba rekordy.

Jak to naprawić: Połącz swoje rekordy SPF w jeden, ponieważ dla każdej domeny można mieć tylko jeden rekord SPF typu TXT.

Przykład:

• Stary wpis nr 1: v=spf1 include:sendgrid.net ~all
• Stary rekord 2: v=spf1 include:mailchimp.com ~all
• Nowy połączony rekord: v=spf1 include:sendgrid.net include:mailchimp.com ~all

2. Ponad 10 zapytań DNS: Każde z nich może wymagać od 1 do 3 zapytań DNS. Jeśli liczba ta przekroczy 10, weryfikacja SPF zakończy się niepowodzeniem dla niektórych nadawców.

Jak to naprawić: Skorzystaj z naszej usługi SPF, aby dynamicznie zoptymalizować swój rekord. Dzięki temu instrukcje „include:” zostaną zastąpione konkretnymi adresami IP, co ograniczy liczbę operacji wyszukiwania.

Przykład:

• Wcześniej (ponad 10 wyszukiwań): v=spf1 include:sendgrid.net include:mailchimp.com include:klaviyo.com include:hubspot.com ~all
• Po optymalizacji: v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 ~all

Problem nr 5: Prawdziwa poczta trafia do folderu „Spam” po umieszczeniu w kwarantannie

Dlaczego tak się dzieje: Przeszedłeś do etapu p=kwarantanna, zanim sprawdziłeś, czy wszyscy wiarygodni nadawcy przeszli proces uwierzytelniania.

Jak to naprawić:

1. Natychmiast przywróć ustawienie p=none
2. Przejrzyj swoje zbiorcze raporty, aby ustalić, który nadawca nie wywiązuje się ze swoich zobowiązań
3. Popraw ich uwierzytelnianie (dostosowanie SPF lub DKIM)
4. Przejść ponownie do etapu p = kwarantanna, ale przeprowadzić test z t = y i obserwować przez 1–2 tygodnie przed wprowadzeniem restrykcji

Problem nr 6: Błędy składniowe w rekordach DMARC

Przyczyny: błąd w zapisie, brakujące średniki lub nieobsługiwane tagi

Jak to naprawić:

1. Sprawdź to za pomocą naszego narzędzia DMARC Checker, które wskaże błędy składniowe
2. Skorzystaj z naszego generatora DMARC, aby odtworzyć rekord, zamiast edytować go ręcznie
3. Skopiuj wygenerowany wpis i wklej go u swojego dostawcy usług DNS

Słowa końcowe

Prawidłowa konfiguracja protokołu DMARC nie jest już kwestią opcjonalną. Stałe stosowanie polityki odrzucania przez Gmaila, wymagania serwisów Yahoo i Microsoftu, zalecenia normy PCI DSS w wersji 4.0 oraz wytyczne CISA BOD 18-01 sprawiają, że wdrożenie protokołu DMARC stało się koniecznością z punktu widzenia zgodności z przepisami.

Bezpieczną i niezawodną metodą jest powolne wprowadzanie zmian, ciągła weryfikacja i odpowiedzialne egzekwowanie zasad. Jeśli jednak zależy Ci na szybszym i łatwiejszym zarządzaniu DMARC z automatycznym przetwarzaniem raportów, monitorowaniem zgodności i stałym wsparciem, rozważ skorzystanie z hostowanej platformy DMARC, takiej jak PowerDMARC, która zajmuje się konfiguracją, skalowaniem i egzekwowaniem zasad, dzięki czemu możesz skupić się na bezpieczeństwie. Rozpocznij bezpłatny okres próbny już dziś lub umów się na prezentację, aby zabezpieczyć swoją domenę już teraz.

Najczęściej zadawane pytania

Jak długo trwa konfiguracja DMARC?

Wstępna konfiguracja rekordów DNS zajmuje kilka minut. Propagacja zmian w systemie DNS może potrwać do 72 godzin (zwykle 1–2 godziny). Pełne wdrożenie (osiągnięcie stanu p=reject z odpowiednim poziomem pewności) trwa zazwyczaj 4–8 tygodni, w zależności od liczby źródeł wysyłających oraz tempa rozwiązywania problemów związanych z dostosowaniem.

Czy konfiguracja DMARC wpływa na dostarczalność wiadomości e-mail?

Gdy p=none, wpływ na dostarczalność jest zerowy, ponieważ tryb monitorowania nie przewiduje żadnych działań egzekucyjnych. Gdy p=quarantine lub p=reject, dotyczy to wyłącznie wiadomości nieautoryzowanych i niezgodnych z polityką. Nie ma to wpływu na wiadomości prawidłowo uwierzytelnione, a ich dostarczalność często ulega poprawie. DMARC może w dłuższej perspektywie poprawić trafność do skrzynki odbiorczej poprzez budowanie reputacji domeny wśród dostawców usług pocztowych.

Jak skonfigurować DMARC dla wielu domen?

Konfigurując DMARC dla wielu domen, należy pamiętać, że każda domena wymaga własnego rekordu TXT DMARC w lokalizacji _dmarc.[domena].

Przykład:

• Dziedzina 1: rekord TXT dla domeny _dmarc.example.com
• Dziedzina 2: rekord TXT dla domeny _dmarc.example.org

W przypadku organizacji zarządzających wieloma domenami hostowana platforma DMARC umożliwia zarządzanie wszystkimi rekordami z poziomu jednego pulpitu nawigacyjnego, co ułatwia skalowanie.

Czym jest dostosowanie DMARC?

Dopasowanie oznacza, że domena w nagłówku „From:” musi być zgodna z domeną uwierzytelnioną przez SPF lub DKIM. Dopasowanie łagodne (ustawienie domyślne, adkim=r; aspf=r) dopuszcza zgodność z domenami organizacyjnymi, natomiast dopasowanie ścisłe (adkim=s; aspf=s) wymaga dokładnej zgodności.

• O
• Latest Posts

Maitham Al Lawati

Ekspert ds. cyberbezpieczeństwa, dyrektor generalny w PowerDMARC

Maitham jest przedsiębiorcą technologicznym, ekspertem ds. cyberbezpieczeństwa, dyrektorem generalnym i założycielem PowerDMARC z ponad 15-letnim doświadczeniem w branży. Maitham posiada tytuł Global MBA Uniwersytetu w Manchesterze oraz różne certyfikaty zawodowe, w tym CISSP, CISM, CRISC i ISC2 CCSP.

Najnowsze posty autorstwa Maitham Al Lawati (zobacz wszystkie)

• Jak skonfigurować DMARC: Kompletny przewodnik konfiguracji krok po kroku (2026) - 20 czerwca 2026 r.
• Jak interpretować raporty DMARC: Kompletny przewodnik po wskaźnikach RUA i RUF – 10 czerwca 2026 r.
• Czym jest DMARC? Definicja, zasada działania i znaczenie – 28 kwietnia 2026 r.