Uwierzytelnianie e-mail: SPF, DKIM i DMARC prosto wyjaśnione

SPF, DKIM i DMARC pomagają serwerowi odbiorcy sprawdzić, czy wiadomość korzysta z domeny nadawcy w autoryzowany sposób. Każdy mechanizm robi coś innego: SPF ocenia techniczne źródło wysyłki, DKIM weryfikuje podpis domeny i integralność wybranych elementów wiadomości, a DMARC porównuje te wyniki z domeną widoczną w polu „Od”.

Nie są to po prostu „trzy rekordy, które potwierdzają, że mail jest od Ciebie”. SPF i DMARC są publikowane w DNS, a DKIM wymaga zarówno klucza publicznego w DNS, jak i podpisywania każdej wiadomości kluczem prywatnym przez system wysyłkowy. Poprawne wdrożenie ogranicza podszywanie się pod domenę i spełnia podstawowe wymagania dużych dostawców skrzynek, ale nie gwarantuje folderu Odebrane.

W skrócie

• SPF sprawdza, czy adres IP może wysyłać pocztę dla technicznej domeny zwrotnej, nazywanej także MAIL FROM lub Return-Path.
• DKIM sprawdza podpis wiadomości i domenę podpisującą wskazaną parametrem d=.
• DMARC przechodzi, gdy SPF albo DKIM przechodzi uwierzytelnienie i używa domeny zgodnej z domeną w widocznym polu „Od”.
• Gmail i Yahoo wymagają od nadawców masowych SPF, DKIM i DMARC; minimalna polityka DMARC może mieć wartość p=none.
• p=none służy do obserwacji, ale nie prosi odbiorców o blokowanie wiadomości podszywających się pod domenę.
• Wdrożenie wymaga spisu wszystkich legalnych źródeł: newslettera, poczty pracowników, sklepu, faktur, CRM, help desku i formularzy.

Trzy domeny, które trzeba odróżnić

W jednej wiadomości mogą występować różne tożsamości:

1. Domena w polu „Od” — adres, który widzi odbiorca, np. newsletter@marka.pl.
2. Domena SPF — techniczna domena używana do obsługi zwrotów; często widać ją w nagłówku Return-Path.
3. Domena DKIM — domena podpisująca wiadomość, zapisana w podpisie jako d=.

SPF albo DKIM może przejść dla domeny dostawcy, podczas gdy odbiorca widzi marka.pl. Taka wiadomość jest uwierzytelniona technicznie, ale nie musi spełnić DMARC dla marka.pl. DMARC został stworzony właśnie po to, aby połączyć wynik techniczny z domeną widoczną dla człowieka.

SPF: kto może wysyłać dla domeny technicznej

SPF, czyli Sender Policy Framework, jest rekordem TXT w DNS. Wymienia adresy IP i usługi uprawnione do używania domeny w poleceniu MAIL FROM. Serwer odbiorcy porównuje adres IP połączenia z tą polityką.

Najważniejsze zasady SPF:

• domena powinna mieć jeden rekord SPF zaczynający się od v=spf1; dwóch osobnych rekordów nie należy tworzyć;
• rekord musi obejmować wszystkie legalne źródła używające tej domeny zwrotnej;
• standard ogranicza liczbę mechanizmów powodujących zapytania DNS do 10 podczas jednego sprawdzenia;
• usunięcie dostawcy wymaga również usunięcia jego wpisu z SPF;
• przekazywanie wiadomości może zmienić serwer wysyłający i spowodować błąd SPF, nawet jeśli pierwotna wysyłka była legalna.

SPF nie sprawdza bezpośrednio adresu widocznego w polu „Od”. Zgodność z tą domeną ocenia dopiero DMARC. Rekordu nie należy składać przez kopiowanie fragmentów z przypadkowych poradników — właściwą składnię i domeny include podaje konkretny dostawca poczty.

DKIM: podpis domeny na wiadomości

DKIM, czyli DomainKeys Identified Mail, korzysta z pary kluczy. System nadawcy podpisuje wiadomość kluczem prywatnym, a serwer odbiorcy pobiera klucz publiczny z DNS i sprawdza podpis. Dzięki temu można potwierdzić, że wskazane nagłówki i treść objęte podpisem nie zostały zmienione po jego utworzeniu.

Rekord DKIM znajduje się pod nazwą zawierającą selektor, na przykład selector1._domainkey.marka.pl. Selektor pozwala równolegle publikować kilka kluczy i bezpiecznie je zmieniać.

W praktyce sprawdź:

• czy wiadomości są rzeczywiście podpisywane, a nie tylko czy rekord istnieje;
• czy domena d= należy do marki lub jest z nią zgodna dla DMARC;
• długość klucza — Google wymaga minimum 1024 bitów i rekomenduje 2048 bitów, jeśli dostawca je obsługuje;
• procedurę rotacji kluczy i usuwania nieużywanych selektorów;
• czy narzędzia modyfikujące wiadomość po podpisaniu nie powodują błędu weryfikacji.

DKIM może lepiej przetrwać zwykłe przekazanie niż SPF, ale nie jest niezniszczalny. Zmiana podpisanych elementów przez bramkę, listę mailingową lub system bezpieczeństwa może unieważnić podpis.

DMARC: zgodność domeny i polityka odbioru

DMARC, czyli Domain-based Message Authentication, Reporting and Conformance, jest rekordem TXT publikowanym pod _dmarc.marka.pl. Sprawdza domenę w widocznym polu „Od” i uznaje wiadomość za zgodną, jeżeli spełniony jest co najmniej jeden warunek:

• SPF przechodzi, a jego domena jest zgodna z domeną „Od”; lub
• DKIM przechodzi, a domena podpisu d= jest zgodna z domeną „Od”.

Domyślnie stosuje się zgodność uproszczoną: subdomena i domena organizacyjna mogą zostać uznane za zgodne. Tryb ścisły wymaga dokładnego dopasowania i można go włączyć parametrami aspf=s albo adkim=s. Nie zaostrzaj tych ustawień bez sprawdzenia wszystkich strumieni poczty.

Polityka DMARC informuje odbiorcę, jak właściciel domeny chce traktować wiadomości, które nie spełniają warunków:

• p=none — zbieraj dane, bez żądania kwarantanny lub odrzucenia;
• p=quarantine — traktuj błąd podejrzliwie, zwykle kierując wiadomość do spamu;
• p=reject — odrzucaj wiadomość niespełniającą zasad.

Ostateczną decyzję podejmuje serwer odbiorcy. Polityka DMARC jest opublikowaną prośbą nadawcy, a nie bezwarunkową gwarancją zachowania każdego systemu.

Raporty DMARC: co rzeczywiście pokazują

Parametr rua wskazuje adres do zbiorczych raportów. Raporty zwykle zawierają domenę, źródłowy adres IP, liczbę wiadomości oraz wyniki SPF, DKIM i DMARC. Pomagają znaleźć legalne narzędzia, błędną konfigurację i źródła podszywania się.

Raporty agregujące nie pokazują pełnej treści kampanii ani nie zastępują raportu dostarczalności. Są plikami XML i przy wielu domenach lub źródłach wygodniej analizować je narzędziem, które grupuje dane. Adres raportowy trzeba zabezpieczyć przed dużą liczbą wiadomości i kontrolować, kto ma do niego dostęp.

Raportowanie ruf dotyczy pojedynczych błędów, nie jest powszechnie obsługiwane i może zawierać dane wymagające dodatkowej oceny prywatności. Dla większości wdrożeń punktem wyjścia jest rua.

Aktualne wymagania Gmaila, Yahoo i Outlook.com

Google wymaga, aby każdy nadawca do prywatnych kont Gmail korzystał co najmniej z SPF lub DKIM. Nadawcy wysyłający około 5000 lub więcej wiadomości dziennie do prywatnych kont Gmail muszą używać SPF i DKIM oraz opublikować DMARC. Polityka może mieć wartość p=none, a domena w polu „Od” musi być zgodna z uwierzytelnioną domeną SPF lub DKIM. Wymagania obejmują również między innymi TLS, poprawny DNS, niski poziom skarg i łatwy wypis dla wiadomości marketingowych.

Yahoo wymaga od nadawców masowych SPF, DKIM i DMARC z polityką co najmniej p=none; DMARC musi przechodzić, a zgodność uproszczona jest akceptowana. Yahoo nie publikuje jednego progu liczbowego dla klasyfikacji nadawcy masowego.

Od maja 2025 roku Outlook.com wymaga SPF, DKIM i DMARC od domen wysyłających ponad 5000 wiadomości dziennie do konsumenckich adresów Outlook.com, Hotmail.com i Live.com.

Spełnienie wymagań uwierzytelniania jest warunkiem technicznym, nie obietnicą miejsca w Odebranych. Reputacja domeny i IP, skargi, jakość bazy, treść, częstotliwość oraz błędy SMTP nadal wpływają na dostarczalność e-mail.

Bezpieczna kolejność wdrożenia

1. Zrób spis źródeł. Uwzględnij pocztę pracowników, marketing automation, sklep, płatności, faktury, formularze, CRM, help desk i systemy partnerów.
2. Wybierz domeny i subdomeny. Rozdzielenie poczty marketingowej, transakcyjnej i firmowej może ułatwić zarządzanie reputacją, ale każda domena musi być poprawnie skonfigurowana.
3. Popraw SPF. Utwórz jeden rekord, usuń stare źródła i sprawdź limit zapytań DNS.
4. Włącz DKIM u każdego nadawcy. Potwierdź podpis w realnej wiadomości i zgodność domeny d=.
5. Opublikuj DMARC z p=none i rua. To faza obserwacji, nie ochrona przed podszywaniem.
6. Analizuj reprezentatywny okres. Obejmij rzadsze wysyłki, takie jak faktury miesięczne czy kampanie sezonowe, zamiast trzymać się arbitralnej liczby dni.
7. Napraw legalne źródła. Nie dodawaj podejrzanego serwera do SPF tylko dlatego, że pojawił się w raporcie.
8. Przejdź do egzekwowania. Włącz quarantine, a następnie reject, gdy legalna poczta przechodzi DMARC i istnieje plan awaryjny.
9. Monitoruj zmiany. Nowe narzędzie, migracja systemu lub zmiana domeny może ponownie zepsuć uwierzytelnianie.

Dla samego spełnienia minimalnych wymagań Gmaila i Yahoo p=none wystarcza. Jeżeli celem jest również ograniczenie podszywania się pod domenę albo uruchomienie BIMI, potrzebna jest polityka egzekwująca — po bezpiecznym przygotowaniu legalnej poczty.

Przykładowe rekordy — tylko do zrozumienia składni

Poniższe wartości używają zastrzeżonej domeny example.com i nie nadają się do wklejenia do firmowego DNS:

example.com                  TXT  "v=spf1 include:provider.example -all"
selector1._domainkey.example.com TXT  "v=DKIM1; k=rsa; p=KLUCZ_PUBLICZNY"
_dmarc.example.com           TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Rekordy trzeba zbudować na podstawie dokumentacji faktycznie używanych dostawców. Błąd w DNS może wpłynąć na pocztę firmową, transakcyjną i marketingową, dlatego zmianę powinien wykonać lub zatwierdzić administrator domeny.

Najczęstsze błędy

• dwa osobne rekordy SPF zamiast jednego;
• przekroczenie limitu 10 zapytań DNS w SPF;
• pozostawienie usług, które nie wysyłają już poczty;
• rekord DKIM w DNS bez rzeczywistego podpisywania wiadomości;
• podpis DKIM domeną dostawcy, która nie jest zgodna z domeną „Od”;
• ocena konfiguracji tylko na podstawie obecności rekordów, bez sprawdzenia nagłówków testowej wiadomości;
• p=reject wdrożone przed odnalezieniem faktur, formularzy i innych rzadkich źródeł;
• p=none utrzymywane bez analizy raportów i decyzji o dalszej ochronie;
• zakładanie, że poprawny DMARC rozwiązuje skargi, starą bazę lub nagły skok wolumenu;
• brak właściciela procesu po zmianie narzędzia.

Jak podchodzimy do uwierzytelniania w Space Ads

W audycie zaczynamy od mapy domen i źródeł, a następnie sprawdzamy wyniki w nagłówkach realnych wiadomości. Sama obecność zielonego znacznika w panelu narzędzia nie wystarcza, jeżeli SPF lub DKIM przechodzi dla obcej domeny i DMARC nadal nie jest zgodny.

Docelową politykę dobieramy po analizie raportów i ryzyka. Pełne egzekwowanie DMARC jest także jednym z warunków BIMI oraz certyfikatu VMC lub CMC. Audyt marketingowy może wskazać braki, a bieżący e-mail marketing uwzględnić monitoring przy zmianach infrastruktury.

Najczęstsze pytania

Czym różnią się SPF, DKIM i DMARC?

SPF autoryzuje serwer dla technicznej domeny zwrotnej. DKIM sprawdza podpis i integralność wiadomości dla domeny podpisującej. DMARC porównuje domenę SPF lub DKIM z domeną widoczną w polu „Od”, ustala politykę dla błędów i umożliwia zbiorcze raportowanie.

Czy DMARC wymaga jednocześnie zgodnego SPF i DKIM?

Nie. Wiadomość przechodzi DMARC, jeżeli przejdzie SPF wraz ze zgodnością domeny albo DKIM wraz ze zgodnością domeny. Nadawcy masowi Gmaila i Yahoo muszą jednak wdrożyć zarówno SPF, jak i DKIM jako osobne wymaganie tych dostawców.

Czy od razu ustawić p=reject?

Tylko jeśli organizacja zna wszystkie legalne źródła i potwierdziła ich zgodność. W typowym wdrożeniu bezpieczniej zacząć od p=none, analizować raporty, naprawić źródła, a potem przejść przez quarantine do reject. Domena bez aktywnej poczty może wymagać innego, szybszego podejścia.

Czy p=none chroni domenę przed podszywaniem?

Nie prosi odbiorców o kwarantannę ani odrzucenie wiadomości, które nie przechodzą DMARC. Daje widoczność w raportach i spełnia minimalny wymóg publikacji polityki u Gmaila i Yahoo, ale aktywna ochrona wymaga p=quarantine albo p=reject.

Czy SPF, DKIM i DMARC gwarantują folder Odebrane?

Nie. Potwierdzają autoryzację domeny i ograniczają podszywanie się, lecz filtr bierze pod uwagę także reputację, skargi, oczekiwanie odbiorcy na wiadomość, zawartość, linki, wolumen i zachowanie bazy. Poprawna autoryzacja jest fundamentem, a nie przepustką do skrzynki.

Jak sprawdzić, czy DMARC przechodzi?

Wyślij wiadomość z każdego systemu do kontrolowanej skrzynki i sprawdź pełne nagłówki, zwłaszcza Authentication-Results, domenę Return-Path oraz d= w podpisie DKIM. Następnie porównaj wyniki z raportami DMARC. Test jednego newslettera nie potwierdza poprawności faktur, poczty pracowników ani formularzy.

Czy konfigurację wykonuje się tylko raz?

Rekordy nie zmieniają się przy każdej kampanii, ale infrastruktura wymaga stałego nadzoru. Dodanie lub usunięcie platformy, rotacja klucza, migracja DNS i nowa subdomena są powodami do ponownego testu.

Najważniejsze wnioski

• SPF, DKIM i DMARC sprawdzają różne elementy tożsamości wiadomości.
• DMARC wymaga zgodnego SPF lub zgodnego DKIM z domeną w widocznym polu „Od”.
• Nadawcy masowi powinni wdrożyć wszystkie trzy mechanizmy zgodnie z aktualnymi zasadami odbiorców.
• p=none zapewnia obserwację, a quarantine i reject wprowadzają egzekwowanie.
• Najpierw zinwentaryzuj i napraw legalne źródła, dopiero później blokuj błędy.
• Po każdej zmianie narzędzia sprawdzaj nagłówki realnej wiadomości i raporty.

Źródła i dalsza lektura

• Google — wymagania dla nadawców wiadomości e-mail
• Yahoo Sender Hub — wymagania i rekomendacje dla nadawców
• Microsoft — wymagania Outlook.com dla nadawców wysyłających duże wolumeny
• IETF — RFC 7208: SPF, RFC 6376: DKIM, RFC 7489: DMARC

Czytaj dalej

• Dostarczalność e-mail: dlaczego maile trafiają do spamu
• BIMI, VMC i CMC: zweryfikowane logo w skrzynce
• Dedykowane vs współdzielone IP i rozgrzewanie IP
• Double opt-in, wypisy i higiena bazy
• E-mail marketing · Marketing automation