SPF, DKIM i DMARC – jak zabezpieczyć wysyłkę e-maili z własnej domeny

Dlaczego maile z Twojej aplikacji mogą trafiać do spamu?

Protokół poczty e-mail powstał w czasach, gdy nikt nie sprawdzał, kto naprawdę wysyła wiadomość. Pole „Od” można wpisać dowolnie, więc przez lata każdy mógł wysłać maila „od” kontakt@twojadomena.pl. Nikt nie musiał mieć do tego Twojej zgody.

Dlatego dziś serwery odbiorców (Gmail, Outlook i inne) zadają przy każdej wiadomości trzy pytania:

1. Czy ten serwer ma prawo wysyłać pocztę w imieniu tej domeny? Odpowiada na to SPF.
2. Czy wiadomość na pewno pochodzi od właściciela domeny i nikt jej po drodze nie zmienił? Odpowiada na to DKIM.
3. Co zrobić, jeśli odpowiedzi na powyższe pytania są złe? Odpowiada na to DMARC.

Jeśli wysyłasz maile z formularza kontaktowego, powiadomienia o rejestracji albo link do logowania, każdy z nich przechodzi ten test. Bez poprawnie skonfigurowanej domeny wiadomość wygląda dla odbiorcy tak samo, jak próba podszycia się pod Ciebie. Jak podłączyć wysyłkę do formularza, opisujemy w artykule o wysyłaniu maila przez formularz z e-mail API Resend.

Czym są SPF, DKIM i DMARC? Różnice w skrócie

Te trzy mechanizmy działają razem. SPF i DKIM to dwa niezależne sposoby udowodnienia tożsamości nadawcy, a DMARC to polityka, która z nich korzysta i wysyła Ci raporty.

Jak działa SPF i jak wygląda rekord?

SPF (Sender Policy Framework) to jedna linia tekstu w DNS, która wymienia, kto może wysyłać pocztę z Twojej domeny. Serwer odbiorcy sprawdza, czy adres IP serwera, który wysłał wiadomość, jest na tej liście.

Przykładowy rekord (wartości są poglądowe, prawdziwe wygeneruje Twój dostawca):

# typ TXT, nazwa: twojadomena.pl
v=spf1 include:_spf.google.com include:spf.dostawca-api.example ~all

Jak czytać ten rekord:

• v=spf1 oznacza wersję protokołu,
• każde include: dopuszcza serwery danej usługi (tu Google Workspace i dostawcę e-mail API),
• ~all na końcu to instrukcja dla wszystkich pozostałych: potraktuj je podejrzliwie (tzw. softfail). Ostrzejsza wersja to -all, czyli odrzuć.

Dwie zasady z RFC 7208 powodują najwięcej problemów:

• Domena może mieć tylko jeden rekord SPF. Jeśli dodasz drugi (np. po podłączeniu nowej usługi), wynikiem jest błąd permerror, a SPF przestaje działać. Nowe include: dopisujesz do istniejącego rekordu.
• Rekord może wymagać najwyżej 10 zapytań DNS. Liczą się mechanizmy include, a, mx, ptr, exists i modyfikator redirect. Po przekroczeniu limitu wynikiem jest znów permerror. Przy kilku usługach (poczta, newsletter, CRM, system faktur) łatwo dobić do 10, bo każdy include może sam zawierać kolejne.

Jak działa DKIM i skąd bierze się podpis?

DKIM (DomainKeys Identified Mail) działa jak pieczęć. Serwer wysyłający podpisuje wiadomość kluczem prywatnym, którego nie zna nikt poza nim. Klucz publiczny leży w Twoim DNS. Serwer odbiorcy pobiera go i sprawdza, czy podpis pasuje do treści i nagłówków. Jeśli ktoś zmienił wiadomość po drodze albo podszywa się pod domenę, podpis się nie zgodzi.

Rekord DKIM wygląda tak, że jego nazwa zawiera selektor, czyli etykietę klucza:

# nazwa: selector1._domainkey.twojadomena.pl   typ: TXT (albo CNAME)
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Selektor wybiera dostawca (u każdego jest inny), dlatego rekordu nie wymyślasz sam. Dostawca e-mail API podaje go w panelu. W przypadku Resend dokumentacja każe skopiować rekordy z zakładki Records dokładnie tak, jak zostały wygenerowane.

Kilka faktów, które warto znać:

• Google wymaga kluczy DKIM o długości co najmniej 1024 bity i zaleca 2048 bitów, tam, gdzie to możliwe.
• Możesz mieć kilku nadawców podpisujących wiadomości jednej domeny, bo każdy ma własny selektor i własny rekord.
• Jeśli panel dostawcy daje rekordy typu CNAME, nie włączaj dla nich proxy. W Cloudflare oznacza to szarą chmurkę zamiast pomarańczowej. Resend ostrzega, że proxy uniemożliwia weryfikację.

Jak działa DMARC i dlaczego zaczynamy od p=none?

DMARC (Domain-based Message Authentication, Reporting and Conformance) spina SPF i DKIM w jedną politykę. Mówi serwerom odbiorców, co zrobić z wiadomością, która nie przeszła uwierzytelnienia, i prosi je o raporty.

Rekord TXT pod nazwą _dmarc.twojadomena.pl:

v=DMARC1; p=none; rua=mailto:dmarc@twojadomena.pl;

Trzy polityki:

• p=none: nic nie blokuje, tylko zbiera raporty. To punkt startowy.
• p=quarantine: wiadomości, które nie przeszły, trafiają do spamu.
• p=reject: serwer odbiorcy odrzuca takie wiadomości.

Bezpieczne wdrożenie według zaleceń Resend wygląda tak:

1. Dodaj rekord z p=none i adresem rua.
2. Wyślij maile ze wszystkich aplikacji i usług używających Twojej domeny i sprawdź w nagłówkach dmarc=pass. Zajmie to kilka dni, bo część poczty wychodzi rzadko.
3. Gdy cała prawdziwa poczta przechodzi, zmień politykę na quarantine.
4. Gdy nadal wszystko jest w porządku, możesz przejść na reject.

Jest tu jeden szczegół, który często myli: DMARC wymaga, żeby przeszedł SPF albo DKIM, nie oba naraz. Wiadomość nie przechodzi DMARC dopiero wtedy, gdy oba zawiodą. Do tego domena, która przeszła SPF lub DKIM, musi się zgadzać z domeną w polu Od. To tzw. zgodność (alignment), i dlatego zdarza się, że SPF i DKIM pokazują „pass”, a DMARC mimo to „fail”: sprawdzony został inny adres niż ten widoczny dla odbiorcy.

Jak wygląda konfiguracja domeny przy e-mail API (na przykładzie Resend)?

Dostawcy takie jak Resend upraszczają większość pracy: po dodaniu domeny w panelu dostajesz listę rekordów SPF i DKIM, które wklejasz w DNS u swojego rejestratora. Dokumentacja Resend podkreśla kilka rzeczy:

• Wysyłaj z subdomeny, np. powiadomienia.twojadomena.pl, a nie z domeny głównej. Dzięki temu reputacja wysyłki z aplikacji nie miesza się z główną pocztą firmy.
• Rekordy muszą pasować dokładnie do tych wygenerowanych w panelu.
• Adres Return-Path (na który wracają błędy dostarczenia) domyślnie leży w subdomenie send Twojej domeny. Możesz ustawić własny.
• Weryfikacja zwykle kończy się w ciągu ok. 15 minut, ale propagacja DNS bywa wolniejsza i może zająć do 72 godzin. Po tym czasie użyj przycisku „Restart verification”. Stan rekordów możesz sprawdzić w narzędziu dns.email.
• DMARC dodajesz po weryfikacji domeny. To osobny rekord, który tworzysz sam.

Cały przepływ wygląda więc tak: dodajesz domenę, kopiujesz rekordy do DNS, czekasz na status „Verified”, a potem dopisujesz rekord DMARC z p=none.

Jak sprawdzić, czy SPF, DKIM i DMARC działają?

Status „Verified” w panelu dostawcy to za mało. Sprawdź to samodzielnie na dwa sposoby.

1. Komendą dig w terminalu (rekordy widoczne publicznie):

# rekord SPF (szukaj linii zaczynającej się od v=spf1)
dig TXT twojadomena.pl +short

# rekord DMARC
dig TXT _dmarc.twojadomena.pl +short

# rekord DKIM (selektor podaje dostawca)
dig TXT selector1._domainkey.twojadomena.pl +short

Jeśli odpowiedź jest pusta, rekord nie jest jeszcze widoczny w DNS (albo wpisałeś złą nazwę).

2. Nagłówkami prawdziwej wiadomości. Wyślij maila z aplikacji na swoje konto Gmail, otwórz wiadomość i wybierz „Pokaż oryginał”. Na górze zobaczysz wyniki trzech sprawdzeń. Szukasz trzech razy PASS: SPF, DKIM i DMARC. To jedyny dowód, że poczta rzeczywiście przechodzi test. Taki sam krok zaleca dokumentacja Resend przy wdrażaniu DMARC (dmarc=pass w nagłówkach).

Co oznacza PASS i inne wyniki?

Każde z trzech sprawdzeń kończy się jednym słowem. PASS znaczy „test zdany”: serwer odbiorcy sprawdził rekord w DNS i wszystko się zgadza. W pełnej wersji nagłówków zobaczysz to jako spf=pass, dkim=pass i dmarc=pass.

Jeśli gdzieś widzisz coś innego niż PASS, wróć do tabeli błędów na końcu artykułu. Najczęściej wystarczy poprawić jeden rekord.

Czego wymaga Gmail od nadawców?

Od 1 lutego 2024 roku Gmail stosuje zaostrzone zasady dla nadawców. Według dokumentacji Google (stan na 19 października 2026) wymagania zależą od skali wysyłki:

Dla formularza kontaktowego i powiadomień z aplikacji liczy się przede wszystkim pierwsza kolumna, bo jest to poczta transakcyjna, a nie masowa wysyłka marketingowa. Warto jednak mieć wszystkie trzy mechanizmy od początku: kosztuje to kilkanaście minut, a oszczędza problemów, gdy aplikacja urośnie. Do monitorowania odsetka zgłoszeń spamu Gmail udostępnia narzędzie Postmaster Tools.

Jakie błędy w konfiguracji zdarzają się najczęściej?

Uwaga mentora: Po każdej zmianie w DNS wyślij testową wiadomość z aplikacji na swoje konto Gmail, wybierz „Pokaż oryginał” i znajdź trzy wyniki: SPF, DKIM i DMARC. Trzy razy PASS to jedyny pewny dowód, że poczta przechodzi test. Status „Verified” w panelu dostawcy to za mało, bo mówi tylko, że rekordy istnieją, a nie że prawdziwa wiadomość je przeszła.

Najczęstsze pytania

Czy muszę mieć SPF, DKIM i DMARC, żeby wysyłać maile z aplikacji?

W praktyce tak. Dostawca e-mail API nie pozwoli wysyłać z własnej domeny bez weryfikacji (SPF i DKIM), a Gmail wymaga co najmniej SPF lub DKIM od wszystkich nadawców. DMARC jest obowiązkowy dla nadawców masowych, ale dodanie go z p=none jest proste i daje raporty.

Czym różni się SPF od DKIM?

SPF sprawdza skąd wysłano wiadomość (czy serwer jest na liście dozwolonych), a DKIM sprawdza co wysłano (czy podpis cyfrowy zgadza się z treścią i domeną). Zabezpieczają przed różnymi atakami i dlatego używa się ich razem.

Co oznacza p=none w DMARC?

Że DMARC działa tylko w trybie monitorowania: niczego nie blokuje, ale wysyła Ci raporty o tym, kto wysyła pocztę w imieniu Twojej domeny i czy przechodzi test. To bezpieczny punkt startowy.

Ile trwa propagacja rekordów DNS?

Resend podaje, że domena często weryfikuje się w ciągu ok. 15 minut, a propagacja DNS potrafi zająć do 72 godzin. Jeśli po tym czasie nie działa, uruchom weryfikację ponownie i sprawdź rekordy komendą dig.

Czy mogę mieć kilka rekordów SPF?

Nie. Jedna domena powinna mieć tylko jeden rekord SPF. Drugi powoduje błąd permerror i SPF przestaje działać. Wszystkie usługi dopisujesz do jednego rekordu jako kolejne include:.

Czy zaostrzyć DMARC do p=reject?

Dopiero gdy raporty rua pokażą, że cała prawdziwa poczta z Twojej domeny przechodzi uwierzytelnienie. Wcześniejsze przejście na reject grozi tym, że odrzucone zostaną też Twoje własne, prawidłowe wiadomości.