Pamiętam, jak kilka lat temu klient zadzwonił w panice: “Gmail odrzuca wszystkie nasze maile!”. Okazało się, że ich domena nie miała żadnej autentykacji — ani SPF, ani DKIM, ani DMARC. W 2020 roku jakoś się z tym żyło. W 2026? To wyrok śmierci dla deliverability.

Gmail i Yahoo powiedzieli wprost: nie ma autentykacji, nie ma dostarczenia. Koniec dyskusji.

Jeśli słowa SPF, DKIM i DMARC brzmią dla Ciebie jak zaklęcia — spokojnie. Za chwilę wszystko wyjaśnię.

Co te wszystkie skróty właściwie oznaczają?

Wyobraź sobie, że wysyłasz list tradycyjną pocztą. SPF to lista osób upoważnionych do wysyłania listów w Twoim imieniu. DKIM to Twój podpis — dowód, że to naprawdę Ty napisałeś ten list. A DMARC? To instrukcja dla poczty: “Jeśli list nie ma mojego podpisu albo wysłał go ktoś nieautoryzowany, wyrzuć go do kosza”.

Razem tworzą system, który mówi światu: “Tak, ten email naprawdę pochodzi ode mnie”.

SPF — kto może wysyłać maile z Twojej domeny

SPF to najprostszy z trzech protokołów. To zwykły rekord DNS (typu TXT), który wymienia wszystkie serwery uprawnione do wysyłania maili z Twojej domeny.

Jak to wygląda w praktyce

Załóżmy, że używasz MailingAPI do wysyłania maili transakcyjnych i Google Workspace do firmowej poczty. Twój rekord SPF będzie wyglądał tak:

example.com. TXT "v=spf1 include:spf.mailingapi.com include:_spf.google.com ~all"

Co to znaczy?

  • v=spf1 — wersja protokołu (zawsze taka sama)
  • include:spf.mailingapi.com — serwery MailingAPI są OK
  • include:_spf.google.com — serwery Google są OK
  • ~all — wszystko inne traktuj podejrzliwie

Pułapka, w którą wpada połowa ludzi

SPF ma limit 10 “lookupów” DNS. Każdy include: to jeden lookup. Brzmi jak dużo? Nie, gdy używasz kilku usług zewnętrznych, a każda z nich ma własne includy wewnątrz…

Kiedyś pomagałem firmie, która miała 14 lookupów w SPF. Gmail po prostu ignorował cały rekord. Rozwiązanie? Musieliśmy skonsolidować usługi i użyć SPF flattening.

Jak sprawdzić swój SPF

dig example.com TXT | grep spf

Albo prościej — wejdź na MXToolbox SPF Check i wpisz swoją domenę.

DKIM — cyfrowy podpis każdego maila

DKIM jest trochę bardziej skomplikowany, ale idea jest prosta: każdy wysyłany mail dostaje cyfrowy podpis. Serwer odbiorcy sprawdza ten podpis używając klucza publicznego w Twoim DNS.

Jeśli ktoś zmieni treść maila po drodze — podpis się nie zgadza. Gmail wie, że coś jest nie tak.

Konfiguracja DKIM

Tu są dwie opcje:

Opcja A — robisz wszystko sam (trudna droga):

# Generujesz klucze
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# Dodajesz klucz publiczny do DNS
mailingapi._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

# Konfigurujesz serwer do podpisywania...
# I modlisz się, że nic nie pomyliłeś

Opcja B — używasz MailingAPI (prosta droga):

mailingapi._domainkey.example.com. CNAME dkim.mailingapi.com.

Jeden rekord CNAME i gotowe. My generujemy klucze, rotujemy je regularnie, podpisujemy maile — wszystko automatycznie.

Jak sprawdzić, czy DKIM działa

Wyślij testowego maila do siebie i sprawdź nagłówki. Szukasz czegoś takiego:

Authentication-Results: ... dkim=pass

dkim=pass — świetnie. dkim=fail — masz problem.

DMARC — polityka i raporty

DMARC to taki nadzorca nad SPF i DKIM. Mówi serwerom pocztowym: “Jeśli mail nie przechodzi SPF i DKIM, zrób z nim to”. Dodatkowo generuje raporty, dzięki którym wiesz, kto próbuje wysyłać maile jako Ty.

Wdrażanie DMARC — nie rób tego na raz!

Widziałem firmy, które ustawiły p=reject pierwszego dnia i zablokowały połowę swoich własnych maili. Nie rób tego.

Tydzień 1-2: Zacznij od monitorowania

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@twojadomena.com"

p=none znaczy “nic nie rób, tylko raportuj”. Przez dwa tygodnie zbieraj dane i sprawdzaj, czy wszystkie Twoje legalne źródła maili przechodzą autentykację.

Tydzień 3-4: Powoli zaostrzaj politykę

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@twojadomena.com"

p=quarantine znaczy “wrzuć do spamu”. pct=10 znaczy “ale tylko 10% wiadomości”. Stopniowo zwiększaj procent.

Po miesiącu+: Pełna ochrona

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@twojadomena.com"

Teraz nieautoryzowane maile są odrzucane. Twoja domena jest chroniona.

Najczęstsze problemy (i jak je naprawić)

“Too many DNS lookups”

SPF ma limit 10 lookupów i przekraczasz go. Rozwiązania:

  • Usuń nieużywane includy
  • Użyj SPF flattening (zamienia includy na bezpośrednie adresy IP)
  • Skonsoliduj usługi

“DKIM signature not verified”

Klucz publiczny w DNS nie pasuje do podpisu. Sprawdź:

  1. Czy rekord DNS się już rozpropagował (może trwać do 48h)
  2. Czy selector w podpisie zgadza się z tym w DNS
  3. Czy nie ma literówek w rekordzie

Maile wciąż lądują w spamie mimo autentykacji

Autentykacja to podstawa, ale nie wszystko. Sprawdź również:

  • Reputację domeny i IP
  • Treść wiadomości
  • Bounce rate i skargi na spam

Narzędzia, których używam codziennie

Narzędzie Co sprawdza
MXToolbox SPF, DKIM, DMARC, blacklisty — wszystko w jednym miejscu
mail-tester.com Kompleksowy test wiadomości (score 1-10)
DMARC Analyzer Czytelne raporty DMARC zamiast surowego XML

Na koniec

Konfiguracja SPF, DKIM i DMARC to nie rakietowa nauka, ale wymaga uwagi. Jeden błąd w rekordzie DNS i Twoje maile przestają dochodzić.

Jeśli nie chcesz się z tym bawić — MailingAPI załatwia to za Ciebie. Jeden rekord CNAME i masz pełną autentykację bez martwienia się o klucze, rotacje i limity lookupów.

A jeśli wolisz robić to sam — masz teraz wszystko, czego potrzebujesz. Powodzenia.