SPF, DKIM i DMARC – jak zabezpieczyć pocztę firmową przed podszywaniem

Potrzebujesz wszystkich trzech rekordów DNS, w tej kolejności: SPF, DKIM, a na końcu DMARC. SPF wskazuje serwery uprawnione do wysyłania poczty z Twojej domeny, DKIM podpisuje wiadomości kryptograficznie, a DMARC spina jedno z drugim i mówi serwerom odbiorców, co zrobić z pocztą, która nie przeszła weryfikacji. Kluczowy fakt: same SPF i DKIM nie chronią adresu, który widzi odbiorca – dopiero DMARC wymusza zgodność (alignment) z widocznym polem „Od”, i to on realnie blokuje podszywanie się pod Twoją firmę.

Od 2026 roku to już nie jest dobra praktyka, a warunek dostarczenia poczty. Google i Microsoft odrzucają dziś niepoprawnie uwierzytelnioną korespondencję masową na stałe (błąd 550), a nie kierują ją do spamu. Jeśli Twoja domena wysyła powyżej 5000 wiadomości dziennie do jednego dostawcy, brak SPF, DKIM i DMARC oznacza po prostu, że maile nie dotrą.

Najważniejsze w skrócie

• SPF = lista serwerów uprawnionych do wysyłki (rekord TXT, tylko jeden na domenę).
• DKIM = podpis kryptograficzny wiadomości (klucz publiczny w DNS, min. 1024-bit, zalecane 2048).
• DMARC = polityka + raporty + wymóg zgodności z polem „Od” (rekord _dmarc.domena.pl).
• Kolejność wdrożenia: SPF → DKIM → DMARC p=none → monitoring → p=quarantine → p=reject.
• Nigdy nie startuj od p=reject – najpierw 2–4 tygodnie raportów, inaczej zablokujesz własną pocztę.
• Limit SPF: 10 zapytań DNS. Przekroczenie = błąd permerror i nieudana weryfikacja.
• Od 2026 r. brak konfiguracji = odrzucanie poczty przez Gmail, Yahoo i Outlook (błędy 550).

SPF vs DKIM vs DMARC – porównanie (tabela)

Cecha	SPF	DKIM	DMARC
Co weryfikuje	Adres IP serwera wysyłającego	Integralność i autentyczność wiadomości	Zgodność SPF/DKIM z widocznym polem „Od”
Rekord DNS	TXT na domenie głównej	TXT: selektor._domainkey.domena.pl	TXT: _dmarc.domena.pl
Przykład wartości	v=spf1 include:spf.protection.outlook.com -all	klucz publiczny (RSA 2048-bit)	v=DMARC1; p=none; rua=mailto:dmarc@domena.pl
Chroni pole „Od” widoczne dla odbiorcy	Nie	Nie	Tak
Przeżywa przekierowanie maila (forwarding)	Nie	Tak	Zależnie od SPF/DKIM
Daje raporty	Nie	Nie	Tak (XML na adres rua)
Ile rekordów na domenę	Dokładnie jeden	Wiele (po jednym na selektor)	Jeden
Najczęstszy błąd	Dwa rekordy SPF lub >10 zapytań DNS	Klucz 512-bit lub brak podpisu	Zbyt szybkie p=reject

Dlaczego trzeba to zrobić teraz – wymogi dostawców

Do 2024 roku uwierzytelnianie poczty było zaleceniem. Dziś jest wymogiem trzech największych dostawców skrzynek:

• Google i Yahoo ogłosiły wymagania w październiku 2023, a egzekwowanie zaczęły w lutym 2024 – początkowo łagodnie, przez tymczasowe odroczenia (błędy 421). Od listopada 2025 niezgodna poczta masowa dostaje trwałe odrzucenia (błędy 550).
• Microsoft (Outlook.com) wprowadził własne wymagania 5 maja 2025 dla domen wysyłających ponad 5000 wiadomości dziennie. Odrzucone wiadomości zwracają komunikat 550 5.7.515 Access denied, sending domain does not meet the required authentication level.
• Progi i limity: wymogi dla nadawców masowych dotyczą 5000+ wiadomości dziennie do danego dostawcy. Google oczekuje SPF lub DKIM od wszystkich nadawców, Yahoo – obu protokołów. Dodatkowo wskaźnik zgłoszeń spamu musi pozostać poniżej 0,3%, a mailingi marketingowe wymagają wypisu jednym kliknięciem (RFC 8058).
• Regulacje: DMARC pojawia się dziś także w standardzie PCI DSS 4.0 oraz w wymaganiach wynikających z dyrektywy NIS2 – dla wielu firm to argument formalny, nie tylko techniczny.

Praktyczny wniosek: nawet jeśli Twoja firma nie prowadzi mailingów, poprawne SPF, DKIM i DMARC decydują o tym, czy faktury, oferty i korespondencja z klientami trafiają do skrzynki odbiorczej, czy do spamu.

SPF – kto może wysyłać pocztę z Twojej domeny

SPF (Sender Policy Framework) to rekord TXT w DNS, w którym wymieniasz serwery i usługi uprawnione do wysyłania poczty w imieniu Twojej domeny. Serwer odbiorcy sprawdza, czy adres IP nadawcy znajduje się na tej liście.

Przykład dla firmy korzystającej z Microsoft 365 i zewnętrznego systemu do faktur:

v=spf1 include:spf.protection.outlook.com include:_spf.dostawca-faktur.pl -all

Trzy rzeczy, które decydują o poprawności SPF:

• Tylko jeden rekord SPF na domenę. Dwa rekordy TXT rozpoczynające się od v=spf1 powodują błąd permerror i nieudaną weryfikację. Wszystkie usługi łączysz w jednym rekordzie, dopisując kolejne include:.
• Limit 10 zapytań DNS. Każdy mechanizm include, a, mx czy redirect generuje odpytanie DNS. Przekroczenie dziesięciu kończy się błędem – w rozbudowanych środowiskach stosuje się wtedy tzw. spłaszczanie SPF (SPF flattening) albo redukcję liczby usług.
• Zakończenie: -all czy ~all. -all (hardfail) oznacza „odrzuć wszystko, czego nie ma na liście”, ~all (softfail) – „oznacz jako podejrzane”. Docelowo używaj -all, ale przełącz się na nie dopiero po weryfikacji, że wszystkie legalne systemy wysyłkowe są uwzględnione.

Ważne ograniczenie: SPF weryfikuje adres z koperty wiadomości (MAIL FROM / Return-Path), a nie adres widoczny dla odbiorcy w polu „Od”. Dlatego SPF sam w sobie nie zapobiega podszywaniu się pod Twoją nazwę. SPF zawodzi też przy przekierowaniach poczty, bo zmienia się serwer wysyłający – tę lukę pokrywa DKIM.

DKIM – kryptograficzny podpis wiadomości

DKIM (DomainKeys Identified Mail) dodaje do każdej wysyłanej wiadomości podpis cyfrowy, tworzony kluczem prywatnym po stronie serwera nadawcy. Klucz publiczny publikujesz w DNS pod adresem selektor._domainkey.domena.pl. Serwer odbiorcy weryfikuje podpis i w ten sposób potwierdza, że wiadomość faktycznie wyszła z Twojej domeny i nie została zmieniona w tranzycie.

Praktyczne zasady:

• Długość klucza: minimum 1024 bity, zalecane 2048. Klucze 512-bitowe są odrzucane (m.in. przez Yahoo) – jeśli masz starą konfigurację, sprawdź to w pierwszej kolejności.
• Wiele selektorów. Każda usługa wysyłkowa może mieć własny selektor, więc DKIM – w przeciwieństwie do SPF – nie ma problemu z „jednym rekordem”.
• Rotacja kluczy. Dobra praktyka to okresowa wymiana kluczy; w Microsoft 365 służą do tego dwa selektory (selector1 i selector2) skonfigurowane jako rekordy CNAME.
• DKIM przeżywa przekierowania, dlatego przy poczcie przesyłanej dalej (listy, aliasy, forwardowanie) jest ważniejszy niż SPF.

DMARC – polityka, raporty i najważniejszy element: zgodność

DMARC (Domain-based Message Authentication, Reporting and Conformance) to rekord TXT pod _dmarc.domena.pl, który robi trzy rzeczy: wymaga zgodności domen, ustala politykę dla wiadomości niespełniających wymogów i zapewnia raportowanie.

Minimalny rekord startowy:

v=DMARC1; p=none; rua=mailto:dmarc@domena.pl; fo=1

Trzy poziomy polityki:

Polityka	Działanie serwera odbiorcy	Kiedy stosować
p=none	Tylko monitoruje i raportuje	Start – 2–4 tygodnie zbierania danych
p=quarantine	Kieruje do spamu	Po naprawieniu wszystkich legalnych nadawców
p=reject	Odrzuca wiadomość	Docelowo, po potwierdzeniu w raportach

Zgodność (alignment) – sedno całego mechanizmu. DMARC uznaje wiadomość za poprawną tylko wtedy, gdy przejdzie SPF lub DKIM, a domena z tej weryfikacji jest zgodna z domeną w widocznym polu „Od”. To właśnie ten warunek blokuje podszywanie się: nadawca może mieć własny, poprawny SPF, ale jeśli w polu „Od” wpisze Twoją domenę, DMARC to wychwyci. Domyślnie stosowana jest zgodność luźna (relaxed), obejmująca subdomeny; ścisłą wymuszają parametry aspf=s i adkim=s.

Raporty. Parametr rua to adres, na który dostawcy przysyłają dzienne raporty zbiorcze w formacie XML: kto wysyłał pocztę z Twojej domeny, z jakich adresów IP i z jakim wynikiem uwierzytelniania. To jedyny sposób, by bezpiecznie przejść od p=none do p=reject – i najczęściej pomijany etap wdrożenia.

Aktualizacja standardu: DMARCbis (2026)

W maju 2026 IETF opublikował zaktualizowaną specyfikację DMARC, znaną w branży jako DMARCbis: RFC 9989 (protokół główny), RFC 9990 (raporty zbiorcze) i RFC 9991 (raporty o błędach). Dokumenty te unieważniają pierwotny RFC 7489 z 2015 roku i podnoszą DMARC ze statusu informacyjnego do Proposed Standard na ścieżce standardów IETF.

Co to znaczy w praktyce dla firmy:

• Brak zmian wymuszonych. Rekordy nadal rozpoczynają się od v=DMARC1 i pozostają w pełni poprawne – nie ma „DMARC2” i nie trzeba masowo przebudowywać DNS.
• Wycofywane parametry. Tagi pct, rf i ri są uznane za przestarzałe – warto je usunąć przy najbliższej aktualizacji rekordu.
• Nowy sposób ustalania domeny organizacyjnej. Statyczną listę Public Suffix List zastąpił dynamiczny algorytm DNS Tree Walk, co dokładniej rozstrzyga kwestie subdomen.
• Zmiana podejścia do p=reject. Nowa specyfikacja wyraźnie odradza bezwarunkowe odrzucanie dla tzw. przepływów niebezpośrednich (listy mailingowe, przekierowania) – to sygnał, że polityki trzeba dobierać do realnego ruchu, a nie ustawiać maksymalnie „na wszelki wypadek”.

Wdrożenie krok po kroku – bezpieczna kolejność

1. Inwentaryzacja nadawców. Wypisz wszystko, co wysyła pocztę z Twojej domeny: serwer poczty, CRM, system fakturowy, ERP, narzędzie do newslettera, formularze ze strony, monitoring, drukarki sieciowe. Pominięcie choćby jednego systemu to najczęstsza przyczyna późniejszych problemów.
2. SPF. Utwórz jeden rekord TXT obejmujący wszystkie te usługi. Na start zakończ go ~all.
3. DKIM. Włącz podpisywanie dla każdej usługi wysyłkowej i opublikuj klucze publiczne (2048-bit).
4. DMARC p=none. Opublikuj rekord z adresem rua i zbieraj raporty przez 2–4 tygodnie.
5. Analiza raportów. Zidentyfikuj legalnych nadawców, którzy nie przechodzą weryfikacji, i napraw ich konfigurację. Dopiero teraz zmień SPF na -all.
6. p=quarantine. Przejdź na kwarantannę i monitoruj dalej, czy nie giną potrzebne wiadomości.
7. p=reject. Ustaw docelową politykę, uwzględniając zastrzeżenie DMARCbis dotyczące przepływów niebezpośrednich.

Etapy 4–6 to nie formalność. Ustawienie p=reject bez wcześniejszego monitoringu potrafi zablokować własne faktury, powiadomienia z systemów wewnętrznych i newsletter – to najczęstszy i najkosztowniejszy błąd we wdrożeniach, jakie widzimy w NG Solutions.

Microsoft 365 i Exchange Online – konkrety

Dla firm korzystających z Microsoft 365 konfiguracja wygląda tak:

• SPF: dodaj include:spf.protection.outlook.com do jedynego rekordu SPF domeny.
• DKIM: utwórz dwa rekordy CNAME (selector1._domainkey i selector2._domainkey) wskazujące na wartości z Twojego tenanta, a następnie włącz podpisywanie DKIM dla domeny w portalu Microsoft Defender.
• DMARC: opublikuj rekord _dmarc i skieruj raporty na monitorowaną skrzynkę lub do usługi analizującej raporty XML.

Jeśli planujesz zmianę dostawcy poczty, pamiętaj, że rekordy trzeba zaktualizować równolegle z przenoszeniem skrzynek – zapomniany SPF po migracji to klasyczna przyczyna nagłego trafiania firmowej poczty do spamu. Ten etap warto zaplanować razem z migracją i przeniesieniem poczty na inny serwer, a w środowiskach z lokalnym Exchange – z wdrożeniem Exchange i Active Directory.

Najczęstsze błędy w konfiguracji

• Dwa rekordy SPF na jednej domenie – zawsze scalaj w jeden.
• Przekroczenie 10 zapytań DNS w SPF (permerror) – ogranicz include lub spłaszcz rekord.
• Start od p=reject bez etapu raportowania – ryzyko utraty legalnej korespondencji.
• Pominięci nadawcy zewnętrzni – system fakturowy, CRM czy newsletter wysyłający „w imieniu” domeny.
• Brak DKIM przy samym SPF – poczta przekierowywana przestaje przechodzić weryfikację.
• Nieodbierane raporty rua – rekord istnieje, ale nikt nie analizuje danych, więc wdrożenie stoi na p=none latami.
• Stary klucz DKIM 512-bit – odrzucany przez część dostawców.
• Założenie, że SPF chroni pole „Od” – nie chroni; bez DMARC podszywanie się pozostaje możliwe.

Jak sprawdzić, czy konfiguracja działa

1. Nagłówki wiadomości. Wyślij testowy mail na konto Gmail i wybierz „Pokaż oryginał”. Szukasz trzech wyników: spf=pass, dkim=pass, dmarc=pass.
2. Walidatory DNS. Publiczne narzędzia (np. MXToolbox, Google Admin Toolbox) pokazują składnię rekordów, liczbę zapytań DNS w SPF i poprawność DKIM.
3. Raporty DMARC. Analiza plików XML z adresu rua to jedyne pełne źródło informacji o tym, kto wysyła pocztę z Twojej domeny.
4. Kody błędów przy odrzuceniach: 421-4.7.26 (brak uwierzytelnienia), 421-4.7.32 (problem ze zgodnością), 550 5.7.515 (Microsoft – niespełniony wymóg uwierzytelniania).

Regularny przegląd tych ustawień – zwłaszcza po zmianie dostawcy poczty lub dodaniu nowego systemu – warto włączyć do szerszego audytu informatycznego i bezpieczeństwa.

Co dalej: BIMI i MTA-STS

Po osiągnięciu p=reject można rozbudować ochronę:

• BIMI – wyświetla logo firmy przy wiadomościach w skrzynce odbiorcy; wymaga DMARC na poziomie quarantine lub reject oraz certyfikatu VMC.
• MTA-STS – wymusza szyfrowanie TLS dla poczty przychodzącej do Twojej domeny, zamykając lukę na ataki typu downgrade.

Warto pamiętać, że uwierzytelnianie poczty ogranicza podszywanie się pod Twoją domenę, ale nie chroni przed phishingiem z domen łudząco podobnych ani przed przejęciem konta pracownika. To element szerszej strategii – obok uwierzytelniania wieloskładnikowego, filtrowania treści i szkoleń – którą realizujemy w ramach cyberbezpieczeństwa dla firm.

Najczęstsze pytania (FAQ)

Czy wystarczy sam SPF? Nie. SPF weryfikuje tylko adres z koperty wiadomości i zawodzi przy przekierowaniach. Nie chroni widocznego pola „Od”, więc bez DKIM i DMARC podszywanie się pod Twoją domenę pozostaje możliwe.

Ile rekordów SPF może mieć domena? Dokładnie jeden. Dwa rekordy zaczynające się od v=spf1 powodują błąd i nieudaną weryfikację – wszystkie usługi trzeba połączyć w jednym rekordzie.

Czy mogę od razu ustawić p=reject? Nie jest to zalecane. Najpierw ustaw p=none z raportowaniem na 2–4 tygodnie, napraw legalnych nadawców, przejdź przez p=quarantine, a dopiero potem na p=reject. Inaczej ryzykujesz zablokowanie własnej poczty.

Co oznacza różnica między ~all i -all w SPF? ~all (softfail) oznacza oznaczenie wiadomości jako podejrzanej, -all (hardfail) – jej odrzucenie. Docelowo stosuj -all, ale dopiero po potwierdzeniu, że wszystkie legalne systemy wysyłkowe są w rekordzie.

Jak długo trwa wdrożenie SPF, DKIM i DMARC? Publikacja rekordów to kwestia godzin (plus propagacja DNS). Bezpieczne dojście do p=reject zajmuje zwykle od kilku tygodni do 2–3 miesięcy, bo wymaga analizy raportów.

Czy DMARC chroni przed phishingiem z podobnych domen? Nie. DMARC blokuje podszywanie się pod Twoją dokładną domenę, ale nie pod domeny łudząco podobne. Do tego potrzebne są monitoring podobnych domen, filtrowanie poczty i szkolenia pracowników.

Czy te wymogi dotyczą też małych firm? Tak, choć w mniejszym stopniu formalnie. Progi 5000 wiadomości dziennie dotyczą nadawców masowych, ale Google oczekuje SPF lub DKIM od wszystkich nadawców, a brak uwierzytelniania zwiększa ryzyko trafienia zwykłej korespondencji do spamu.

Podsumowanie

Ochrona firmowej poczty przed podszywaniem opiera się na trzech rekordach DNS wdrażanych w określonej kolejności: SPF (jeden rekord, maksymalnie 10 zapytań DNS), DKIM (klucz 2048-bit, przeżywa przekierowania) i DMARC (polityka plus wymóg zgodności z polem „Od”). To DMARC realnie blokuje spoofing, bo SPF i DKIM same nie chronią adresu widocznego dla odbiorcy. Wdrożenie prowadź etapami – od p=none z raportowaniem, przez p=quarantine, do p=reject – i nigdy nie skracaj etapu analizy raportów, bo to najszybsza droga do zablokowania własnej korespondencji. Od 2026 roku poprawna konfiguracja to warunek dostarczalności: Gmail, Yahoo i Outlook odrzucają niezgodną pocztę masową na stałe.