SPF, DKIM i DMARC dla domeny wysyłkowej — konfiguracja krok po kroku

Zespół przenosi wysyłkę na osobną domenę, zakłada cztery skrzynki, wpina je do sekwencera i po dwóch tygodniach większość wiadomości do odbiorców na Outlooku ląduje w folderze Junk. Konfiguracja DNS wygląda poprawnie, bo jest w niej SPF, jest DKIM i jest DMARC. Dopiero w nagłówkach odebranej wiadomości widać, że podpis DKIM należy do domeny dostawcy narzędzia, adres zwrotny wskazuje na tę samą domenę, a w polu From stoi domena firmowa. Uwierzytelnianie przechodzi, zgodność domen nie.

To najczęstsza pojedyncza przyczyna, dla której poprawnie wyglądająca konfiguracja nie działa u nadawcy outboundowego. Google w wytycznych obowiązujących od 1 lutego 2024 roku wymaga od nadawców masowych, żeby domena widoczna w nagłówku From była zgodna z domeną sprawdzaną przez SPF albo z domeną, która podpisała wiadomość kluczem DKIM. Wynik pass w obu mechanizmach nie wystarcza, jeżeli dotyczy cudzej domeny.

Wszystkie przykłady poniżej zakładają osobną domenę wysyłkową, oddzieloną od domeny korporacyjnej, bo tak wygląda typowa infrastruktura outboundowa i bo to zmienia część decyzji konfiguracyjnych. Na domenie, z której wychodzą również faktury i powiadomienia systemowe, część kroków opisanych dalej trwa miesiącami zamiast tygodnia.

Co odpowiada za co

SPF to opublikowana w DNS lista serwerów, którym wolno wysyłać pocztę w imieniu domeny. Serwer odbiorcy porównuje adres IP, z którego przyszło połączenie, z tą listą i zwraca wynik. Sprawdzana jest przy tym domena z koperty SMTP, czyli z adresu zwrotnego, a nie ta, którą odbiorca widzi w kliencie pocztowym. To rozróżnienie wraca za chwilę przy alignmencie i jest źródłem większości nieporozumień na temat SPF.

DKIM to podpis kryptograficzny nałożony na wybrane nagłówki oraz na treść wiadomości. Klucz publiczny leży w DNS pod nazwą selektora, klucz prywatny zostaje na serwerze wysyłającym. Odbiorca przelicza podpis i dowiaduje się dwóch rzeczy: czy wiadomość zmieniono w drodze i która domena wzięła za nią odpowiedzialność. DKIM przeżywa przekazanie wiadomości dalej, SPF przy forwardowaniu zwykle się wywraca, bo zmienia się adres IP nadawcy.

DMARC sam z siebie niczego nie uwierzytelnia. Mówi serwerowi odbiorcy, co zrobić z wiadomością, w której domena z pola From nie zgadza się z żadnym uwierzytelnionym identyfikatorem, i wskazuje adres, na który mają iść raporty o tym, kto wysyła pocztę w imieniu domeny. Wymogi Google i Yahoo z 2024 roku oraz Microsoftu z maja 2025 roku żądają rekordu DMARC z polityką minimum p=none, czyli takiej, która nie każe odbiorcy robić niczego. Sens tego wymogu leży w raportach, nie w egzekwowaniu.

Podział obowiązków jest tu ostrzejszy, niż się wydaje z opisów w panelach narzędzi. Google od wszystkich nadawców wymaga SPF albo DKIM, do wyboru, a dopiero od nadawców masowych obu naraz. Próg nadawcy masowego to 5 000 wiadomości na dobę wysłanych na adresy Gmail, liczone per domena nadawcy, i po jego przekroczeniu klasyfikacja zostaje na stałe. Typowa polska kampania outboundowa z pięciu skrzynek po czterdzieści wiadomości dziennie nigdy tego progu nie dotknie, co nie zwalnia jej z wymogów podstawowych.

Alignment, czyli miejsce, w którym sypie się najwięcej konfiguracji

Alignment to zgodność domeny z pola From z domeną, którą potwierdził SPF, albo z domeną z podpisu DKIM, oznaczaną w nagłówku jako d=. DMARC przechodzi wtedy, gdy przynajmniej jeden z tych dwóch identyfikatorów jest jednocześnie uwierzytelniony i zgodny. Wystarczy jeden, więc konfiguracja, w której SPF wskazuje na infrastrukturę dostawcy, a DKIM podpisuje twoją domenę, jest poprawna.

Tryb zgodności bywa dwojaki. Relaxed dopuszcza różnicę na poziomie subdomeny, czyli podpis z wysylka.firma-kontakt.pl pasuje do adresu w domenie firma-kontakt.pl. Strict wymaga identycznego ciągu znaków. Yahoo w wymogach z 2024 roku wprost akceptuje relaxed i przy okazji formułuje warunek ostrzejszy niż Google, bo żąda, żeby DMARC faktycznie przechodził, a nie tylko żeby rekord DMARC istniał w DNS.

Sprawdzenie stanu faktycznego zajmuje minutę i nie wymaga żadnego narzędzia. Wysyłasz wiadomość z sekwencera na własny adres u innego dostawcy poczty, otwierasz pełne nagłówki odebranej wiadomości i szukasz linii Authentication-Results. Są w niej trzy interesujące wartości: wynik SPF wraz z domeną, dla której został policzony, wynik DKIM z parametrem header.d, oraz wynik DMARC z parametrem header.from. Jeżeli header.d albo domena z SPF nie pokrywa się z header.from, masz odpowiedź, zanim ktokolwiek zacznie poprawiać treść wiadomości. Ten test warto powtórzyć osobno dla Gmaila, dla Outlooka i dla polskiego dostawcy hostingu poczty, bo interpretacje bywają różne, a raporty w panelu sekwencera pokazują wyłącznie to, co narzędzie samo o sobie wie.

W praktyce sekwencery wysyłają przez własne serwery i domyślnie wpisują własną domenę w adres zwrotny. SPF potwierdza wtedy ich domenę i alignment przez SPF jest nieosiągalny. Zostaje DKIM, więc w panelu narzędzia trzeba włączyć podpisywanie własną domeną, co zwykle nazywa się custom domain authentication albo własnym rekordem DKIM, i dopiero to tworzy zgodność. Jeżeli narzędzie nie oferuje takiej opcji, nadal da się przez nie wysyłać, ale nie da się spełnić wymogu alignmentu dla nadawcy masowego i nie ma sensu tego obchodzić.

Wpisy DNS, które trzeba założyć

Rekord SPF dla domeny wysyłkowej wygląda tak:

firma-kontakt.pl.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.narzedzie.example -all"

Dwa include, bo poczta wychodzi z Google Workspace oraz z sekwencera. Kwalifikator -all oznacza twarde odrzucenie wszystkiego spoza listy i na osobnej domenie wysyłkowej jest właściwym wyborem, bo dokładnie wiadomo, co z niej nadaje. Na domenie korporacyjnej bezpieczniej zacząć od ~all, czyli softfail, i zaostrzyć dopiero po przejrzeniu raportów DMARC, bo prawie zawsze znajduje się jakiś zapomniany system, który legalnie wysyła pocztę.

Rekord DKIM zakłada się osobno dla każdego nadawcy, pod jego własnym selektorem:

selektor1._domainkey.firma-kontakt.pl.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Klucz publiczny generuje narzędzie i podaje gotową wartość do skopiowania. Klucz 2048-bitowy nie mieści się w pojedynczym ciągu TXT i część paneli DNS wymaga podzielenia go na fragmenty, co jest najczęstszym powodem, dla którego świeżo dodany DKIM nie waliduje się mimo poprawnie skopiowanej wartości. Selektory rozdzielają nadawców, więc dodanie drugiego narzędzia nie wymaga ruszania pierwszego rekordu.

Rekord DMARC jest jeden na domenę i zaczyna się od polityki obserwacyjnej:

_dmarc.firma-kontakt.pl.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@firma-kontakt.pl; fo=1; adkim=r; aspf=r; pct=100"

Adres w rua powinien być skrzynką techniczną, a nie prywatną, bo raporty zbiorcze przychodzą codziennie z każdego większego dostawcy poczty w formacie XML i bez parsera są nieczytelne. Parametry adkim=r i aspf=r ustawiają tryb relaxed, który jest domyślny, ale lepiej mieć go wpisanego wprost, żeby przy przeglądzie konfiguracji nie było wątpliwości. Rekord PTR, czyli odwrotny DNS dla adresu IP, nie jest częścią tego zestawu i przy wysyłce z Google Workspace lub Microsoft 365 należy do dostawcy.

Komplet trzech rekordów zakłada się osobno na każdej domenie wysyłkowej, co przy rotacji domen robi się pracochłonne i bywa pomijane właśnie na tej domenie, którą dodano w pośpiechu. Sales.co, czyli dostawca infrastruktury wysyłkowej, rekomenduje na podstawie analizy ponad dwóch milionów cold maili z lat 2025-2026 dwie do trzech skrzynek na domenę, więc program wysyłający dwieście wiadomości dziennie potrzebuje dwóch domen i sześciu kompletów wpisów DNS. Warto to policzyć przed zakupem domen, bo koszt utrzymania konfiguracji rośnie liniowo z ich liczbą, a każda pominięta domena wraca w postaci kampanii, która milczy bez wyraźnego powodu.

Droga od p=none do quarantine

Polityka p=none istnieje po to, żeby przez kilka tygodni patrzeć, kto wysyła pocztę w imieniu domeny, zanim zacznie się cokolwiek blokować. Raporty zbiorcze pokazują adresy IP, wyniki SPF i DKIM oraz liczbę wiadomości z każdego źródła. Na osobnej domenie wysyłkowej lista źródeł jest krótka i po dwóch tygodniach zwykle wszystko się zgadza. Na domenie korporacyjnej pojawiają się rzeczy, o których nikt nie pamiętał: stary system do wysyłki potwierdzeń zamówień, narzędzie do ankiet pracowniczych, formularz na stronie nadający przez serwer agencji.

Kolejny krok to p=quarantine z parametrem pct, który określa, jaki procent niezgodnych wiadomości ma podlegać polityce:

_dmarc.firma-kontakt.pl.  3600  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@firma-kontakt.pl; fo=1"

Dwadzieścia pięć procent przez tydzień, potem pięćdziesiąt, potem sto. Sensem tego stopniowania jest to, że jeżeli coś przeoczysz, stracisz jedną czwartą wiadomości z zapomnianego systemu, a nie wszystkie, i zdążysz to zauważyć w raportach. Dopiero po miesiącu na p=quarantine pct=100 ma sens rozmowa o p=reject.

Zaostrzanie polityki nie jest przy tym drogą do lepszej dostarczalności kampanii. Wszyscy trzej dostawcy wymagają wyłącznie p=none jako minimum i nie deklarują premii za politykę ostrzejszą. Nie znam badania, które mierzyłoby wpływ samego p=reject na umieszczenie w skrzynce odbiorczej. Uzasadnieniem dla p=reject jest ochrona domeny przed podszywaniem się, a to jest zupełnie inny problem niż to, czy twoja kampania trafia do skrzynki odbiorczej.

PTR, TLS i zgodność z RFC 5322

Trzy wymogi Google dla wszystkich nadawców, nie tylko masowych, giną w dyskusjach o SPF i DKIM, chociaż potrafią same z siebie zablokować wysyłkę. Pierwszy to poprawny forward i reverse DNS, czyli rekord PTR dla adresu IP serwera nadawczego, rozwiązujący się w obie strony. Przy wysyłce z infrastruktury Google albo Microsoftu to nie jest twój problem. Przy własnym serwerze na maszynie wirtualnej PTR ustawia dostawca hostingu na wniosek i bez tego wniosku pozostaje domyślny, ogólny wpis, który filtry czytają jako sygnał ryzyka.

Drugi wymóg to transmisja po TLS przy nawiązywaniu połączenia. Domyślne konfiguracje popularnych serwerów spełniają go od lat, ale własne skrypty wysyłające przez czysty SMTP na porcie 25 potrafią go pomijać.

Trzeci to zgodność z RFC 5322, czyli ze specyfikacją formatu wiadomości. Chodzi o poprawny nagłówek From z jednym adresem, obecność Date i Message-ID oraz brak zdeformowanych nagłówków. Sekwencery robią to poprawnie z definicji. Problem pojawia się przy wysyłce przez API własnym kodem, gdzie łatwo o wiadomość bez Message-ID albo z dwoma adresami w polu From, co część filtrów punktuje niezależnie od treści. To zresztą jedna z niewielu rzeczy, które filtr naprawdę punktuje, w odróżnieniu od pojedynczych słów w treści.

Cztery błędy, które kosztują najwięcej

Najczęstszy to dwa rekordy SPF na jednej domenie, zwykle po migracji, gdy zostaje wpis od poprzedniego dostawcy i dochodzi nowy. Specyfikacja SPF, czyli RFC 7208, dopuszcza dokładnie jeden rekord na domenę. Przy dwóch serwer odbiorcy zwraca permerror i SPF nie działa w ogóle, choć oba wpisy wyglądają poprawnie. Naprawa polega na scaleniu wszystkich include do jednego rekordu.

Drugi to przekroczenie limitu przeglądań DNS. RFC 7208 dopuszcza maksymalnie dziesięć przeglądań podczas jednej ewaluacji rekordu, licząc mechanizmy include, a, mx, ptr i exists, przy czym include zagnieżdżone liczą się osobno. Google Workspace, sekwencer, CRM, narzędzie do faktur i system do webinarów w jednym rekordzie przekraczają dziesiątkę bez ostrzeżenia. Efektem jest permerror, czyli ten sam skutek co przy dwóch rekordach. Rozwiązania są dwa: rozdzielenie nadawców na subdomeny z osobnymi rekordami albo spłaszczenie include do adresów IP, przy czym spłaszczanie oznacza, że po każdej zmianie infrastruktury po stronie dostawcy trzeba rekord aktualizować ręcznie, bo inaczej cicho się rozjeżdża.

Trzeci to wysyłka z domeny, dla której narzędzie nie ma własnego DKIM, opisana wyżej. Czwarty to -all postawione na domenie korporacyjnej przed przeczytaniem raportów, po którym przestaje działać powiadamianie z jakiegoś systemu wewnętrznego i nikt nie łączy tego z DNS przez pierwsze dwa dni.

Poprawna konfiguracja tych trzech mechanizmów jest warunkiem wstępu, a nie przewagą. Po jej spełnieniu o dostarczalności decyduje odsetek skarg i to, ile wysyłasz z jednej skrzynki, a nie to, ile masz rekordów w DNS. Domena z bezbłędnym uwierzytelnianiem i odsetkiem skarg powyżej progu egzekwowania Google, czyli 0,30 procent, trafia do spamu tak samo jak domena bez DKIM. Woodpecker na próbie ponad dwudziestu milionów wiadomości podaje średni rynkowy poziom odbić 5,1 procent, czyli powyżej granicy, od której według benchmarku weryfikacji Instantly reputacja nadawcy zaczyna być uszkadzana, co dobrze pokazuje proporcje: rynek psuje sobie dostarczalność jakością list i wolumenem na skrzynkę, a nie brakiem rekordów TXT. Zmiana w DNS zajmuje popołudnie i propaguje się w kilka godzin, a odbudowa reputacji domeny po serii skarg zajmuje tygodnie, więc kolejność jest wymuszona przez koszt błędu, nie przez elegancję procesu. Rekordy zakłada się przed rozgrzewaniem skrzynek, bo rozgrzewanie na niezgodnej konfiguracji buduje reputację, którą i tak trzeba będzie zbudować od nowa.