Audyt bezpieczeństwa poczty w 2026 r.: SPF, DKIM, DMARC i bezpieczeństwo transportu

Co rzeczywiście chronią SPF, DKIM i DMARC

SPF, DKIM i DMARC chronią tożsamość domeny, ale nie odpowiadają na wszystkie problemy poczty. Nie potwierdzają tożsamości człowieka, prawdziwości treści, bezpieczeństwa odnośnika ani uczciwości nadawcy, który legalnie korzysta z uwierzytelnionej domeny. Poprawnie uwierzytelniona wiadomość może nadal być phishingiem.

SPF odpowiada na pytanie, czy dany serwer może użyć domeny w tożsamości SMTP MAIL FROM albo HELO/EHLO. Nie sprawdza sam z siebie domeny widocznej użytkownikowi w polu From:. Rekord SPF jest publikowany w DNS jako TXT i opisuje autoryzowane źródła wysyłki.^[3]

DKIM pozwala domenie kryptograficznie podpisać wybrane nagłówki oraz skrót treści wiadomości. Odbiorca pobiera klucz publiczny z DNS i weryfikuje podpis, a domenę podpisującą określa parametr d=. DKIM może przetrwać przekazywanie wiadomości, o ile pośrednie systemy nie zmienią podpisanych elementów w sposób unieważniający podpis.^[4]

DMARC wiąże domenę autora z pola RFC5322.From z wynikiem SPF lub DKIM. Wiadomość przechodzi DMARC, jeżeli przynajmniej jeden z tych mechanizmów przejdzie weryfikację i jego domena będzie zgodna z domeną autora według wybranego trybu alignment.^[1]

Ta konstrukcja ogranicza bezpośrednie podszywanie się pod domenę organizacji, ale nie blokuje domen podobnych wizualnie, nadużycia nazwy wyświetlanej, przejętego konta ani legalnie uwierzytelnionej kampanii phishingowej. Audyt powinien więc rozdzielić uwierzytelnianie domeny od bezpieczeństwa skrzynki, transportu i ochrony odbiorcy. To rozróżnienie ma znaczenie także dla szkoleń security awareness: użytkownik nie może zakładać, że wiadomość, która dotarła do skrzynki, przeszła jakąkolwiek weryfikację treści.

SPF: więcej niż sprawdzenie składni

Dobry audyt SPF odpowiada co najmniej na sześć pytań:

• Czy dla ocenianej domeny istnieje dokładnie jeden rekord SPF?
• Czy wszystkie mechanizmy include, a, mx, ip4, ip6 i redirect są nadal potrzebne?
• Czy każdy zewnętrzny dostawca wysyłający w imieniu organizacji ma właściciela biznesowego?
• Czy rekord nie autoryzuje zakresu adresów większego niż rzeczywiście potrzebny?
• Czy domena MAIL FROM pozwala uzyskać zgodność z domeną From:, jeśli organizacja polega na SPF dla DMARC?
• Czy cały łańcuch rekursywnych include mieści się w limitach oceny DNS?

RFC 7208 ogranicza do dziesięciu łączną liczbę terminów powodujących zapytania DNS podczas oceny SPF. Do limitu należą include, a, mx, ptr, exists i redirect, a przekroczenie prowadzi do wyniku permerror. Standard zaleca także ograniczenie pustych odpowiedzi DNS do dwóch.^[3]

To ważne, bo problemy SPF częściej ujawniają się podczas oceny niż podczas samego parsowania rekordu. Badanie przedstawione na USENIX Security 2024 analizowało cotygodniowe migawki przez 17 miesięcy, obejmujące 176 mln domen z czterech domen najwyższego poziomu. Błędy składniowe występowały w 0,4% rekordów, a problemy pojawiające się w fazie oceny w 7,7%.^[11] Liczb tych nie należy przenosić na pojedynczą organizację, ale dobrze pokazują ograniczenia prostego walidatora SPF.

Spłaszczanie SPF do listy adresów IP może zmniejszyć liczbę zapytań DNS, ale tworzy lokalną kopię danych dostawcy. Jeśli dostawca zmieni infrastrukturę, rekord trzeba zsynchronizować, inaczej organizacja zaczyna odrzucać własną pocztę. Audyt powinien więc sprawdzić nie tylko wynik, ale również mechanizm utrzymania rekordu.

DKIM: podpis to także zarządzanie kluczem

RFC 8301 zabrania RSA-SHA1. Dla podpisów RSA wymaga co najmniej 1024 bitów i zaleca minimum 2048 bitów.^[4] RFC 8463 dodał Ed25519-SHA256.^[5] Organizacja powinna jednak brać pod uwagę interoperacyjność z odbiorcami, szczególnie gdy sięga po mniej powszechny algorytm.

Audyt DKIM obejmuje:

• domenę podpisującą d= i jej zgodność z domeną autora;
• algorytm i długość klucza;
• ochronę klucza prywatnego;
• osobne selektory dla różnych dostawców i środowisk, jeśli pozwala to ograniczyć skutki kompromitacji;
• zakres podpisywanych nagłówków, w tym From:;
• brak nieuzasadnionego użycia znacznika l= ograniczającego podpisaną długość treści;
• sposób rotacji, unieważnienia i odzyskania po kompromitacji;
• potwierdzenie, że stary rekord nie jest usuwany przed przejściem ruchu na nowy selektor.

Nie istnieje uniwersalny wymóg rotowania klucza DKIM co sześć albo dwanaście miesięcy. Harmonogram powinien wynikać z ochrony klucza, możliwości dostawcy, modelu zagrożeń i zdolności do wykonania bezpiecznej rotacji. Audytor, który wpisuje do raportu "brak rotacji co 6 miesięcy" jako niezgodność, powinien wskazać podstawę tego wymagania, a nie zwyczaj.

DMARC według RFC 9989

W nowym DMARC nadal najważniejsze jest pojęcie alignment. SPF może dać wynik pass dla jednej domeny, ale jeżeli domena MAIL FROM nie jest zgodna z domeną From:, nie daje to pozytywnego wyniku DMARC. Podobnie podpis DKIM jest użyteczny dla DMARC tylko wtedy, gdy jego domena d= jest zgodna z domeną autora.^[1]

Tryb relaxed, będący domyślnym, pozwala na zgodność na poziomie tej samej domeny organizacyjnej. Tryb strict wymaga ściślejszego dopasowania. Decyzję należy podejmować z uwzględnieniem architektury wysyłki, a nie na zasadzie "strict zawsze jest bezpieczniejszy": w środowisku z wieloma subdomenami i dostawcami tryb strict potrafi odciąć legalną korespondencję.

RFC 9989 zmienił również sposób odkrywania polityki, odchodząc od wcześniejszego uzależnienia od Public Suffix List. Wprowadza między innymi politykę dla nieistniejących subdomen poprzez np oraz znacznik t służący do sygnalizowania trybu testowego. Historyczny mechanizm pct nie jest częścią nowego modelu polityki.^[1]

To ma praktyczne znaczenie w 2026 r. Specyfikacja jest świeża, a dokumentacja i implementacje dostawców mogą nadal opisywać rekordy według RFC 7489. Audyt powinien zapisać osobno zgodność z aktualnym standardem i zgodność operacyjną z odbiorcami, na których organizacji zależy. Te dwie rzeczy potrafią się w okresie przejściowym rozjeżdżać.

Raporty DMARC są źródłem danych, nie dekoracją

Raporty zbiorcze DMARC pozwalają zobaczyć, jakie źródła wysyłają pocztę z użyciem domeny, jak odbiorcy oceniają SPF i DKIM oraz gdzie występują niezgodności. RFC 9990 definiuje ich aktualny format.^[2]

Samo wpisanie adresu rua bez procesu obsługi raportów niewiele zmienia. Organizacja potrzebuje właściciela, retencji, sposobu normalizacji i mechanizmu eskalowania nowych źródeł. Przy dużej domenie raporty mogą ujawnić system marketingowy, urządzenie wielofunkcyjne, dostawcę SaaS albo starą aplikację, o której zespół bezpieczeństwa nie wiedział. To zwykle najcenniejszy pojedynczy efekt audytu poczty.

Raporty należy traktować jako nieufne dane zewnętrzne. Parser nie powinien bez kontroli wykonywać zawartych w nich wartości, pobierać wskazanych zasobów ani przekazywać surowych treści do automatyzacji o szerokich uprawnieniach.

Transport SMTP: TLS, MTA-STS, TLS-RPT i DANE

SPF, DKIM i DMARC dotyczą przede wszystkim uwierzytelniania domeny i oceny wiadomości. Nie zapewniają szyfrowania transportu między serwerami.

MTA-STS pozwala domenie odbiorcy zadeklarować oczekiwanie dotyczące TLS i tożsamości serwera przy dostarczaniu poczty. TLS-RPT umożliwia raportowanie problemów związanych z negocjacją TLS, routingiem i politykami MTA-STS lub DANE. DANE for SMTP opiera się na DNSSEC i rekordach TLSA.^[6]

Mechanizmy te chronią określone odcinki transportu serwer-serwer. Nie są szyfrowaniem end-to-end. Administrator serwera pocztowego i system docelowy nadal mogą mieć dostęp do treści wiadomości, co ma znaczenie przy ocenie środków z art. 32 RODO.^[15]

ARC i przekazywanie wiadomości

Przekierowania, listy dyskusyjne i bramki mogą modyfikować wiadomość w sposób powodujący problemy z SPF lub DKIM. ARC zapisuje uwierzytelniony łańcuch wcześniejszych ocen i może dostarczyć odbiorcy dodatkowego kontekstu.^[7]

ARC nie naprawia DMARC i nie daje automatycznej zgody na przyjęcie wiadomości. Odbiorca musi zdecydować, czy ufa systemom tworzącym łańcuch oraz czy informacje są spójne. RFC 8617 ma status Experimental, co również warto zapisać w dokumentacji architektury, zamiast przedstawiać ARC jako gotowe rozwiązanie problemu przekazywania.^[7]

SMTP smuggling i granice warstwy uwierzytelniania

Badanie opublikowane na USENIX Security 2025 pokazało, że niespójna interpretacja granic wiadomości SMTP przez różne serwery może umożliwiać spoofing mimo mechanizmów SPF i DMARC. Autorzy zbadali publiczne i prywatne usługi pocztowe, oprogramowanie open source oraz bramy bezpieczeństwa i wykazali, że problem nie sprowadza się do błędnego rekordu DNS.^[12]

Wniosek dla audytu jest prosty: poprawne SPF, DKIM i DMARC nie pozwala stwierdzić, że cała ścieżka pocztowa jest bezpieczna. Trzeba również zidentyfikować serwery pośredniczące, wersje oprogramowania, sposób parsowania SMTP i stan aktualizacji. To już obszar wspólny ze skanowaniem podatności i hardeningiem, a nie z konfiguracją DNS.

Bezpieczeństwo skrzynki i ochrona odbiorcy

Uwierzytelnianie domeny nie chroni przed przejęciem konta, a przejęte konto wysyła pocztę, która przechodzi SPF, DKIM i DMARC bez zarzutu. Dlatego audyt poczty musi objąć samą platformę:

• MFA dla wszystkich kont, ze szczególną uwagą na role administracyjne;
• protokoły starszego typu, które omijają nowoczesne uwierzytelnianie;
• reguły przekazywania wiadomości na zewnątrz, tworzone przez użytkowników;
• aplikacje OAuth z dostępem do skrzynek i zakres ich uprawnień;
• rejestrowanie zdarzeń, retencję logów i alerty o nietypowym logowaniu;
• procedurę po przejęciu konta: unieważnienie sesji, przegląd reguł, powiadomienia.

Osobną warstwą jest ochrona odbiorcy: detekcja podszywania się nazwą wyświetlaną, analiza odnośników i załączników, oznaczanie poczty spoza organizacji oraz prosty, jednoklikowy sposób zgłoszenia podejrzanej wiadomości. Ten ostatni element jest tańszy niż większość rozwiązań technicznych i najczęściej brakuje go w organizacjach, które mają poprawny rekord DMARC.

Gmail, Yahoo i Outlook.com: wymagania dostarczalności, nie prawo

Od 1 lutego 2024 r. Gmail wymaga od wszystkich nadawców między innymi SPF lub DKIM, TLS i prawidłowego DNS, a od nadawców wysyłających ponad 5000 wiadomości dziennie do kont Gmail dodatkowo SPF, DKIM i DMARC oraz zgodności domen dla wiadomości bezpośrednich.^[8]

Yahoo wymaga od nadawców masowych SPF i DKIM oraz ważnej polityki DMARC co najmniej p=none, a także zgodności domeny From: z domeną SPF lub DKIM.^[9]

Outlook.com wprowadził w 2025 r. wymagania SPF, DKIM i DMARC dla domen wysyłających ponad 5000 wiadomości dziennie do usług konsumenckich Microsoftu, z egzekwowaniem od 5 maja 2025 r.^[10]

To wymagania operatorów usług dotyczące dostarczalności i przeciwdziałania nadużyciom. Nie należy przedstawiać ich jako powszechnego obowiązku prawnego. Dla organizacji wysyłającej korespondencję do tych odbiorców stają się jednak realnym wymaganiem operacyjnym, którego niespełnienie widać natychmiast w postaci niedostarczonych wiadomości.

Czy polskie prawo wymaga DMARC

Nie istnieje ogólny przepis nakazujący każdej polskiej organizacji wdrożenie DMARC.

KSC po nowelizacji obowiązującej od 3 kwietnia 2026 r. wymaga od podmiotów kluczowych i ważnych środków zarządzania ryzykiem obejmujących między innymi bezpieczeństwo komunikacji, kontrolę dostępu i ochronę systemów.^[13] Dobór SPF, DKIM, DMARC, MTA-STS albo DANE zależy od architektury i ryzyka, a nie od katalogu narzędzi.

Dla określonych dostawców usług cyfrowych objętych bezpośrednio rozporządzeniem wykonawczym (UE) 2024/2690 wymagania są bardziej konkretne. Akt wymaga planu wdrażania nowoczesnych, interoperacyjnych standardów komunikacji pocztowej służących zabezpieczeniu poczty i ograniczaniu związanych z nią zagrożeń.^[14] Nadal nie sprowadza to całego wymagania do pojedynczego rekordu DMARC.

RODO wymaga środków bezpieczeństwa odpowiednich do ryzyka dla danych osobowych.^[15] DMARC może ograniczać ryzyko podszywania się pod domenę, ale nie jest wymieniony jako obowiązek powszechny.

KRI wymaga od objętych podmiotów ochrony informacji i systemów, zarządzania ryzykiem, aktualizacji, wykrywania nieautoryzowanych działań i właściwych regulacji wewnętrznych.^[16] Audyt poczty może stanowić jeden z dowodów oceny tych mechanizmów w audycie KRI, ale go nie zastępuje.

Jak wygląda rzetelny audyt poczty

Audyt powinien rozpocząć się od inwentaryzacji domen, subdomen i źródeł wysyłki. Należy znaleźć nie tylko główny serwer pocztowy, ale też systemy marketingowe, CRM, helpdesk, urządzenia wielofunkcyjne, aplikacje biznesowe, usługi monitoringu i dostawców wysyłających komunikaty w imieniu organizacji.

Następnie bada się:

1. DNS i źródła wysyłki - SPF, DKIM, DMARC, MX, delegacje i rekordy związane z transportem.
2. Rzeczywiste wiadomości - nagłówki Authentication-Results, Received, DKIM-Signature i Return-Path.
3. Alignment - czy legalne strumienie przechodzą DMARC właściwą metodą.
4. Raporty - czy organizacja zna wszystkie źródła i potrafi wyjaśnić anomalie.
5. Transport - TLS, MTA-STS z TLS-RPT albo DANE, jeśli organizacja je stosuje.
6. Platformę pocztową - MFA, role administracyjne, protokoły starszego typu, reguły przekazywania, aplikacje OAuth, logowanie i alerty.
7. Ochronę użytkownika - antyphishing, detekcję podszywania się nazwą, analizę odnośników i załączników, mechanizm zgłaszania.
8. Procedury - onboarding dostawcy, zmiany DNS, kompromitacja klucza, przejęcie konta, usunięcie starego źródła.

Dopiero po potwierdzeniu legalnych strumieni można przechodzić do silniejszego egzekwowania polityki. Zmiana p=none bezpośrednio na reject bez danych o rzeczywistej wysyłce potrafi odrzucić fakturę, powiadomienie systemowe albo korespondencję działu sprzedaży, a przyczyna zostanie znaleziona dopiero po kilku dniach.

W audytach poczty 4crypto warto połączyć warstwę DNS z analizą rzeczywistych nagłówków i raportów. Sam zrzut ekranu walidatora pokazujący trzy zielone ikony nie jest dowodem, że wszystkie strumienie działają prawidłowo.