SPF, DKIM i DMARC. Jak zabezpieczyć pocztę w domenie firmy

Od 1 lutego 2024 roku Gmail wymaga, żeby każda domena wysyłająca pocztę na prywatne konta Gmail miała co najmniej rekord SPF albo DKIM. Od listopada 2025 roku Google zaostrzył egzekwowanie i wiadomości, które tych wymagań nie spełniają, mogą zostać odrzucone. Yahoo wprowadziło podobne zasady również od lutego 2024 roku.

Jeśli masz firmową domenę i wysyłasz z niej faktury, oferty albo potwierdzenia zamówień, trzy rekordy w DNS w dużej mierze decydują o tym, czy Twoje maile trafią do skrzynki klienta i czy ktoś obcy może wysyłać wiadomości „od Ciebie”. Poniżej masz SPF, DKIM i DMARC w kolejności wdrażania, ze wzorami rekordów, w które wstawisz dane od swojego dostawcy. Wszystkie zasady sprawdziłem w dokumentach źródłowych: RFC 7208 (SPF), RFC 6376 i RFC 8301 (DKIM) oraz RFC 9989 (DMARC, standard z maja 2026 roku, który zastąpił RFC 7489), a także w wytycznych Google i Yahoo dla nadawców.

Czym są SPF, DKIM i DMARC i jak działają razem?

SPF, DKIM i DMARC to trzy rekordy TXT w DNS, które razem dają odbiorcy pewność, że wiadomość z Twoim adresem naprawdę wyszła od Ciebie. Każdy z nich sprawdza coś innego.

• SPF (Sender Policy Framework): lista serwerów, które mają prawo wysyłać pocztę z Twojej domeny. Serwer odbiorcy porównuje adres IP nadawcy z tą listą. SPF sprawdza adres z „koperty” wiadomości (pole MAIL FROM, widoczne w nagłówkach jako Return-Path). Adresu w polu „Od”, który Twój kontrahent widzi w programie pocztowym, SPF nie sprawdza (RFC 7208, sekcje 2.4 i 2.5).
• DKIM (DomainKeys Identified Mail): podpis dodawany do każdej wysłanej wiadomości w nagłówku DKIM-Signature. Odbiorca pobiera z DNS Twój klucz publiczny i sprawdza, czy podpis pasuje, czyli czy nikt nie zmienił wiadomości po drodze. Działa jak pieczęć lakowa na liście: każdy może go przeczytać, ale złamaną albo podrobioną pieczęć widać od razu. DKIM nie szyfruje treści (RFC 6376, sekcja 1).
• DMARC (Domain-based Message Authentication, Reporting and Conformance): reguła, którą publikujesz dla domeny z pola „Od”. Mówi odbiorcy, co zrobić z wiadomością, która nie przeszła kontroli, i gdzie wysyłać raporty.

Wiadomość przechodzi DMARC, gdy co najmniej jeden z mechanizmów (SPF albo DKIM) da wynik pozytywny i jego domena jest zgodna z domeną w polu „Od” (RFC 9989, sekcja 5.3.5). Ta zgodność to tak zwane wyrównanie (alignment). Oba naraz nie muszą przejść. Ustaw jednak SPF i DKIM, bo SPF zawodzi, gdy wiadomość jest automatycznie przekazywana dalej na inny adres.

Czy wymagania Gmaila i Yahoo dotyczą małej firmy?

Tak, w podstawowym zakresie. Google dzieli nadawców na dwie grupy (wytyczne Google dla nadawców, support.google.com/mail/answer/81126):

• Wszyscy nadawcy: SPF albo DKIM, poprawny rekord PTR serwera, szyfrowane połączenie TLS i odsetek zgłoszeń spamu poniżej 0,3% w Postmaster Tools. PTR i TLS zwykle zapewnia dostawca poczty.
• Ponad 5000 wiadomości dziennie do kont Gmail: SPF i DKIM jednocześnie, rekord DMARC (wystarczy polityka p=none), domena w polu „Od” zgodna z domeną SPF albo DKIM oraz rezygnacja z subskrypcji jednym kliknięciem w wiadomościach marketingowych.

Google liczy ten próg dla całej domeny głównej, razem z subdomenami, a status nadawcy masowego przyznaje na stałe, nawet po jednym takim dniu. Yahoo wymaga od wszystkich SPF albo DKIM i spamu poniżej 0,3%, a od nadawców masowych SPF, DKIM i DMARC z polityką co najmniej p=none, ale nie podaje liczbowego progu.

Firma, która wysyła kilkadziesiąt maili dziennie, mieści się w pierwszej grupie. Sam SPF formalnie wystarczy, ale bez DMARC odbiorca nie dostaje od Ciebie żadnej reguły, co zrobić z fałszywą fakturą wysłaną klientom z Twoim adresem w polu „Od”. Dlatego ustaw wszystkie trzy rekordy.

Kto wysyła maile z Twojej domeny? Spis przed zmianą

Zwykle więcej usług niż sama skrzynka pocztowa, a zapomniany nadawca to częsty błąd przy wdrażaniu. Ustawiasz SPF dla skrzynki pocztowej, a po tygodniu okazuje się, że faktury z programu księgowego lądują w spamie. Zanim dotkniesz DNS, spisz wszystko, co wysyła wiadomości z adresem w Twojej domenie:

• Skrzynki pocztowe: serwer poczty u dostawcy hostingu albo usługa pocztowa w chmurze.
• Sklep internetowy: potwierdzenia zamówień i zmiany statusu.
• Program do faktur: wysyłka faktur „z Twojego adresu”.
• Newsletter: system do mailingu.
• Formularz na stronie i CRM: powiadomienia i automatyczne odpowiedzi.

Dla każdej pozycji znajdź w pomocy dostawcy dwie rzeczy: wpis include do rekordu SPF i instrukcję włączenia DKIM. Dostawca, który wysyła pocztę w Twoim imieniu, zwykle podaje je w dokumentacji.

Jak ustawić rekord SPF?

Rekord SPF to rekord TXT na samej domenie. W panelu DNS u operatora strefy w polu nazwy hosta wpisz @ albo zostaw je puste. Zasady z RFC 7208, które najczęściej się łamie:

• Tylko jeden rekord SPF na domenę. Dwa rekordy zaczynające się od v=spf1 dają błąd permerror i SPF przestaje działać w całości (sekcje 3.2 i 4.5). Kolejnego dostawcę dopisujesz do istniejącego rekordu jako następny include.
• Limit 10 zapytań DNS. Do limitu wliczają się include, a, mx, ptr, exists i redirect, także te zagnieżdżone w rekordach dostawców. Adresy ip4 i ip6 oraz all się nie liczą. Po przekroczeniu limitu wynik to znowu permerror (sekcja 4.6.4).
• all zawsze na końcu. Wszystko, co stoi za nim, jest ignorowane (sekcja 5.1).

Przykład dla domeny firma-przyklad.pl z jednym dostawcą poczty:

firma-przyklad.pl.  3600  IN  TXT  "v=spf1 include:_spf.dostawca-poczty.example ~all"

Przy dwóch nadawcach, na przykład skrzynce i programie do faktur, oba wpisy include stoją w tym samym rekordzie:

firma-przyklad.pl.  3600  IN  TXT  "v=spf1 include:_spf.dostawca-poczty.example include:_spf.program-faktur.example ~all"

Końcówka ~all (softfail) oznacza, że inne serwery są „prawdopodobnie nieuprawnione”, a -all (fail) to jednoznaczne „nieuprawnione”. O tym, co zrobić z wiadomością, decyduje serwer odbiorcy. Przy ~all RFC zaleca, żeby nie odrzucał jej wyłącznie na tej podstawie (RFC 7208, sekcja 8.5). Na start bezpieczniej użyć ~all, a o odrzucaniu podróbek zdecyduje DMARC. Nie ustawiaj +all, bo przepuszcza każdy serwer.

Zanim zapiszesz zmianę, skopiuj stary rekord do notatek. Jeśli coś przestanie działać, wrócisz do niego bez zgadywania, co tam było. Jak edytować rekordy w panelu i co znaczy TTL, opisałem w poradniku o konfiguracji DNS.

Jak włączyć DKIM?

DKIM włączasz u dostawcy, który wysyła pocztę. W jego panelu generujesz klucz, a on podaje Ci nazwę i treść rekordu do wpisania w DNS. Nazwa ma zawsze postać selektor._domainkey.domena, gdzie selektor to krótki identyfikator klucza (RFC 6376, sekcja 3.6.2.1). Dla firma-przyklad.pl i selektora s2026 rekord wygląda tak:

s2026._domainkey.firma-przyklad.pl.  3600  IN  TXT  "v=DKIM1; k=rsa; p=<klucz_publiczny_od_dostawcy>"

Selektory pozwalają mieć kilka kluczy naraz, więc skrzynka, sklep i newsletter mogą podpisywać pocztę każdy swoim kluczem bez konfliktu. Długość klucza: minimum 1024 bity, zalecane 2048 (RFC 8301, sekcja 3.2; to samo minimum podaje Google). Jeśli panel daje wybór, wybierz 2048. Po dodaniu rekordu wróć do panelu dostawcy i włącz podpisywanie, bo samo opublikowanie klucza niczego nie podpisuje.

Jak wdrożyć DMARC bez ryzyka dla własnej poczty?

DMARC wdrażasz etapami: zaczynasz od samej obserwacji i zaostrzasz politykę stopniowo. Google zaleca, żeby rekord dodać co najmniej 48 godzin po ustawieniu SPF i DKIM. Rekord DMARC to TXT pod nazwą _dmarc przed domeną, w przykładzie _dmarc.firma-przyklad.pl:

_dmarc.firma-przyklad.pl.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@firma-przyklad.pl"

Tag v=DMARC1 musi stać na pierwszym miejscu, inaczej odbiorca zignoruje cały rekord. Zanim opublikujesz rekord, załóż skrzynkę dla adresu z rua. Plan wdrożenia:

1. Tydzień z p=none. Nic się nie zmienia w doręczaniu, ale zaczynasz dostawać raporty zbiorcze na adres z rua. Bez tagu rua odbiorcy raportów nie wysyłają.
2. Czytanie raportów. Raporty przychodzą jako pliki XML, zwykle spakowane, i wygodniej czytać je w analizatorze raportów DMARC niż ręcznie. Pokazują, z jakich adresów IP wyszły wiadomości z Twoją domeną i czy przeszły SPF oraz DKIM. Źródło z wynikiem negatywnym to najczęściej zapomniany nadawca ze spisu, przekazywanie poczty dalej albo ktoś, kto się pod Ciebie podszywa.
3. p=quarantine. Gdy wszystkie usługi ze spisu przechodzą SPF albo DKIM z wyrównaniem, a wyniki negatywne zostają tylko przy obcych źródłach, przełącz politykę na kwarantannę: odbiorcy będą traktować podróbki jako podejrzane, zwykle przenosząc je do spamu.
4. p=reject. Na końcu polityka odrzucania: wiadomości, które nie przejdą DMARC, nie zostaną doręczone.

Domyślnie DMARC stosuje wyrównanie w trybie łagodnym (relaxed), więc jeśli w polu „Od” jest firma-przyklad.pl, a podpis DKIM albo adres koperty używa subdomeny, na przykład sklep.firma-przyklad.pl, wyrównanie i tak zostanie zaliczone. Tryb ścisły ustawiają tagi adkim=s i aspf=s, ale małej firmie zwykle nie jest potrzebny.

Jak sprawdzić, czy rekordy działają?

Najprostszy test zrobisz w Gmailu, bez dodatkowych narzędzi. Wyślij wiadomość ze swojej domeny na konto Gmail, otwórz ją, obok przycisku „Odpowiedz” kliknij menu z trzema kropkami i wybierz „Pokaż oryginał”. W nagłówku Authentication-Results szukaj wpisów spf=pass i dkim=pass. Jeśli jest tam też wynik DMARC, powinien brzmieć dmarc=pass.

Same rekordy sprawdzisz w wierszu poleceń. W systemie Windows wpisz w menu Start cmd, otwórz wiersz poleceń i wpisz po kolei:

nslookup -type=TXT firma-przyklad.pl
nslookup -type=TXT _dmarc.firma-przyklad.pl
nslookup -type=TXT s2026._domainkey.firma-przyklad.pl

Typowe przyczyny problemów:

• Dwa rekordy SPF po dodaniu nowego dostawcy obok starego wpisu.
• Przekroczony limit 10 zapytań, gdy w SPF jest kilka include, które same zawierają kolejne.
• Nadawca spoza spisu, na przykład stary formularz na stronie wysyłający pocztę z serwera WWW.
• Od razu p=reject, bez tygodnia obserwacji raportów.
• Zbyt szybkie wnioski. Nowy rekord zaczyna obowiązywać, gdy w pamięci podręcznej serwerów wygaśnie stary, czyli po czasie TTL, na przykład po 3600 sekundach przy wartości z przykładów.

Jeśli zmieniasz serwery DNS albo przenosisz domenę razem ze strefą DNS prowadzoną przez rejestratora, przed zmianą spisz wszystkie rekordy strefy, zwłaszcza MX, SPF, DKIM (selektor._domainkey) i _dmarc. Po zmianie sprawdź, czy są w nowej strefie, bo bez nich poczta może trafiać do spamu albo zostać odrzucona. Sam transfer opisałem w poradniku o przenoszeniu domeny.

DNSSEC to osobna sprawa: chroni odpowiedzi DNS przed sfałszowaniem, ale nie zastępuje SPF, DKIM i DMARC. Więcej o nim w tekście o protokole DNSSEC. Jeśli dopiero zakładasz skrzynkę w programie pocztowym, zajrzyj do instrukcji konfiguracji poczty w Thunderbirdzie.

FAQ: pytania i odpowiedzi

Czy wystarczy sam rekord SPF?

Dla podstawowych wymagań Gmaila i Yahoo wystarczy SPF albo DKIM. Sam SPF nie chroni jednak adresu w polu „Od”, bo sprawdza adres z koperty wiadomości. Przed podszywaniem chroni dopiero DMARC z polityką quarantine albo reject. Samo p=none tylko raportuje.

Czy DMARC wymaga, żeby przeszły i SPF, i DKIM?

Nie. Wystarczy, że jeden z nich da wynik pozytywny i jego domena będzie zgodna z domeną w polu „Od”. Google od nadawców powyżej 5000 wiadomości dziennie wymaga skonfigurowania obu mechanizmów, ale wyrównany musi być tylko jeden.

Czy DKIM szyfruje wiadomość?

Nie. DKIM dodaje podpis, który potwierdza nadawcę i nienaruszoną treść, ale sama wiadomość pozostaje jawna. Za szyfrowanie połączenia między serwerami odpowiada TLS.

Po jakim czasie nowe rekordy zaczynają działać?

To zależy od TTL starego rekordu, czyli czasu, przez który serwery trzymają go w pamięci. Przy TTL 3600 sekund większość serwerów zobaczy zmianę w ciągu godziny. Z DMARC odczekaj co najmniej 48 godzin od ustawienia SPF i DKIM, tak jak zaleca Google.