SPF, DKIM i DMARC — konfiguracja poczty na hostingu

SPF, DKIM i DMARC nie są trzema nazwami tego samego zabezpieczenia. Każdy mechanizm odpowiada na inne pytanie: SPF sprawdza, czy dany serwer może wysyłać pocztę dla określonej domeny koperty, DKIM potwierdza podpis wiadomości, a DMARC łączy te wyniki z domeną widoczną w polu From. Poprawna konfiguracja wymaga więc najpierw spisu wszystkich systemów wysyłających, a dopiero później zmian w DNS.

Najbezpieczniejsza kolejność to: zinwentaryzować nadawców, poprawić SPF i DKIM, uruchomić DMARC z p=none, przeanalizować raporty, a dopiero potem rozważyć quarantine lub reject.

Co robią SPF, DKIM i DMARC?

SPF publikuje w DNS listę systemów uprawnionych do wysyłania wiadomości dla domeny użytej w SMTP jako envelope sender, zwykle widocznej później jako Return-Path. Nie sprawdza bezpośrednio adresu pokazywanego odbiorcy w nagłówku From.

DKIM dodaje do wiadomości podpis kryptograficzny. System wysyłający używa klucza prywatnego, a odbiorca pobiera z DNS klucz publiczny. Poprawny podpis potwierdza, że podpisane części wiadomości nie zostały zmienione po drodze i że nadawca kontroluje domenę wskazaną w podpisie.

DMARC sprawdza nie tylko wynik SPF lub DKIM, lecz także ich alignment, czyli zgodność z domeną w widocznym polu From. Następnie pozwala właścicielowi domeny ogłosić politykę postępowania z wiadomościami, które nie przechodzą kontroli, oraz otrzymywać raporty zbiorcze.

Te mechanizmy się uzupełniają. Wiadomość może mieć SPF PASS, ale nie przejść DMARC, jeśli domena Return-Path nie jest zgodna z domeną From. Może też przejść DMARC dzięki zgodnemu podpisowi DKIM, nawet gdy ścieżka przekazywania wiadomości zepsuła wynik SPF.

Zacznij od listy wszystkich systemów wysyłających

Przed edycją DNS wypisz każde miejsce, które wysyła wiadomości z Twoją domeną. W małej firmie rzadko jest to wyłącznie serwer skrzynek. Lista może obejmować:

zwykłe skrzynki pracowników,
formularze i powiadomienia WordPressa,
sklep oraz wiadomości transakcyjne,
newsletter, system CRM lub helpdesk,
program do faktur i system rezerwacji,
urządzenia albo aplikacje wysyłające przez SMTP.

Dla każdego systemu ustal dostawcę, domenę widoczną w From, domenę Return-Path oraz domenę podpisu DKIM. To ważniejsze niż miejsce utrzymywania strony. Jeżeli hosting WWW i poczta są rozdzielone, rekordów uwierzytelniających nie należy kopiować z panelu hostingu tylko dlatego, że strona działa na jego serwerze. Szerzej wybór modelu usługi omawia poradnik poczta w hostingu czy osobna usługa e-mail.

SPF: jeden rekord obejmujący rzeczywistych nadawców

SPF zapisuje się jako rekord TXT. Zaczyna się od v=spf1, po którym występują mechanizmy opisujące dozwolone źródła. Najczęściej spotkasz:

include: — odwołanie do polityki dostawcy poczty lub usługi wysyłkowej,
ip4: i ip6: — konkretne adresy lub zakresy IP,
a i mx — autoryzację adresów wynikających z rekordów A/AAAA albo MX; używaj ich tylko wtedy, gdy te serwery naprawdę wysyłają,
~all — miękkie niepowodzenie dla pozostałych źródeł,
-all — twarde niepowodzenie dla pozostałych źródeł.

v=spf1 include:_spf.example-mail.test ip4:192.0.2.10 ~all

To przykład składni, nie rekord do skopiowania. Domenę include i adres IP zawsze bierze się z instrukcji faktycznego nadawcy. Specyfikacja SPF ogranicza do dziesięciu liczbę mechanizmów i modyfikatorów powodujących zapytania DNS podczas jednej oceny. Dotyczy to między innymi include, a, mx, exists i redirect; same mechanizmy ip4, ip6 oraz all nie zużywają tego limitu.

Przekroczenie limitu nie daje „trochę słabszego SPF”, tylko może zakończyć ocenę błędem permerror. Dlatego dokładanie kolejnych usług przez kolejne include wymaga kontroli także ich zagnieżdżonych odwołań. Po migracji usuń stare źródło dopiero wtedy, gdy przestało wysyłać. Jednocześnie nie publikuj dwóch rekordów zaczynających się od v=spf1: odbiorca nie może ich bezpiecznie scalić, co również prowadzi do błędu. Potwierdza to także dokumentacja Microsoft Learn dotycząca SPF.

Wybór ~all albo -all powinien wynikać ze stopnia rozpoznania źródeł. Twarde -all ma sens dopiero wtedy, gdy lista jest kompletna. Nie naprawia braku DKIM ani alignment DMARC.

DKIM: podpis musi powstawać u faktycznego nadawcy

Dostawca generuje parę kluczy. Klucz prywatny zostaje w systemie podpisującym, a klucz publiczny trafia do DNS pod nazwą zawierającą selektor, na przykład:

mail2026._domainkey.example.pl

Selektor mail2026 nie jest uniwersalny. Podaje go konkretny dostawca. Jeden operator może użyć rekordu TXT, inny poprosić o CNAME prowadzący do własnej infrastruktury. Różni nadawcy mogą równolegle używać różnych selektorów; to normalne i ułatwia rotację kluczy. Mechanizm selektorów i pobierania klucza z DNS opisuje standard DKIM.

Rekord DKIM ma znaczenie tylko wtedy, gdy rzeczywiście powstaje podpis z odpowiadającym mu selektorem i domeną. Samo wklejenie klucza publicznego do DNS nie włącza podpisywania. Po migracji poczty stary selektor może pozostać potrzebny przez krótki okres przejściowy, jeśli stary system nadal wysyła albo wiadomości są w drodze. Później warto go usunąć zgodnie z procedurą dostawcy, zamiast zakładać, że każdy rekord _domainkey jest nadal aktywny.

DMARC: wynik uwierzytelnienia i zgodność domen

Rekord DMARC publikuje się jako TXT pod adresem _dmarc.example.pl. Minimalny rekord monitorujący może wyglądać tak:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.pl

p=none nie żąda kwarantanny ani odrzucania wiadomości. Raporty zbiorcze można zamówić osobno przez rua. p=quarantine wskazuje, że wiadomości niespełniające zasad powinny być traktowane podejrzliwie, a p=reject — odrzucane. Ostateczna obsługa należy do odbiorcy, dlatego polityka nie jest gwarancją identycznego zachowania wszystkich systemów.

Na czym polega alignment DMARC?

DMARC porównuje domenę z pola From, które widzi użytkownik, z domeną uwierzytelnioną przez SPF albo DKIM. Przy alignment łagodnym wystarczy ta sama domena organizacyjna, na przykład mail.example.pl i example.pl. Przy alignment ścisłym domeny muszą być identyczne. Wiadomość przechodzi DMARC, gdy co najmniej jeden mechanizm — SPF lub DKIM — zarówno przejdzie kontrolę, jak i będzie zgodny z From.

Przykład: newsletter ma From biuro@example.pl, ale jego Return-Path należy do domeny operatora mailer.test. SPF może przejść dla mailer.test, lecz nie jest zgodny z example.pl. DMARC może mimo to przejść, jeżeli dostawca podpisze wiadomość DKIM domeną example.pl. Zasady alignment i sposób łączenia wyników opisuje aktualny RFC 9989 dla DMARC.

Raporty rua i ograniczenia ruf

rua wskazuje adres raportów zbiorczych. Raporty zwykle są plikami maszynowymi i pokazują źródła, wolumen oraz wyniki uwierzytelnienia; format raportów zbiorczych opisuje RFC 9990. Adres powinien być przygotowany na ich obsługę; nie warto kierować ich do zwykłej skrzynki pracownika bez procesu analizy.

ruf służy do wskazania adresów dla raportów o niepowodzeniach, lecz nie każdy odbiorca je wysyła, a ich treść może rodzić kwestie prywatności. Nie należy uzależniać wdrożenia od otrzymywania raportów ruf; współczesny format failure reports opisuje RFC 9991.

Dlaczego nie zaczynać od p=reject?

Najpierw trzeba ujawnić wszystkie legalne strumienie poczty. Pominięty system faktur, formularz albo newsletter może po włączeniu restrykcyjnej polityki zacząć tracić wiadomości. Praktyczna ścieżka to:

ustawić poprawne SPF i DKIM dla wszystkich rzeczywistych nadawców,
opublikować DMARC z p=none i adresem rua,
obserwować raporty przez okres obejmujący także rzadsze wysyłki,
naprawić niezgodności i dopiero potem rozważyć quarantine,
przejść do reject dopiero przy pełnym rozpoznaniu skutków, w tym przekierowań i list dyskusyjnych.

Dokumentacja Google nadal pokazuje etapowe wdrożenie z tagiem pct. Aktualny RFC 9989 usunął jednak pct ze standardu z powodu niejednolitej implementacji. Dlatego w nowej, niezależnej od jednego dostawcy konfiguracji nie warto opierać bezpieczeństwa na procentowym egzekwowaniu. Jeżeli konkretny operator nadal zaleca ten tag, trzeba traktować to jako instrukcję jego środowiska, a nie uniwersalną właściwość aktualnego DMARC. RFC 9989 wprowadził natomiast tag t; wartość t=y oznacza tryb testowy, ale nie jest procentowym wdrażaniem polityki znanym z dawnego pct. Sama zasada stopniowego wdrożenia pozostaje rozsądna; opisuje ją instrukcja wdrażania DMARC w Google Workspace.

Trzy typowe układy usług

Strona i poczta u jednego operatora

Operator często podaje gotowe wartości, ale rekordy trzeba dodać tam, gdzie znajdują się autorytatywne serwery DNS domeny. Panel hostingu może jedynie wyświetlać zalecenia, jeżeli DNS obsługuje rejestrator, Cloudflare albo inna firma. Przed zmianą sprawdź delegację domeny i istniejące rekordy.

Hosting WWW i poczta u różnych dostawców

SPF uwzględnia systemy naprawdę wysyłające. DKIM pochodzi od dostawcy, który podpisuje wiadomości. DMARC pozostaje polityką domeny. Rekord MX informuje, gdzie odbierać pocztę, ale sam nie konfiguruje uwierzytelniania wysyłki. Rozdzielenie usług nie jest błędem — wymaga tylko spójnej listy odpowiedzialności.

Kilka niezależnych systemów wysyłających

Każdy strumień należy sprawdzić osobno. Skrzynki mogą używać jednego include SPF i selektora DKIM, newsletter drugiego selektora, a sklep zewnętrznego Return-Path. Nie zakładaj, że dodanie dostawcy skrzynek automatycznie obejmuje sklep lub formularz. Po zmianie usług przydaje się plan z poradnika jak przenieść pocztę na inny hosting; uwierzytelnianie trzeba uwzględnić obok skrzynek i MX.

WordPress i formularze: From nie jest adresem odwiedzającego

Wysyłka przez lokalne mail() lub lokalny MTA może utrudniać kontrolę nad Return-Path, podpisem DKIM i reputacją infrastruktury. SMTP albo API właściwego dostawcy zwykle pozwala wyraźniej ustalić, kto autoryzuje wysyłkę. Nie oznacza to jednak, że sama instalacja wtyczki SMTP automatycznie poprawia DNS i alignment.

Formularz powinien używać w From adresu kontrolowanego przez właściciela domeny, na przykład formularz@example.pl. Adres podany przez odwiedzającego może trafić do Reply-To. Ustawienie obcego adresu użytkownika jako From powoduje, że strona próbuje nadawać w imieniu domeny, której nie kontroluje. Dokumentacja funkcji wp_mail() rozróżnia nagłówki From i Reply-To oraz zaznacza, że samo przyjęcie wiadomości przez funkcję nie oznacza jej doręczenia. Gdy trzeba najpierw ustalić, czy aplikacja w ogóle uruchamia wysyłkę, zobacz WordPress nie wysyła e-maili.

Jak sprawdzić konfigurację bez udawania dostarczenia?

Po zapisaniu rekordów nie wystarczy sprawdzić, że panel przyjął tekst. Kontrola powinna objąć DNS i rzeczywistą wiadomość z każdego systemu wysyłającego.

Sprawdź autorytatywny DNS. Odczytaj TXT domeny, selektor DKIM i rekord _dmarc. Upewnij się, że nie edytowałeś nieużywanej strefy.
Zweryfikuj SPF. Potwierdź jeden rekord v=spf1, wszystkie legalne źródła i liczbę zapytań DNS.
Wyślij wiadomość testową z każdego strumienia. Osobno ze skrzynki, WordPressa, sklepu, newslettera i innych usług.
Odczytaj pełne nagłówki. Szukaj wyników SPF, DKIM i DMARC, domen użytych do oceny oraz selektora DKIM.
Sprawdź alignment. Porównaj widoczne From z domeną Return-Path dla SPF i domeną d= podpisu DKIM.
Przejrzyj raporty DMARC. Zidentyfikuj źródła legalne, nieznane i błędnie skonfigurowane. Nie wyciągaj wniosków z jednego dnia, jeśli część systemów wysyła rzadziej.
Powtórz kontrolę po zmianach. Zmiana dostawcy, newslettera, formularza lub systemu faktur może wymagać aktualizacji rekordów.

Jeżeli masz pełne nagłówki odebranej wiadomości, możesz lokalnie przeanalizować nagłówki SPF, DKIM i DMARC oraz sprawdzić zapisane wyniki i alignment.

Przed zmianą DNS warto też wykonać kontrolę usług według poradnika jak sprawdzić stronę na nowym hostingu przed zmianą DNS. Nie potwierdzi on samych rekordów pocztowych, ale pomaga oddzielić testy wykonywane przed delegacją od kontroli po przełączeniu.

Najczęstsze błędy

Dwa rekordy SPF. Powinien istnieć jeden rekord obejmujący wszystkie źródła.
Zbyt wiele include. Łańcuch przekracza limit zapytań DNS i kończy się permerror.
Stary include po migracji. Niepotrzebnie rozszerza listę uprawnionych nadawców.
DKIM starego dostawcy. Rekord istnieje, ale aktualny system nie podpisuje odpowiadającym kluczem.
p=reject bez monitoringu. Legalne, pominięte źródła zaczynają być odrzucane.
Brak alignment. SPF lub DKIM przechodzi, lecz dla domeny niezwiązanej z widocznym From.
Newsletter poza konfiguracją. Osobna platforma nie została ujęta w SPF ani nie dostała zgodnego DKIM.
Obcy From w formularzu. Adres odwiedzającego ustawiono jako nadawcę zamiast Reply-To.
Edycja złej strefy DNS. Rekord dodano w panelu, który nie obsługuje autorytatywnych DNS domeny.
Kopiowanie przykładu. Testowa domena, selektor lub adres raportów pozostały bez podmiany.

Czego SPF, DKIM i DMARC nie gwarantują?

Poprawne uwierzytelnianie nie gwarantuje miejsca w skrzynce odbiorczej. Odbiorcy oceniają też reputację domeny i adresu IP, skargi, jakość listy, częstotliwość wysyłki, treść oraz zachowanie użytkowników. Prawidłowo podpisany spam nadal może być spamem. Osobno omawiamy spam mimo SPF, DKIM i DMARC.

Mechanizmy nie zastępują ochrony kont: unikalnych haseł, MFA, kontroli dostępu i reakcji na przejęcie skrzynki. Nie blokują każdego phishingu, zwłaszcza z podobnych domen albo przejętych, prawidłowo uwierzytelnionych kont. Nie potwierdzają też, że treść wiadomości jest prawdziwa.

Praktyczna checklista wdrożenia

Spisz wszystkie systemy wysyłające i właścicieli każdego z nich.
Ustal, gdzie działa autorytatywny DNS domeny.
Połącz legalnych nadawców w jeden rekord SPF i policz mechanizmy DNS.
Włącz DKIM u każdego faktycznego nadawcy i zapisz używany selektor.
Sprawdź From, Return-Path oraz domenę d= podpisu.
Uruchom DMARC z p=none i działającym adresem raportowym.
Wyślij test z każdej skrzynki, aplikacji i platformy.
Przeanalizuj raporty z okresu obejmującego rzadsze wysyłki.
Dopiero po naprawieniu legalnych źródeł rozważ quarantine i reject.
Po każdej migracji usuń nieużywane uprawnienia i powtórz kontrolę.

Jeżeli domena i hosting są utrzymywane w różnych firmach, warto wcześniej rozpisać, kto zarządza DNS, pocztą i stroną. Pomaga w tym poradnik domena i hosting w jednej firmie czy osobno. Najważniejsze jest jednak nie miejsce zakupu usługi, lecz spójność konfiguracji wszystkich rzeczywistych nadawców.

SPF, DKIM i DMARC — jak poprawnie skonfigurować pocztę na hostingu