Jak ustawić rekord SPF, DKIM i DMARC

Poprawnie skonfigurowane mechanizmy autoryzacji poczty chronią domenę przed podszywaniem się i znacząco zwiększają szanse na dotarcie wiadomości do skrzynki odbiorczej. W tym poradniku, krok po kroku, ustawisz SPF, DKIM i DMARC w panelu DNS swojej domeny, zrozumiesz ich działanie oraz nauczysz się testować wyniki. Instrukcja obejmuje najczęstsze przypadki: własny serwer, Google Workspace, Microsoft 365, narzędzia mailingowe i systemy CRM.

Fundamenty: jak działają SPF, DKIM i DMARC

Co to jest DNS i gdzie dodać rekordy

Wszystkie trzy mechanizmy działają poprzez publiczne rekordy w strefie DNS Twojej domeny. Rekordy dodajesz tam, gdzie zarządzasz strefą domeny (rejestrator, panel hostingu, Cloudflare, panel serwera). Najczęściej będą to rekordy TXT, a w przypadku DKIM — również selektor jako część nazwy. Zwróć uwagę, że zmiany mogą propagować się od kilku minut do nawet 24–48 godzin w zależności od TTL i sieci rekursywnych resolverów.

Rola SPF, DKIM i DMARC

• SPF: określa, które serwery mogą wysyłać pocztę w imieniu domeny. Odbiorca sprawdza IP nadawcy względem rekordu SPF domeny w polu MAIL FROM (envelope).
• DKIM: podpis kryptograficzny nagłówków i treści wiadomości przypisany do domeny. Odbiorca weryfikuje podpis kluczem publicznym z rekordu TXT selector._domainkey.domena.
• DMARC: łączy SPF i DKIM oraz definiuje policy dla odbiorców (co robić z mailami, które nie przejdą weryfikacji) i zasady alignment (zgodności domen).

Alignment: sedno DMARC

DMARC uznaje wiadomość za autoryzowaną, gdy co najmniej jeden z mechanizmów (SPF lub DKIM) przejdzie i jest dopasowany do domeny w polu From:. Dopasowanie może być relaxed (r) lub strict (s). W trybie relaxed domeny mogą różnić się na poziomie subdomen, a w trybie strict muszą być identyczne. Przykład: From: sklep.example.com, DKIM podpisany example.com — relaxed przejdzie, strict nie.

Typowe błędy i mity

• SPF bez -all to niepełna ochrona — odbiorcy nie mają twardej wskazówki, co robić z nieautoryzowanym źródłem.
• Sam DKIM bez DMARC nie powie, co zrobić z nieudanym podpisem (brak polityki).
• DMARC p=reject bez monitoringu potrafi zablokować legalne wysyłki (np. z CRM, helpdesku, systemu faktur), jeśli zapomnisz je dodać do SPF lub DKIM.

Konfiguracja SPF krok po kroku

Krok 1: Spisz wszystkie źródła wysyłki

Zidentyfikuj wszystko, co wysyła wiadomości z Twojej domeny: serwer WWW, serwer pocztowy, Google Workspace, Microsoft 365, platformy mailingowe (np. SendGrid, Mailgun), systemy CRM, helpdesk, marketing automation, system fakturowy, urządzenia (skanery, drukarki). Ustal ich IP lub domeny, które należy uwzględnić w SPF.

Krok 2: Zbuduj poprawny rekord SPF

Rekord SPF to TXT dodany na nazwie domeny (host: @). Minimalna składnia: v=spf1 [mechanizmy] [kwalifikator]. Typowe mechanizmy:

• ip4:203.0.113.10 — zezwala konkretnemu adresowi IPv4
• a, mx — zezwalają adresom wynikającym z rekordów A/MX domeny
• include:_spf.google.com — deleguje sprawdzenie do zewnętrznego dostawcy
• ptr — niezalecany
• ~all — softfail (oznacz podejrzane, ale potencjalnie dostarcz)
• -all — twardy fail (reject według intencji nadawcy)

Przykład dla Google Workspace + Microsoft 365 + SendGrid + jeden adres IP serwera WWW:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ip4:203.0.113.10 -all

Najważniejsze zasady:

• Jeden rekord SPF na domenę (TXT). Jeśli masz kilka, scal je.
• Limit 10 DNS-lookupów w SPF (include, a, mx, ptr, exists, redirect). Przekroczenie skutkuje temperror/permanenterror u odbiorcy. Optymalizuj, usuwaj zbędne include.
• Unikaj +all oraz ?all — osłabiają ochronę i zwiększają spam.
• Ustal spójne źródła — jeśli wysyłasz z subdomen (np. mail.example.com), rozważ dedykowany SPF dla subdomeny i DMARC sp=.

Krok 3: Dodaj rekord w panelu

• Nazwa/Host: @ (lub zostaw pustą nazwę, jeśli panel tak wymaga)
• Typ: TXT
• Wartość: v=spf1 … -all
• TTL: 3600 (lub wg polityki; krótszy na czas testów)

W niektórych panelach wartości TXT nie wymagają cudzysłowów; w innych są dodawane automatycznie. Jeśli panel wymaga cudzysłowów, wpisz dokładnie jedną parę.

Krok 4: Weryfikacja i testy

• Użyj dig/nslookup: dig TXT example.com lub narzędzi online, aby potwierdzić wartość.
• Wyślij mail do skrzynki Gmail/Outlook i zobacz oryginał nagłówków (Authentication-Results). Sprawdź spf=pass i szczegóły.
• Jeśli SPF nie przechodzi, porównaj IP nadawcy z mechanizmami. Sprawdź, czy dany system używa własnego envelope MAIL FROM (często subdomena dostawcy) — wtedy alignment DMARC może nie przejść, ale SPF pass nadal jest możliwy.

Najczęstsze problemy z SPF

• Przekroczony limit 10 lookupów — usuń zbędne include, zastąp mx/a statycznymi ip4/ip6, rozważ provider-specific flattening.
• Wysyłka z nowej usługi bez aktualizacji SPF — dodaj include lub IP.
• Konflikt wielu rekordów SPF — scal do jednego TXT.
• Nadmiernie szerokie a/mx — mogą otwierać furtkę dla niespodziewanych IP. Lepiej używać konkretnych ip4/ip6 lub include dostawcy.

Konfiguracja DKIM krok po kroku

Krok 1: Generowanie kluczy i dobór długości

DKIM wymaga pary kluczy: prywatnego (na serwerze nadawcy) i publicznego (w DNS). Zalecana długość to 2048 bit; 1024 bywa akceptowana, ale jest słabsza kryptograficznie i część odbiorców może ją deprecjonować. Jeśli Twój dostawca generuje klucze, pobierz wartość publiczną wraz z nazwą selektora.

Krok 2: Zrozumienie pojęcia selektora

Selektor (np. s1, s2025q1, google) pozwala mieć wiele aktywnych kluczy równolegle i rotować je bez przestojów. Publiczny rekord jest publikowany pod nazwą: selektor._domainkey.example.com. Przykład wartości TXT:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…

W polu Selector w narzędziach dostawcy ustaw krótką, czytelną nazwę; to Twój selector.

Krok 3: Publikacja i aktywacja

• Dodaj rekord TXT na nazwie: s1._domainkey (lub pełnej: s1._domainkey.example.com)
• Wartość: v=DKIM1; k=rsa; p=… (bez klucza prywatnego!)
• Włącz podpisywanie DKIM po stronie serwera/usługi. W GWS/M365 zwykle w sekcji Autoryzacja/Zaawansowane.

Po propagacji wyślij test i sprawdź w Authentication-Results nagłówek dkim=pass oraz d=example.com; s=s1.

Krok 4: Rotacja kluczy i praktyki bezpieczeństwa

• Utrzymuj co najmniej dwa selektory (np. s1 i s2). Nowe wysyłki podpisuj s2, a po kilku dniach usuń s1.
• Nie publikuj klucza prywatnego; zabezpiecz uprawnienia dostępu do MTA/ESP i paneli.
• W przypadku migracji ESP najpierw publikuj ich rekord publiczny, potwierdź podpisy, dopiero potem wyłącz stary system.

Typowe problemy z DKIM

• Za długi rekord TXT w panelu — część paneli wymaga automatycznego dzielenia na kilka cudzysłowów; inne robią to same. Nie dziel ręcznie, jeśli panel już dzieli.
• Zmiana białych znaków/CRLF przez bramki — rzadkie, ale możliwe; aktualizacje MTA zwykle rozwiązują te problemy.
• Niewłaściwy d= w podpisie (np. ESP podpisuje inną domeną) — sprawdź ustawienia custom domain w ESP, aby osiągnąć DMARC alignment.

Konfiguracja DMARC krok po kroku

Krok 1: Zacznij od p=none i włącz raporty

DMARC to TXT na nazwie _dmarc.example.com. Startowy rekord do monitoringu:

v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-afrf@example.com; fo=1; pct=100; aspf=r; adkim=r

• p=none — tylko obserwuj, nie egzekwuj
• rua — raporty zbiorcze (XML) z dostarczeń
• ruf — raporty forensics/failure (nie wszyscy wysyłają; kwestia prywatności)
• fo=1 — raportuj każde niepowodzenie
• pct=100 — procent wiadomości objętych polityką
• aspf/adkim — tryb dopasowania relaxed/strict

Stwórz dedykowane skrzynki na raporty lub użyj narzędzia zewnętrznego do parsowania. Raporty pomogą wykryć legalne źródła, które jeszcze nie przechodzą SPF/DKIM alignment.

Krok 2: Uporządkuj alignment SPF i DKIM

W raporcie DMARC sprawdź, które źródła mają dkim=pass aligned albo spf=pass aligned. Aby osiągnąć alignment:

• SPF: envelope MAIL FROM (domena w Return-Path) musi dopasować się do From: (relaxed/strict). U wielu ESP Return-Path to domena ESP (np. sendgrid.net), więc alignment SPF nie przejdzie. Wtedy skonfiguruj nadawanie z własną custom subdomeną (np. bounce.example.com) albo polegaj na DKIM alignment.
• DKIM: ustaw podpis d=example.com (lub subdomena dopasowana zgodnie z aspf/adkim). W wielu usługach trzeba włączyć opcję „custom DKIM domain”.

Krok 3: Stopniowe zaostrzanie polityki

Po 2–4 tygodniach monitoringu, gdy większość legalnej poczty spełnia alignment, podnieś politykę:

v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com; fo=1; pct=50; aspf=s; adkim=s

quarantine oznacza zalecenie, by wiadomości niespełniające wymagań trafiły do folderu spam. Po kolejnych 2–4 tygodniach i analizie raportów możesz przejść do:

v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com; fo=1; pct=100; aspf=s; adkim=s

Parametry sp= pozwalają ustawić osobną politykę dla subdomen (np. sp=quarantine). Pamiętaj: część odbiorców może interpretować polityki nieco odmiennie, ale p=quarantine i p=reject są szeroko respektowane.

Krok 4: Opcje zaawansowane DMARC

• pct= — pozwala wdrażać politykę częściowo (np. 25%, 50%), co ułatwia stopniowe zaostrzanie.
• fo=0/1/d/s — steruje warunkami raportowania; fo=1 zwykle daje pełniejszy obraz, ale więcej danych do analizy.
• ri= — interwał raportów zbiorczych (sekundy; nie zawsze respektowany).
• sp= — polityka subdomen (np. sp=reject, gdy główna domena jest p=quarantine).

Przykładowe gotowe rekordy DMARC

• Monitoring i uczenie się:

  v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; aspf=r; adkim=r

• Egzekwowanie do spamu:

  v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com; pct=100; aspf=s; adkim=s

• Pełne odrzucanie:

  v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com; pct=100; aspf=s; adkim=s

Przykłady konfiguracji w popularnych scenariuszach

Google Workspace

• SPF: v=spf1 include:_spf.google.com -all (rozszerz o inne źródła, jeśli są)
• DKIM: w panelu administratora wygeneruj klucz 2048-bit, np. google jako selektor; opublikuj TXT google._domainkey
• DMARC: _dmarc.example.com z p=none i raportami; po testach zaostrzenie do quarantine/reject

Microsoft 365

• SPF: v=spf1 include:spf.protection.outlook.com -all (rozszerz o dodatkowe usługi)
• DKIM: włącz DKIM dla domeny niestandardowej; opublikuj dwa rekordy CNAME lub TXT wg instrukcji M365 dla selektorów selector1 i selector2
• DMARC: jak wyżej — p=none → quarantine → reject po analizie

ESP/CDP/CRM (SendGrid, Mailgun, Amazon SES, itp.)

• Skonfiguruj własną domenę nadawczą: custom Return-Path (np. b.example.com) i custom DKIM d=example.com.
• Opublikuj rekordy DKIM sugerowane przez dostawcę oraz CNAME dla trackingu, jeśli używasz linków śledzących (dla spójności domeny).
• Jeśli nie możesz ustawić custom Return-Path, dmuchaj na zimne — postaw na alignment DKIM i testuj DMARC.

Własny serwer (Postfix/Exim)

• SPF: dodaj ip4/ip6 serwera do rekordu SPF; rozważ include, jeśli łączysz z ESP.
• DKIM: zainstaluj opendkim/opendmarc; wygeneruj klucz 2048-bit; podpisuj domeną From.
• DMARC: opublikuj p=none, analizuj raporty, dopiero potem zaostrzaj.

Subdomeny i separacja strumieni

Jeśli różne działy lub systemy wysyłają z różnych subdomen (np. transakcje: tx.example.com, marketing: m.example.com), skonfiguruj osobne DKIM/DMARC dla każdej subdomeny. W DMARC możesz użyć sp= dla dziedziczenia lub publikować niezależne rekordy w _dmarc.m.example.com i _dmarc.tx.example.com. Pozwala to precyzyjniej kontrolować ruch i łatwiej diagnozować problemy.

Forwarding, listy mailingowe i ARC

Przekazywanie (forwarding) często psuje SPF, bo envelope MAIL FROM nie zmienia się, a IP nadawcy staje się IP serwera pośredniczącego. DKIM częściej przetrwa, o ile wiadomość nie zostanie zmodyfikowana. Listy mailingowe potrafią modyfikować nagłówki/treść i zrywać DKIM. Standard ARC (Authenticated Received Chain) pomaga odbiorcom oceniać tak przetworzone wiadomości, ale nie zastępuje DMARC i nie jest wszędzie wdrożony. Planując p=reject, sprawdź, czy kluczowe ścieżki pocztowe nie opierają się ciężko na forwardingu.

Testy, monitoring i rozwiązywanie problemów

Narzędzia diagnostyczne

• dig/nslookup: weryfikacja rekordów TXT (SPF, DKIM, DMARC).
• Testowe skrzynki u dużych dostawców (Gmail, Outlook.com): sprawdź Authentication-Results (spf=pass, dkim=pass, dmarc=pass).
• Analizatory raportów DMARC: konsolidują raporty rua i pokazują źródła niezgodne z alignment.
• Mail-tester podobne narzędzia: szybka ocena sygnałów antyspamowych, reputacji i konfiguracji.

Checklist wdrożenia

• SPF: jeden rekord TXT, nieprzekroczony limit lookupów, -all na produkcji (po testach).
• DKIM: aktywny podpis 2048-bit, poprawny rekord publiczny, rotacja co 3–12 miesięcy.
• DMARC: raporty rua działają; p=none na start; stopniowe przejście do quarantine i finalnie p=reject po upewnieniu się, że wszystkie legalne źródła mają alignment.
• Monitoring: archiwizuj raporty, buduj listę legalnych źródeł i aktualizuj konfigurację przy każdej nowej integracji.

Najczęstsze symptomy i ich przyczyny

• Wiadomości trafiają do spamu mimo SPF/DKIM pass — sprawdź reputację IP/domeny, treść, linki, bounces, skargi, historeę wysyłek; DMARC nie naprawi reputacji.
• SPF fail tylko u niektórych odbiorców — możliwa propagacja DNS, różnice w resolverach, albo przekroczony limit lookupów.
• DKIM fail okazjonalnie — problem z formatowaniem linii, modyfikacją wiadomości po drodze (stopki, bramki antywirusowe), niewłaściwy canonicalization.
• DMARC fail mimo SPF/DKIM pass — brak alignment (np. DKIM d=inna-domena lub Return-Path innej domeny).

Polityka rotacji i higiena konfiguracji

• Co kwartał przeglądaj raporty DMARC i listę źródeł. Usuwaj nieużywane include i rekordy.
• Rotuj klucze DKIM; utrzymuj co najmniej dwa aktywne selektory podczas przełączeń.
• W dokumentacji wewnętrznej trzymaj listę: kto i skąd wysyła maile w domenie; bez tego łatwo o niezamierzone blokady.

Wskazówki dla kilku dostawców jednocześnie

• SPF: scal include w jeden rekord; pilnuj limitu lookupów. Jeśli to problem, użyj mechanizmów flatteningu oferowanych przez niektóre ESP lub wstaw konkretne ip4/ip6.
• DKIM: każdy dostawca powinien podpisywać Twoją domeną (d=example.com) z własnym selektorem (np. sg2025, mg2025). To upraszcza alignment.
• DMARC: p=none na start w czasie migracji; podnoszenie polityki dopiero, gdy wszystkie strumienie przechodzą alignment.

BIMI i korzyści wizerunkowe

Po poprawnym SPF, DKIM, DMARC (z p=quarantine lub p=reject) możesz myśleć o BIMI, aby wyświetlać logo przy wiadomościach. Wymaga to dodatkowych rekordów i często certyfikatu VMC, ale wzmacnia zaufanie i może poprawić deliverability poprzez lepsze wskaźniki zaangażowania.

Przykładowe pełne zestawy rekordów

• SPF (domena główna):

  example.com TXT v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ip4:203.0.113.10 -all

• DKIM (Google Workspace, selektor google):

  google._domainkey.example.com TXT v=DKIM1; k=rsa; p=MIIBIjANBgkq…

• DKIM (SendGrid, selektor sg2025):

  sg2025._domainkey.example.com TXT v=DKIM1; k=rsa; p=MIIBIjANBgkq…

• DMARC (polityka surowa po testach):

  _dmarc.example.com TXT v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-afrf@example.com; fo=1; aspf=s; adkim=s; pct=100

Uwaga na narzędzia automatyzujące

Narzędzia „naprawiające SPF/DKIM/DMARC jednym kliknięciem” bywają pomocne, ale nie znają Twojej pełnej infrastruktury. Zawsze czytaj uważnie proponowane zmiany i testuj na p=none, zanim przejdziesz do egzekwowania. Po każdej zmianie integracji (nowy CRM, bramka, serwer) wykonuj szybki audyt i test wysyłki, by uniknąć niezamierzonego odrzucenia ważnych wiadomości.