Spis treści 8 sekcji

DMARC korzysta z SPF i DKIM, by uwierzytelnić pocztę i wskazać, co zrobić z wiadomościami, które nie przejdą kontroli.1 W tym poradniku opisujemy konfigurację rekordów DNS, sprawdzanie wyników, wpływ uwierzytelniania na dostarczalność oraz rozgrzewanie domeny przed wysyłką. Od 2024 roku Gmail wymaga SPF, DKIM i DMARC od nadawców wysyłających ponad 5000 wiadomości dziennie na konta Gmail2.

Czym jest DMARC i jak chroni domenę przed podszywaniem się?

DMARC pomaga chronić domenę przed spoofingiem – podszywaniem się pod adres nadawcy. Porównuje domenę widoczną dla odbiorcy z domeną, której użyto do uwierzytelnienia wiadomości. Dopuszcza dopasowanie ścisłe, wymagające identycznych domen, oraz elastyczne, oparte na wspólnej domenie organizacyjnej3.

Phishing to próba nakłonienia odbiorcy fałszywą wiadomością do ujawnienia danych lub wykonania określonego działania. Gdy oszust podszyje się pod firmową domenę, mail może wyglądać jak korespondencja od marki. CERT Polska odnotował w 2024 roku 40 120 incydentów phishingowych4.

DMARC utrudnia skuteczne podszywanie się pod chronioną domenę. Nie ocenia jednak treści maila ani nie gwarantuje, że poprawnie uwierzytelniona wiadomość ominie folder spamu5.

Co odróżnia DMARC od SPF i DKIM?

DMARC porównuje domenę z pola From z domeną uwierzytelnioną technicznie. SPF wskazuje serwery uprawnione do wysyłania poczty w imieniu domeny. DKIM pozwala z kolei zweryfikować podpis kryptograficzny dodany przez nadawcę. Przy kontroli SPF obowiązuje limit 10 mechanizmów i modyfikatorów powodujących zapytania DNS6.

Dlaczego ochrona domeny ma znaczenie dla marki?

Ochrona domeny utrudnia użycie firmowego adresu jako pozornego nadawcy fałszywego maila. Odbiorca widzi domenę w polu From i może uznać wiadomość za korespondencję od firmy. Takie podszycie naraża go na phishing, a markę – na skojarzenie z oszustwem. Według APWG w 2024 roku odnotowano 3,76 mln ataków phishingowych7.

Dlaczego wiadomość może nie przejść kontroli DMARC?

Wiadomość może nie przejść kontroli DMARC, mimo że jej podpis DKIM jest poprawny. Dzieje się tak, gdy domena z pola From nie odpowiada domenie uwierzytelnionej przez SPF ani domenie podpisu DKIM. W takim przypadku DMARC uznaje wiadomość za nieuwierzytelnioną8. Sam pozytywny wynik testu DKIM nie przesądza więc o wyniku DMARC5.

Przy poprawnym DKIM i nieudanym DMARC trzeba sprawdzić następujące elementy:9

  • Domena w polu From to adres nadawcy widoczny dla odbiorcy. Porównaj ją z domeną podpisu DKIM.
  • Podpis DKIM wskazuje domenę, która podpisała wiadomość. Sprawdź jej zgodność z domeną w polu From.
  • Ścieżka wysyłki obejmuje system przekazujący wiadomość. Ustal, czy wysyła ją w imieniu właściwej domeny.

Czym jest uwierzytelnianie DMARC i jak je skonfigurować?

Uwierzytelnianie DMARC wymaga przygotowania SPF i DKIM oraz opublikowania polityki DMARC w DNS. Liczy się także zgodność domen: domena użyta do uwierzytelnienia musi odpowiadać tej, którą widzi odbiorca. Po uruchomieniu wysyłki kontroluj wyniki każdego systemu korzystającego z domeny. Dla jednej domeny publikuj najwyżej jeden rekord DMARC; jeśli rekordów jest więcej, odbiorca nie zastosuje polityki3.

Co DMARC sprawdza w wiadomości e-mail?

DMARC sprawdza domenę z pola RFC5322.From, które klient pocztowy pokazuje odbiorcy.1 Następnie porównuje ją z domeną powiązaną z wynikiem SPF lub podpisem DKIM. Nawet poprawny wynik jednej z tych metod nie wystarczy, jeśli dotyczy domeny niezgodnej z widocznym adresem nadawcy5.

Jak przebiega uwierzytelnianie nadawcy?

DMARC łączy wynik SPF lub DKIM z kontrolą zgodności domen. Serwer odbiorcy sprawdza poniższe elementy. Pozytywny wynik DMARC wymaga przejścia uwierzytelnienia i kontroli zgodności przez co najmniej jedną metodę: SPF albo DKIM3.

  • SPF sprawdza serwer wysyłający względem domeny użytej w ścieżce pocztowej.
  • DKIM sprawdza podpis wiadomości i wskazuje domenę podpisującą.
  • Zgodność domen określa, czy domena metody zakończonej sukcesem odpowiada domenie widocznej dla odbiorcy.

Wiadomość przechodzi DMARC, gdy SPF lub DKIM daje wynik pozytywny, a domena tej metody jest zgodna z domeną nadawcy. Sukces obu metod nie jest potrzebny1. Wystarczy poprawny SPF lub DKIM z domeną zgodną z polem From3.

Tabela pokazuje, którą domenę SPF i DKIM porównują z adresem nadawcy w DMARC. Dla SPF jest to RFC5321.MailFrom, a dla DKIM domena z parametru d= poprawnego podpisu; punktem odniesienia pozostaje RFC5322.From3.

MetodaKontrolowany elementDomena porównywana z adresem nadawcy
SPFSerwer wysyłającyDomena RFC5321.MailFrom
DKIMPodpis wiadomościDomena z parametru d=

Jakie elementy techniczne są potrzebne do wdrożenia?

Do wdrożenia DMARC potrzebujesz dostępu do DNS oraz listy systemów wysyłających pocztę z domeny. Rekord SPF określa uprawnione serwery, a konfiguracja DKIM umożliwia podpisywanie wiadomości i sprawdzanie podpisów. Rekord DMARC przekazuje odbiorcy politykę postępowania z mailami, które nie przejdą kontroli. Rekord publikowany pod nazwą _dmarc wymaga dwóch tagów: v i p3.

Jak skonfigurować politykę dla domeny?

Konfigurację polityki DMARC zacznij od ustalenia, które systemy wysyłają firmową pocztę. Dopiero potem dodaj rekord do DNS – łatwiej będzie odróżnić legalną wysyłkę od prób podszycia się pod nadawcę. Do wyboru są trzy wartości polityki: p=none, p=quarantine i p=reject3.

  • Systemy wysyłkowe przypisz do domen, których używają w adresie nadawcy.
  • SPF i DKIM skonfiguruj dla używanych systemów, uwzględniając zgodność domen.
  • Rekord DMARC opublikuj w DNS z polityką dopasowaną do etapu wdrożenia.
  • Wyniki uwierzytelniania przeanalizuj przed zaostrzeniem polityki, by wykryć błędnie skonfigurowaną legalną wysyłkę.

Przed ograniczeniem dostarczania wiadomości polityka DMARC powinna uwzględniać wszystkie ustalone źródła firmowej poczty1.

SPF, DKIM i DMARC w praktyce: od uwierzytelniania do wyboru polityki

SPF i DKIM uwierzytelniają wysyłkę, a polityka DMARC wskazuje, co zrobić z wiadomością, która nie przejdzie kontroli. Jej wybór zależy od rozpoznania legalnych źródeł poczty i poprawnego skonfigurowania ich dla domeny. Tag pct przyjmuje wartości od 0 do 100 i pozwala stopniowo obejmować wiadomości wybraną polityką DMARC3.

Jak SPF, DKIM i DMARC współpracują ze sobą?

SPF, DKIM i DMARC pozwalają odbiorcy sprawdzić serwer wysyłający, podpis wiadomości oraz zgodność domeny nadawcy. Przy weryfikacji podpisu DKIM klucz RSA musi mieć co najmniej 1024 bity10. Każda z metod pełni inną rolę:

  • SPF pozwala odbiorcy sprawdzić, czy serwer może wysyłać pocztę w imieniu domeny użytej w ścieżce pocztowej.
  • DKIM pozwala odbiorcy zweryfikować podpis wiadomości oraz domenę, która ją podpisała.
  • DMARC zestawia wynik uwierzytelniania z domeną nadawcy i stosuje opublikowaną politykę.

Wynik DMARC zależy nie tylko od konfiguracji serwera, lecz także od domen używanych przez systemy wysyłkowe. Z polem From może być zgodna domena RFC5321.MailFrom uwierzytelniona przez SPF albo domena z parametru d= podpisu DKIM3.

Kiedy wybrać politykę none, quarantine lub reject?

Polityka p=none służy obserwacji wysyłki. p=quarantine oznacza żądanie skierowania nieuwierzytelnionych wiadomości do spamu, a p=reject – żądanie ich odrzucenia. Tabela porównuje działanie tych polityk wobec maila, który nie przejdzie DMARC. Bez tagu pct domyślna wartość wynosi 100%, więc wybrana polityka obejmuje wszystkie wiadomości niespełniające warunków weryfikacji3.

PolitykaDziałanie wobec wiadomościZastosowanie
p=noneRaportowanie bez żądania ograniczenia dostarczeniaRozpoznanie źródeł wysyłki
p=quarantineŻądanie skierowania do spamuOgraniczenie dostarczania nieuwierzytelnionych wiadomości
p=rejectŻądanie odrzuceniaOdrzucanie nieuwierzytelnionych wiadomości

Nagłe włączenie p=quarantine lub p=reject może zakłócić ważną wysyłkę, także newsletter obsługiwany przez zewnętrznego dostawcę.1 Zanim wybierzesz politykę ograniczającą dostarczanie, uwzględnij takie systemy.

Jak wygląda konfiguracja na przykładzie EmailLabs?

EmailLabs udostępnia w panelu funkcję „Autoryzacja nadawców” z narzędziami i wskazówkami dotyczącymi rekordu DMARC.11 Wdrożenie wymaga ustalenia domeny używanej do wysyłki, przygotowania uwierzytelniania i opublikowania rekordu DMARC w jej DNS. Wyniki trzeba też ocenić dla pozostałych systemów korzystających z tej samej domeny.

idea4me.pl zaleca, by SPF i DKIM były aktywne przez 48 godzin przed konfiguracją DMARC.12 To wskazówka dotycząca kolejności wdrożenia, nie parametr funkcji EmailLabs.

Czy mała firma bez newslettera potrzebuje ochrony domeny?

Mała firma bez newslettera także potrzebuje ochrony domeny. Od firmy prowadzącej newsletter różni ją przede wszystkim liczba systemów pocztowych, które musi uwzględnić. Tabela zestawia źródła wiadomości i ryzyko pominięcia legalnego nadawcy:

FirmaWiadomości i źródła wysyłkiCo trzeba uwzględnić
Mała firma bez newsletteraKorespondencja firmowa z używanej pocztyUżywana poczta; bez konfiguracji nieużywanego systemu newsletterowego
Firma z newsletteremKorespondencja firmowa oraz wiadomości do listy mailingowejOba źródła; pominięcie systemu wysyłkowego może zakłócić newsletter
  • Mała firma bez newslettera wysyła korespondencję firmową i musi uwzględnić używaną pocztę. Nie musi konfigurować systemu newsletterowego, z którego nie korzysta.
  • Firma z newsletterem wysyła pocztę firmową i wiadomości do listy mailingowej. Musi uwzględnić oba źródła, bo pominięcie systemu wysyłkowego może zakłócić newsletter.

Brak newslettera nie usuwa ryzyka: ktoś nadal może podszyć się pod firmowy adres.

Raporty uwierzytelniania: korzyści i ograniczenia

Raporty DMARC pomagają rozpoznać źródła wysyłki i próby podszycia się pod domenę. Ich wyniki trzeba jednak zestawić z systemami używanymi przez firmę.11 Odbierające MTA, czyli serwery przyjmujące pocztę, przekazują w raportach zbiorczych wyniki kontroli wiadomości. PowerDMARC opisuje otrzymywanie takich raportów z częstotliwością 1 dnia.13,14

Co pokazują raporty o wiadomościach wysyłanych z domeny?

Raporty DMARC pokazują źródła ruchu, wyniki uwierzytelniania oraz zastosowaną politykę. Każde źródło porównaj z firmową pocztą i używaną platformą newsletterową. Sam raport nie dowodzi, że firma upoważniła danego nadawcę. DMARCeye zbiera i interpretuje raporty DMARC oraz prezentuje w panelu informacje o źródłach i legalności ruchu e-mail.15

Jakie są ograniczenia mechanizmu uwierzytelniania?

DMARC ocenia uwierzytelnienie domeny, nie prawdziwość treści maila ani intencje nadawcy. Legalny system z błędną konfiguracją może nie przejść kontroli; negatywny wynik nie jest więc dowodem oszustwa. Kaspersky opisuje dodatkową analizę wiadomości, które nie przeszły DMARC, mającą ograniczać fałszywe alarmy.16

Technologia Kaspersky uzupełniająca DMARC była trenowana na zbiorze około 140 milionów wiadomości e-mail.16 Spam stanowił 40% tego zbioru treningowego. Ten udział nie mierzy skuteczności DMARC ani odsetka spamu w poczcie firmy16.

Jak sprawdzić rekord i odczytać wyniki z raportów?

Rekord DMARC i raporty sprawdzaj osobno. Rekord pokazuje opublikowaną politykę, a raporty – wyniki dla ruchu pocztowego. Analizę przeprowadź w tej kolejności:

  • Odczyt DNS pozwala sprawdzić, czy rekord DMARC znajduje się pod właściwą domeną i jaką zawiera politykę. Narzędzie typu dmarc checker kontroluje rekord, ale nie ustala, które źródła należą do firmy.
  • Wyniki raportów wskazują źródła wysyłki i wiadomości, które nie przeszły kontroli. Porównaj te źródła z firmową listą systemów.
  • Nieznane źródła mogą oznaczać pominięty system firmowy albo próbę podszycia się pod domenę. Przed zmianą polityki ustal właściciela każdego legalnego źródła.

Analiza raportów przed włączeniem odrzucania zmniejsza ryzyko zablokowania pominiętej wysyłki firmowej17.

Jak ograniczać skutki błędów i ograniczeń mechanizmu?

Ograniczysz błędy uwierzytelniania, jeśli poprawisz konfigurację legalnych nadawców przed zaostrzeniem polityki. Podejrzane wiadomości oceniaj oddzielnie. Działania obejmują:1

  • Inwentaryzacja wysyłki przypisuje firmową pocztę, wiadomości transakcyjne i newsletter do używanych domen oraz systemów.
  • Korekta konfiguracji dotyczy źródła, które firma uznaje za legalne, ale którego wiadomości nie przechodzą kontroli.
  • Kontrola po zmianach pomaga wykryć problemy po dodaniu systemu wysyłkowego lub zmianie ustawień domeny.

Raport DMARC wskazuje problem z uwierzytelnieniem. Zanim zmienisz konfigurację, ustal, kto faktycznie wysłał wiadomość.

Rekord DMARC w DNS: składnia i publikacja

Rekord DMARC to publiczny rekord TXT w DNS, czyli systemie nazw domen. Nie jest ustawieniem przechowywanym na serwerze pocztowym13. Jego wartość zawiera znaczniki polityki domeny i sposobu otrzymywania raportów. Do publikacji potrzebny jest dostęp do strefy DNS domeny używanej do wysyłki.

Jak wygląda składnia rekordu?

Rekord DMARC składa się z par znacznik=wartość oddzielonych średnikami. Znacznik v podaje wersję protokołu, p – politykę wobec wiadomości niespełniających wymagań, a rua – adres raportów zbiorczych.8 Podstawowy zapis polityki obserwacji to v=DMARC1; p=none.

Znaczniki opcjonalne pozwalają ustalić udział wiadomości objętych polityką przez pct. Można też określić zasady dopasowania domen: dla DKIM przez adkim, a dla SPF przez aspf.12 Znaczniki te wpływają na stosowanie polityki i ocenę zgodności, nie na miejsce publikacji rekordu.

Jak przechodzić od p=none do p=reject?

Przejście od p=none do p=reject poprzedź analizą raportów i poprawieniem konfiguracji legalnych usług wysyłkowych. Wdrażanie rozpoczęte od p=none z raportami daje czas na korekty przed kwarantanną lub odrzucaniem.1

  • Etap obserwacji pozwala ustalić, które systemy wysyłają pocztę z domeny i jakie osiągają wyniki uwierzytelniania.
  • Etap korekty obejmuje poprawienie ustawień rozpoznanych usług, których wiadomości nie przechodzą kontroli1.
  • Etap egzekwowania oznacza zaostrzenie polityki po uwzględnieniu legalnych źródeł wysyłki.

Jak utworzyć i opublikować rekord w DNS?

Rekord DMARC dodaj w strefie DNS jako rekord TXT pod nazwą _dmarc właściwej domeny.

  • Strefa DNS musi odpowiadać domenie widocznej w adresie nadawcy.
  • Nazwa rekordu musi wskazywać _dmarc w wybranej strefie.
  • Wartość TXT musi zawierać poprawnie zapisane znaczniki polityki.
  • Odczyt DNS po publikacji pozwala sprawdzić, czy rekord widać pod zamierzoną nazwą.

Czy kolejność tagów w rekordzie ma znaczenie?

Kolejność znaczników DMARC nie zmienia ich znaczenia, o ile wymagane v i p są obecne i poprawnie zapisane.13 Przy porównywaniu rekordów zwracaj uwagę przede wszystkim na nazwy, wartości i składnię znaczników. Dla czytelności zapis można zacząć od wersji i polityki, a potem podać pozostałe ustawienia.

Poprawny rekord TXT musi znajdować się pod właściwą nazwą DNS i zawierać politykę odpowiednią do etapu wdrożenia.

SPF według RFC 7208: zasady autoryzacji nadawców

SPF określa, które serwery mogą wysyłać pocztę w imieniu domeny użytej w ścieżce doręczenia. Właściciel domeny publikuje reguły w rekordzie TXT w DNS. Serwer odbiorcy porównuje je z adresem serwera, który nawiązał połączenie. Kontrola SPF dotyczy domeny ścieżki pocztowej, a nie samego adresu wyświetlanego odbiorcy.

Rekord SPF powinien obejmować serwery firmowej poczty i używane usługi wysyłkowe. Pominięty legalny system może uzyskać negatywny wynik kontroli. Pozostawienie nieużywanego systemu niepotrzebnie poszerza zaś zakres autoryzacji. Przy konfiguracji obowiązuje limit 10 mechanizmów i modyfikatorów powodujących zapytania DNS6.

SPF check lub spf checker pozwala odczytać rekord i sprawdzić jego składnię. Poprawny zapis w DNS nie dowodzi jednak, że konkretny mail przeszedł SPF. Wynik zależy również od serwera, który wysłał wiadomość, oraz domeny użytej w ścieżce pocztowej.

Przekazywanie wiadomości przez inny serwer może zmienić serwer oceniany przez SPF i doprowadzić do niepowodzenia kontroli. Dostarczalność, czyli zdolność maila do dotarcia do skrzynki odbiorczej, zależy też od reputacji nadawcy i sposobu wysyłki. Przy nowej domenie stopniowe zwiększanie liczby wiadomości – rozgrzewanie domeny – uzupełnia uwierzytelnianie, ale go nie zastępuje.

SPF potwierdza uprawnienie serwera do wysyłki w imieniu domeny ścieżki pocztowej. Sam poprawny rekord nie gwarantuje miejsca poza folderem spamu.

Standardy uwierzytelniania poczty: podpisy i zasady dla domeny

DKIM według RFC 6376 opisuje podpisywanie wiadomości. DMARC według RFC 7489 określa z kolei zasady oceny uwierzytelnienia domeny nadawcy. Podpis pozwala sprawdzić, czy podpisane elementy maila nie zmieniły się w sposób unieważniający weryfikację. Polityka domeny odnosi wynik tej kontroli do adresu nadawcy.

Jak działa podpis DKIM według RFC 6376?

System wysyłający tworzy podpis DKIM kluczem prywatnym. Serwer odbiorcy sprawdza go kluczem publicznym opublikowanym w DNS. Proces wygląda następująco:

  • System wysyłający podpisuje wybrane nagłówki i treść wiadomości kluczem prywatnym.
  • Selektor DKIM wskazuje odbiorcy klucz publiczny w DNS potrzebny do weryfikacji podpisu.
  • Serwer odbiorcy oblicza wynik weryfikacji na podstawie otrzymanej wiadomości i opublikowanego klucza.

DKIM check lub dkim test konkretnej wiadomości pozwala ocenić jej podpis. Sam odczyt klucza w DNS nie potwierdza, że system wysyłkowy podpisał mail. Przy weryfikacji podpisu klucz RSA musi mieć co najmniej 1024 bity10.

Jakie zasady określa DMARC według RFC 7489?

DMARC według RFC 7489 określa, jak oceniać zgodność domeny nadawcy z wynikiem uwierzytelniania i przekazywać wyniki tej oceny. Standard rozróżnia dopasowanie łagodne, które dopuszcza odpowiednią subdomenę tej samej domeny organizacyjnej, oraz dopasowanie ścisłe, wymagające identycznej domeny. Właściciel domeny może w ten sposób ustalić zasady oceny wiadomości wysyłanych przez subdomeny.

DKIM weryfikuje podpis wiadomości. DMARC odnosi wynik uwierzytelniania do domeny nadawcy.

Źródła

  1. ↑SPF, DKIM i DMARC – Baza wiedzy CERT Polska https://wiedza.cert.pl/odpornosc-infrastruktury/bezpieczenstwo-uslug/poczta-spf-dkim-dmarc/
  2. ↑Google, Wskazówki dla nadawców poczty ([support.google.com](support.google.com https://support.google.com/mail/answer/81126?hl=en
  3. ↑RFC 7489 ([rfc-editor.org](rfc-editor.org https://www.rfc-editor.org/rfc/rfc7489.html
  4. ↑CERT Polska, Raport roczny 2024 ([cert.pl](cert.pl https://cert.pl/uploads/docs/Raport_CP_2024.pdf
  5. ↑RFC 9989 (IETF) oraz Pomoc Gmail. ([rfc-editor.org](rfc-editor.org https://www.rfc-editor.org/info/rfc9989/
  6. ↑RFC 7208 ([rfc-editor.org](rfc-editor.org https://www.rfc-editor.org/rfc/rfc7208.html
  7. ↑APWG, Phishing Activity Trends Report, 4th Quarter 2025 ([docs.apwg.org](docs.apwg.org https://docs.apwg.org/reports/apwg_trends_report_q4_2025.pdf
  8. ↑SPF, DKIM i DMARC: jak ustawić pocztę firmowej domeny https://www.web-systems.pl/spf-dkim-dmarc-poczta-firmowa/
  9. ↑Microsoft Learn, konfiguracja DMARC. ([learn.microsoft.com](learn.microsoft.com https://learn.microsoft.com/pl-pl/defender-office-365/email-authentication-dmarc-configure
  10. ↑RFC 8301 ([rfc-editor.org](rfc-editor.org https://www.rfc-editor.org/rfc/rfc8301.html
  11. ↑DMARC (Domain-based Message Authentication, Reporting & Conformance) | EmailLabs Panel https://docs.emaillabs.io/centrum-bezpieczenstwa/bezpieczenstwo-i-autoryzacja-wysylek-e-mail/dmarc-domain-based-message-authentication-reporting-and-conformance
  12. ↑DMARC – uzupełniająca metoda uwierzytelniania poczty https://idea4me.pl/blog/technologie-it/dmarc—uzupelniajaca-metoda-uwierzytelniania-poczty
  13. ↑Jak działa DMARC? | Uwierzytelnianie wiadomości w domenie https://powerdmarc.com/pl/how-does-dmarc-work/
  14. ↑PowerDMARC, opis raportów zbiorczych DMARC. ([powerdmarc.com](powerdmarc.com https://powerdmarc.com/pl/dmarc-reporting/
  15. ↑Co jest DMARC? Klucz do bezpieczeństwa i dostarczalności poczty e-mail https://dmarceye.com/pl/co-jest-dmarc
  16. ↑Jak naprawić mechanizm DMARC | Oficjalny blog Kaspersky https://plblog.kaspersky.com/how-to-cure-dmarc/13954/
  17. ↑Google Workspace Admin Help, zalecane stopniowe wdrażanie DMARC. ([support.google.com](support.google.com https://support.google.com/a/answer/10032473

Ceny i warunki sprawdzone u źródeł: październik 2026.