SPF, DKIM i DMARC – uwierzytelnianie poczty, różnice, wdrożenie w DNS i weryfikacja

Jedna źle ustawiona domena potrafi otworzyć drogę do podszywania się pod firmę. SPF, DKIM i DMARC razem pomagają odsiać legalną pocztę od phishingu i nadużyć. Dają serwerom odbiorczym konkretne sygnały tożsamości. Gdy konfiguracja jest poprawna, wiadomości mają większą szansę trafić do skrzynki odbiorczej. Mniej z nich ląduje wtedy w spamie.^[1]

Dla administratorów domen, zespołów IT i osób prowadzących wysyłki e‑mailowe oznacza to kilka decyzji. Trzeba ustalić, co wdrożyć, w jakiej kolejności, jak zapisać rekordy w DNS i gdzie później szukać błędów. Filtry antyspamowe oceniają treść, reputację i zachowanie nadawcy. Mechanizmy tożsamości w DNS działają bliżej źródła wysyłki. Pokazują, czy dana domena w ogóle pozwala temu serwerowi wysłać wiadomość.^[2]

SPF, DKIM i DMARC – fundamenty uwierzytelniania poczty

SPF, DKIM i DMARC to trzy uzupełniające się protokoły uwierzytelniania e‑mail. Opierają się na DNS i są publikowane jako rekordy TXT w strefie każdej domeny internetowej. Chronią nadawców oraz odbiorców przed spoofing, phishing, spam i scenariuszami Business Email Compromise. Nie zastępują rozsądnej administracji pocztą, ale dają jej solidny punkt zaczepienia.

DNS działa jak katalog Internetu: łączy nazwy domen z adresami IP. Dzięki temu serwery pocztowe na całym świecie mogą odczytywać polityki uwierzytelnienia. Oryginalny SMTP z lat 80. nie powstał z myślą o sprawdzaniu nadawcy. Zakładał zaufanie między serwerami i sam z siebie nie potwierdza tożsamości. SPF/DKIM/DMARC dopisują brakujący zestaw kontroli: pochodzenie, zgodność domeny i integralność wiadomości.

Gmail, Yahoo i Microsoft 365 wykonują te kontrole przy odbiorze poczty. Biorą je też pod uwagę w filtrach antyspamowych. W latach 2024-2026 Gmail i Yahoo wymagają pełnej konfiguracji od masowych nadawców. Zwykle dotyczy to wysyłek > 5 000/dzień, z SPF, DKIM i DMARC oraz wyrównaniem domen. W Google Workspace i Microsoft 365 jest to dziś standard wdrożeniowy. Najbezpieczniej zacząć od SPF, potem włączyć DKIM. DMARC warto uruchomić od polityki p=none i dopiero po analizie przejść do egzekwowania. Zanim dojdziesz do DMARC, co najmniej SPF albo DKIM muszą działać bez błędów. Zwykle powinny działać oba.

Co to są SPF, DKIM i DMARC?

W tym zestawie SPF autoryzuje serwery wysyłające dla domeny. DKIM dodaje kryptograficzny podpis wiadomości, a DMARC ustala zasady zgodności domeny From oraz raportowanie. Dla organizacji wysyłających z własnej domeny internetowej te mechanizmy budują warstwę tożsamości nad transportem SMTP. Ograniczają skuteczność phishing, podszywania się, czyli spoofing, oraz ilość spam trafiającego do użytkowników.^[2]

Czym różnią się od zwykłych filtrów antyspamowych? Decyzja nie opiera się tu głównie na słowach w treści wiadomości. Liczy się przypisanie domeny, podpis i wynik kontroli technicznej.^[3]

Jak działają SPF, DKIM i DMARC?

Przepływ jest prosty: konfiguracja w domenie → wysyłka przez SMTP → weryfikacja SPF/DKIM u odbiorcy → ocena DMARC i polityka → decyzja filtra antyspamowego. W praktyce każdy etap dodaje sygnał zaufania. Może też wskazać miejsce, w którym wiadomość przestaje być wiarygodna. To pomaga szybciej odróżnić błąd konfiguracji od próby nadużycia.

1. Administrator domeny ustanawia zasady SPF, konfigurację DKIM i politykę DMARC. Rola: właściciel domeny; rezultat: ustawienia do weryfikacji,
2. Serwer nadawcy wysyła e‑mail, ustawiając parametry koperty, np. Return-Path, i dołączając podpis DKIM. Rola: MTA nadawcy; rezultat: wiadomość z nagłówkami uwierzytelnienia,
3. Serwer odbiorcy sprawdza SPF oraz podpis DKIM dla nadchodzącej wiadomości. Rola: MTA odbiorcy; rezultat: wyniki PASS/FAIL dla SPF i DKIM,
4. Moduł DMARC porównuje domenę w polu From z wynikami SPF lub DKIM i stosuje politykę domeny. Rola: walidator; rezultat: decyzja none/quarantine/reject oraz rekord do raportu,
5. System dostarczania i filtr antyspamowy łączą wynik DMARC z innymi sygnałami jakości. Rola: dostawca skrzynki; rezultat: doręczenie do Inbox/Spam lub odrzucenie.

W porównaniu z samym filtrowaniem treści taka sekwencja daje twarde wyniki uwierzytelnienia, czyli PASS/FAIL. Dodaje też politykę domeny, którą odbiorca może zastosować.^[4]

Jakie są mechanizmy SPF, DKIM i DMARC?

Mechanizmy są trzy i każdy odpowiada za inny fragment układanki. SPF wskazuje uprawnione źródła wysyłki dla domeny. DKIM zabezpiecza integralność wiadomości podpisem. DMARC wymaga zgodności widocznej domeny From i mówi, co zrobić przy braku zgodności. SPF pracuje na adresach i ścieżce doręczeń. DKIM działa na treści oraz nagłówkach. DMARC łączy wyniki w politykę i tworzy raporty dla właściciela domeny. Taki podział ról pomaga ograniczać podszywanie się pod domenę. Jednocześnie wspiera utrzymanie dobrej reputacji wysyłki.^[2]

Najkrócej: SPF odpowiada na pytanie „kto może wysyłać”. DKIM potwierdza, „czy wiadomość nie została zmieniona”. DMARC rozstrzyga, „czy domena nadawcy pasuje do autoryzacji” i jak potraktować wynik.

W skrócie: SPF, DKIM i DMARC tworzą jeden system tożsamości nadawcy. Poprawia on dostarczalność i zmniejsza ryzyko spoofingu, phishingu, spamu oraz BEC.^[1]

SPF: jak wskazuje uprawnione serwery wysyłające

SPF (Sender Policy Framework) pozwala właścicielowi domeny opublikować listę hostów i adresy IP. Są to źródła, które mogą wysyłać pocztę w jego imieniu. Polityka SPF trafia do rekord TXT (TXT record) w DNS i zaczyna się od ciągu v=spf1. Serwer pocztowy odbiorcy, czyli MTA, odpytuje SPF TXT record domeny nadawcy. Następnie porównuje źródłowy adres IP z listą autoryzowaną i zwraca wynik pass albo fail.

SPF ocenia domenę z MAIL FROM/Return-Path. Nie sprawdza nagłówka From, który widzi użytkownik. Adresy mogą być zarówno IPv4, jak i IPv6. To drobny szczegół, ale w diagnostyce często decyduje o całej sprawie.

Protokół SPF opisuje RFC7208. Walidacja ma limit maksymalnie 10 odwołań DNS przez mechanizmy takie jak a, mx, include, exists, ptr. Obejmuje to zapytania m.in. o rekord A i rekord MX. Jeśli przetwarzanie wymaga więcej niż 10 odwołań, odbiorca uznaje SPF za błąd trwały, czyli permerror.

Pojedynczy łańcuch w rekordzie TXT SPF nie może przekroczyć 255 znaków. Domena powinna publikować jeden rekord SPF. Kilka rekordów naraz powoduje niepowodzenie oceny. Przykładowa deklaracja łączy źródła ip4/ip6 z hostami a/mx i zewnętrznym dostawcą przez include. Rozwiązania typu Dynamic SPF pomagają zebrać wpisy w jednym miejscu. Ułatwiają też utrzymanie złożoności w granicach limitów DNS.

v=spf1 ip4:198.51.100.24 ip6:2001:db8::/32 a mx include:_spf.provider.example -all

Mechanizm ~all oznacza soft fail dla źródeł spoza polityki. Mechanizm -all oznacza hard fail i instruuje odbiorcę, by odrzucał wiadomości z nieautoryzowanych źródeł. Walidacja SPF może się nie powieść, na przykład przy przekazywaniu wiadomości. Dzieje się tak, gdy IP serwera pośredniczącego nie ma autoryzacji. Wielu odbiorców oznaczy wtedy wiadomość jako spam albo ją odrzuci. Wszystko zależy od polityki i pozostałych sygnałów. Aby potwierdzić pozytywny wynik, sprawdź nagłówek Received-SPF i szukaj rezultatu pass.

W skrócie: SPF pozwala odbiorcom porównać IP nadawcy z autoryzowaną listą. Poprawne opublikowanie pojedynczego v=spf1 z limitami DNS i właściwymi kwalifikatorami ogranicza błędy. Wzmacnia też wiarygodność wysyłki.^[5]

DKIM: podpis kryptograficzny, który chroni integralność wiadomości

DomainKeys Identified Mail (DKIM) dodaje do wychodzących e‑maili podpis kryptograficzny, czyli podpis cyfrowy. Potwierdza on integralność treści i autoryzację domeny nadawczej. DKIM opiera się na kryptografii asymetrycznej i został opisany w RFC 6376. Jeśli ktoś zmieni wiadomość po drodze, podpis przestaje pasować.

DKIM używa pary kluczy. Klucz prywatny (private key) podpisuje wiadomość. Pasujący klucz publiczny (public key) w DNS pozwala odbiorcy sprawdzić podpis. Dzięki temu można wykryć zmiany nagłówków lub treści w tranzycie. Nagłówek DKIM-Signature zawiera m.in. parametr s= wskazujący DKIM selector. Dzięki temu weryfikator pobiera właściwy rekord DNS dla danej domeny.

W codziennej konfiguracji często spotkasz algorytm RSA, np. a=rsa-sha256. Jeśli podpis nie zgadza się z kluczem publicznym, weryfikacja kończy się wynikiem fail. Tu nie ma miejsca na domysły.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=sel1;
h=from:subject:date:to:mime-version; bh=BASE64_BODY_HASH;
b=BASE64_SIGNATURE

Klucze publiczne DKIM publikuje się jako rekordy TXT w DNS pod nazwą <selector>._domainkey.<domena>. Selector wskazuje, którego klucza użyć. Przy domenach wysyłających z wielu systemów DKIM selector pozwala utrzymywać równoległe klucze i bezpiecznie je wymieniać. Dobrą praktyką jest rotacja kluczy oraz szybkie unieważnienie tych skompromitowanych. Dla bezpieczeństwa stosuje się klucze 2048‑bit lub dłuższe.

sel1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Sam DKIM nie mówi odbiorcy, co ma zrobić, gdy podpis nie przejdzie weryfikacji. Tę reakcję porządkuje DMARC. DKIM sprawdza integralność wiadomości i domenę podpisującą. Nie uwierzytelnia jednak widocznego pola From:. Aby potwierdzić wynik, zajrzyj do nagłówka Authentication-Results w odebranej wiadomości. Poszukaj tam statusu dkim=pass/fail.

Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=sel1 [email protected]

Podsumowując: DKIM daje sprawdzalny podpis domeny nadawczej i chroni integralność wiadomości dzięki kluczom w DNS. Sam nie narzuca jednak reakcji ani nie potwierdza widocznego nadawcy.

DMARC: polityka i raportowanie, które spinają całość

DMARC publikuje w DNS rekord TXT z instrukcją obsługi wiadomości, które nie przechodzą testów bezpieczeństwa. Chroni domenę nadawcy przed phishingiem i spoofingiem, bo porządkuje egzekwowanie wyników SPF/DKIM. Bez tej warstwy odbiorca widzi pojedyncze wyniki. Nie zawsze wie jednak, jaką decyzję sugeruje właściciel domeny.

DMARC pozwala właścicielom domen wskazać serwerom odbierającym, co zrobić z wiadomościami bez poprawnego SPF lub DKIM. Można je dostarczyć, przenieść do kwarantanny albo odrzucić. Poniższa tabela pokazuje trzy tryby polityki i ich wpływ na dostarczalność.

Polityki DMARC mówią serwerom, czy niezgodne wiadomości mają trafić do spamu, czy zostać odrzucone. Ustawienie p=none daje tylko wgląd w sytuację. Nie blokuje poczty podszywającej się pod domenę. Na starcie bywa przydatne, ale nie jest końcem wdrożenia.

DMARC uwierzytelnia widoczny nagłówek From, wymagając zbieżności z domeną SPF MAIL FROM lub DKIM d=. Aby wiadomość przeszła DMARC, musi zaliczyć SPF lub DKIM. Musi też utrzymać wyrównanie domeny z nagłówkiem From w trybie luźnym albo ścisłym. W praktyce Return‑Path, czyli domena SPF, i/lub domena podpisu DKIM powinny odpowiadać domenie z nagłówka From.

Tagami adkim i aspf ustawia się tryby ścisły (s) albo luźny (r). Domyślnie działa tryb luźny. W trybie ścisłym domena musi być identyczna z From. Tryb luźny dopuszcza dopasowania w obrębie subdomen.

Politykę publikuje się jako rekord TXT w subdomenie _dmarc domeny wysyłającej, np. _dmarc.example.com. Rekord DMARC musi zaczynać się od v=DMARC1 i zawierać wymagany tag p= jako pierwszy. To on definiuje wersję i sposób obsługi niezgodnej poczty. Ten sam rekord ustala reakcję na porażki uwierzytelniania. Wskazuje też miejsca docelowe raportów zbiorczych i forensycznych.

Aby włączyć DMARC, dodaj rekord TXT dla domeny w panelu dostawcy DNS. Przykład rekordu: v=DMARC1; p=quarantine; rua=mailto:[email protected]. Domyślnie polityka obejmuje subdomeny. Opcjonalny tag sp ustawia osobną politykę dla subdomen bez własnego rekordu.

DMARC dostarcza raportowanie zbiorcze oraz, jeśli odbiorca je obsługuje, raportowanie forensyczne. Tag rua wskazuje jeden lub więcej adresów mailto: do dziennych raportów XML. Jeśli chcesz wysłać je na kilka skrzynek, oddziel adresy przecinkami i poprzedź każdy mailto:. Tag ruf wskazuje adresy mailto: do raportów forensycznych pojedynczych wiadomości. Gmail nie obsługuje jednak raportów ruf. Raporty DMARC pokazują, kto wysyła w imieniu domeny. Pokazują też stan całego programu e‑mail.

Wdrożenie warto zacząć od p=none, żeby zbierać raporty bez wpływu na doręczanie. Gdy wszystkie legalne źródła przechodzą uwierzytelnienie, można przejść do p=quarantine. Później można użyć p=reject, by blokować spoofing. Opcjonalny tag pct ustawia odsetek niezgodnej poczty objętej polityką. Jego wartość to liczba całkowita od 1 do 100. Gdy brak pct, polityka obejmuje wszystkie wiadomości. Aby używać BIMI, domena musi mieć DMARC na poziomie egzekwowania (p=quarantine lub p=reject) i pct=100. BIMI nie działa z p=none.

• Platformy i narzędzia DMARC: PowerDMARC, Red Sift (OnDMARC), EasyDMARC, Valimail, dmarcian, Mimecast, a także kreatory typu DMARC Record Generator.

Podsumowanie: DMARC publikuje w DNS zasady egzekwowania SPF/DKIM oraz kanały raportowania. Dzięki temu właściciel domeny widzi pocztę wysyłaną w jego imieniu i może kontrolować jej obsługę.

Co to jest DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) łączy weryfikację SPF/DKIM z polityką postępowania i raportowaniem. Protokół DMARC opisuje RFC 7489 (RFC7489). Zasady i materiały referencyjne znajdziesz na dmarc.org.^[6]

RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)

DMARC daje nadawcom i odbiorcom wspólny język. Nadawcy publikują politykę w DNS. Odbiorcy stosują ją i odsyłają wyniki zgodnie z mechanizmem wyrównania nagłówka From. Przy praktycznej konfiguracji przydają się publiczne narzędzia, takie jak DMARC Record Generator. Nie zastępują one analizy raportów, ale skracają drogę do poprawnego rekordu.

Podsumowanie: DMARC formalizuje relację między domeną nadawcy a serwerami odbiorczymi przez politykę i raportowanie.

Jak różnią się między sobą i dlaczego najlepiej działają razem

SPF, DKIM i DMARC pełnią różne funkcje, ale najlepszy efekt dają razem. Podnoszą dostarczalność wiadomości e‑mail i ograniczają spoofing oraz phishing.^[7]

1. Autoryzuj źródło wysyłki przy użyciu SPF, wskazując uprawnione adresy IP lub serwery nadawcze,
2. Zabezpiecz integralność treści i tożsamość domenową podpisem DKIM, aby odbiorca zweryfikował niezmienność wiadomości,
3. Powiąż wyniki SPF i DKIM z widoczną domeną From oraz włącz egzekwowanie polityki i raportowanie w DMARC,
4. Traktuj zestaw SPF+DKIM+DMARC jako komplet, bo dopiero razem ograniczają podszywanie się pod domenę i kampanie phishingowe.^[2],
5. Uwzględnij ograniczenia: forwarding potrafi złamać SPF, DKIM nie blokuje treści spamu, a DMARC wymaga poprawnego alignmentu domen,
6. Nie oczekuj, że te standardy naprawią reputację treści ani błędne konfiguracje skrzynek; monitoruj raporty i reaguj na odchylenia.

Czy to są trzy osobne kontrole? Formalnie tak, ale w działaniu przypominają jeden łańcuch. SPF wskazuje źródło. DKIM potwierdza niezmienność. DMARC decyduje, czy widoczna domena nadawcy pasuje do tych dowodów. Gdy jeden element kuleje, cały obraz staje się mniej czytelny dla odbiorcy.

Rezultat: powstaje spójny łańcuch uwierzytelniania, który wzmacnia dostarczalność wiadomości e‑mail. Nie zastępuje jednak filtrów jakości treści ani administracji skrzynkami.^[8]

Szybka mapa wdrożenia w DNS (bez wchodzenia w szczegóły)

DNS publikuje rekordy TXT, więc szybka mapa wdrożenia prowadzi najpierw przez SPF i DKIM. Potem przechodzi przez DMARC do egzekwowania. Lepiej potraktować to jak zmianę etapową niż jednorazowe przełączenie całej domeny. Dzięki temu widzisz skutki każdej decyzji. Możesz też cofnąć błąd, zanim dotknie dużej wysyłki.

1. Ustaw krótkie TTL dla nowych rekordów, np. 300-600 s, aby przyspieszyć propagację podczas wdrażania,
2. Skonfiguruj SPF: utwórz rekord TXT w domenie, minimalizuj mechanizmy i zachowaj limit 10 lookupów,
3. Wygeneruj DKIM: utwórz parę kluczy u dostawcy poczty, opublikuj klucz publiczny w DNS pod selektorem i włącz podpisywanie tym selektorem,
4. Zweryfikuj alignment: zapewnij zgodność SPF i DKIM z adresem From domeny,
5. Dodaj DMARC: utwórz rekord TXT z polityką p=none i zacznij zbierać oraz analizować raporty,
6. Zaostrzaj DMARC: po analizie raportów podnieś politykę do p=quarantine, a następnie do p=reject,
7. Testuj po każdej zmianie: odczekaj pełny TTL i wykonaj wysyłki próbne do głównych odbiorców, weryfikując wyniki.

Efekt jest prosty: wdrażanie SPF, DKIM i DMARC zwykle sprowadza się do dodania rekordów TXT w DNS. Dokładne kroki zależą jednak od dostawcy DNS lub poczty. Konfigurację można uznać za gotową dopiero wtedy, gdy testy potwierdzą alignment i skuteczną politykę DMARC.

Jak zweryfikować konfigurację i diagnozować typowe problemy

Authentication-Results to nagłówek wiadomości, który pokazuje wyniki SPF, DKIM i DMARC. Do szybkiej weryfikacji użyj go razem z narzędziami DNS i testami skrzynki. Najlepiej zacząć od jednej wiadomości testowej. Jej pełne nagłówki potrafią powiedzieć więcej niż sam panel administracyjny.

1. Sprawdź DNS poleceniami dig/nslookup: odczytaj rekord TXT SPF, rekordy DKIM dla selectorów i rekord DMARC w strefie domeny,
2. Wyślij wiadomość testową do własnej skrzynki, np. Gmail/Outlook, i otwórz pełne nagłówki,
3. Przeczytaj Authentication-Results i potwierdź DMARC: upewnij się, że SPF lub DKIM mają status pass w alignment z domeną From,
4. Zinterpretuj wynik SPF: pass/fail/softfail/neutral/permerror; typowe przyczyny błędów to brak IP/hosta źródła, brak include dla dostawcy lub błąd składni,
5. Zweryfikuj klucze i składnię w webowych checkerach SPF/DKIM/DMARC, aby wykryć rozbieżności i wygasłe klucze,
6. Włącz i analizuj raporty DMARC RUA/RUF, aby wykrywać nieautoryzowane źródła wysyłki i monitorować zgodność w czasie,
7. Monitoruj reputację nadawcy, treść i wolumen; uwierzytelnienie poprawia zaufanie i dostarczalność, ale nie zapewnia trafienia każdej wiadomości do folderu Odebrane.

Punkt kontrolny jest konkretny: w Authentication-Results widzisz pass dla SPF lub DKIM w zgodności z From. Nie ma permerror w SPF, a RUA/RUF raportują wyłącznie autoryzowane źródła.

Źródła:

1. Antywirus Expert – „SPF, DMARC i DKIM – jak działają?” (2026) – https://www.antywirusexpert.pl/spf-dmarc-i-dkim-jak-dzialaja/
2. nFlo – „DMARC, SPF, DKIM – jak skonfigurować ochronę poczty?” (2026) – https://nflo.pl/baza-wiedzy/bezpieczenstwo-poczty-elektronicznej-dmarc-spf-dkim-spoofing/
3. GetMailbird – „Uwierzytelnianie email 2026: Przewodnik SPF, DKIM i DMARC” (2026) – https://www.getmailbird.com/pl/uwierzytelnianie-email-spf-dkim-dmarc-przewodnik/
4. HitMe.pl – „Test SPF, DKIM, DMARC” (2026) – https://hitme.pl/test-spf-dkim-dmarc/
5. RFC Editor / IETF – „RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email” (2014) – https://www.rfc-editor.org/rfc/rfc7208
6. IETF – „RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC)” (2015) – https://www.rfc-editor.org/rfc/rfc7489
7. PowerDMARC – „SPF, DKIM i DMARC: jak działają razem” (2026) – https://powerdmarc.com/pl/all-about-spf-dkim-dmarc/
8. Hosterion – „DKIM, SPF, DMARC. Czym są te tajemnicze skróty i dlaczego mają ogromny wpływ na dostarczalność” (2026) – https://hosterion.pl/dkim-spf-dmarc-czym-sa-te-tajemnicze-skroty-i-dlaczego-maja-ogromny-wplyw-na-dostarczalnosc

Kamil Sobański · Specjalista e-mail marketingu

Od kilkunastu lat zajmuję się e-mail marketingiem — buduję listy, projektuję newslettery i automatyzacje sprzedażowe dla małych firm oraz sklepów internetowych. Każdy program testuję od środka: zakładam konto, importuję bazę, tworzę kampanię, sprawdzam dostarczalność i wsparcie. W rankingu opisuję to, co realnie sprawdza się w polskich warunkach.