Konfiguracja SPF, DKIM i DMARC dla zimnych e-maili: krok po kroku

Jeśli zimne e-maile wysyła się z własnej domeny, o tym, czy serwery odbierające uwierzą, że wiadomość naprawdę pochodzi od nadawcy, decydują trzy rekordy DNS: SPF, DKIM i DMARC. Bez nich nawet dobrze napisany pierwszy e-mail może zostać odfiltrowany, zanim ktokolwiek go przeczyta.

Ten przewodnik jest przeznaczony dla założycieli i zespołów sprzedaży, które wysyłają wiadomości z adresu takiego jak you@yourcompany.com, zwykle przez Google Workspace. My w Outreach omawiamy każdy rekord w kolejności, w jakiej należy go skonfigurować, pokazujemy formaty rekordów dokładnie tak, jak publikują je strony pomocy Google i dokumenty RFC, oraz wskazujemy błędy, przez które rekord wygląda poprawnie, a po cichu nie działa.

Nie trzeba być ekspertem od DNS. Potrzebny jest dostęp do ustawień DNS domeny (u rejestratora lub dostawcy DNS) oraz, w przypadku DKIM, dostęp administratora do Google Workspace.

Czym są SPF, DKIM i DMARC — po jednym zdaniu?

SPF wymienia serwery uprawnione do wysyłania poczty w imieniu domeny, DKIM dodaje podpis kryptograficzny potwierdzający, że wiadomość nie została sfałszowana ani zmieniona, a DMARC mówi odbiorcom, co zrobić, gdy wiadomość nie przejdzie tych kontroli. Wszystkie trzy są publikowane jako rekordy TXT w DNS domeny.

Działają razem. SPF i DKIM potwierdzają każdy coś wąskiego; DMARC wiąże te dowody z adresem, który ludzie faktycznie widzą w nagłówku From.

Czy te rekordy są naprawdę wymagane przy zimnych e-mailach?

Tak — co najmniej SPF lub DKIM jest wymagane od każdego nadawcy wysyłającego do Gmaila i Yahoo, a nadawcy masowi potrzebują wszystkich trzech. To nie jest zalecenie dotyczące dobrych praktyk, lecz zapis w opublikowanych zasadach obu dostawców dla nadawców.

Wytyczne Google dla nadawców e-maili mówią, że wszyscy nadawcy muszą „skonfigurować uwierzytelnianie e-maili SPF lub DKIM dla domen, z których wysyłają wiadomości.” Nadawcy wysyłający „ponad 5 000 wiadomości dziennie na konta Gmail” muszą ponadto „skonfigurować SPF i DKIM” oraz „uwierzytelnianie e-maili DMARC dla domeny nadawcy”, a domena w nagłówku From musi być zgodna z domeną SPF lub DKIM. Te zasady weszły w życie 1 lutego 2024 roku.

Najlepsze praktyki Sender Hub Yahoo są zgodne: każdy nadawca musi „wdrożyć co najmniej SPF lub DKIM”, a nadawcy masowi muszą „wdrożyć zarówno SPF, jak i DKIM” oraz „opublikować prawidłową politykę DMARC z co najmniej p=none.”

Mały program zimnych e-maili może nigdy nie dojść do 5 000 wiadomości dziennie. Mimo to warto skonfigurować wszystkie trzy: nic to nie kosztuje, zajmuje jedno popołudnie i sprawia, że nigdy nie trzeba sprawdzać, gdzie leży granica.

Jak skonfigurować SPF?

Należy dodać jeden rekord TXT w domenie głównej, który zaczyna się od v=spf1, wymienia każdą usługę wysyłającą pocztę w imieniu nadawcy i kończy się na ~all. Dla domeny wysyłającej wyłącznie przez Google Workspace strona Google o konfiguracji SPF podaje dokładnie taki rekord:

v=spf1 include:_spf.google.com ~all

Kroki:

1. Zaloguj się do ustawień DNS swojego dostawcy domeny.
2. Utwórz rekord TXT. W polu hosta lub nazwy Google każe wpisać @, jeśli rekord dodaje się do domeny głównej, a nie do subdomeny.
3. Wklej rekord jako wartość i zapisz.
4. Poczekaj. Google zaznacza: „Od momentu dodania rekordu do rozpoczęcia uwierzytelniania SPF może minąć nawet 48 godzin.”

Jeśli pocztę z domeny wysyłają także inne usługi — narzędzie do newsletterów, system CRM, usługa poczty transakcyjnej — każda potrzebuje własnego include: w tym samym rekordzie. Strona Google podaje takie połączone przykłady:

v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

Należy użyć wartości include, którą każda usługa wysyłająca podaje w swojej dokumentacji; nie wolno jej zgadywać.

Czy rekord SPF powinien kończyć się na ~all, czy na -all?

Przewodnik Google używa ~all i jest to bezpieczna wartość domyślna, dopóki nie odkryto jeszcze wszystkich usług wysyłających w imieniu domeny. Te dwa zakończenia znaczą co innego w RFC 7208, standardzie SPF:

• ~all (softfail) to „Słabe oświadczenie wydawcy (ADMD), że host prawdopodobnie nie jest uprawniony.”
• -all (fail) to „Jednoznaczne oświadczenie, że klient nie jest uprawniony do używania domeny w podanej tożsamości.”

Przy -all zapomniana usługa wysyłająca dostaje twardą odmowę. Gdy DMARC działa, a jego raporty pokazują, że każde legalne źródło przechodzi kontrolę, zakończenie SPF ma mniejsze znaczenie, ponieważ instrukcją, którą stosują odbiorcy, staje się polityka DMARC.

Dlaczego SPF przestaje działać przy zbyt wielu include?

Ponieważ jedna kontrola SPF może wywołać co najwyżej 10 zapytań DNS; po przekroczeniu tego limitu cały wynik staje się błędem. RFC 7208, sekcja 4.6.4 stanowi, że implementacje „MUSZĄ ograniczyć łączną liczbę tych terminów do 10 podczas oceny SPF” oraz „jeśli ten limit zostanie przekroczony, implementacja MUSI zwrócić 'permerror'.”

Liczą się terminy include, a, mx, ptr, exists oraz modyfikator redirect. Co kluczowe, limit obejmuje całą ocenę — więc include:, który sam zawiera kolejne include, zużywa kilka z tych 10. Strona Google ujmuje to jako „Rekord SPF może mieć do 10 tagów include:”; RFC jest ostrzejszą wykładnią, ponieważ zagnieżdżone zapytania też się liczą.

Jeśli przez lata dodano kilka narzędzi sprzedażowych i marketingowych, należy usunąć te, których już się nie używa, zanim doda się nowe include.

Co się dzieje, gdy domena ma dwa rekordy SPF?

SPF kończy się błędem — dwa rekordy są traktowane jako uszkodzona konfiguracja, a nie jako dwie listy do połączenia. RFC 7208 stanowi, że gdy dla domeny istnieje więcej niż jeden rekord v=spf1, kontrola „daje wynik 'permerror'.”

Typowa przyczyna: ktoś dodaje drugi rekord TXT dla nowego narzędzia zamiast edytować istniejący. Rozwiązaniem jest połączenie ich w jeden rekord z wieloma terminami include:, jak w powyższych przykładach.

Jak włączyć DKIM w Google Workspace?

Należy wygenerować klucz w konsoli administracyjnej, opublikować go jako rekord TXT w google._domainkey, a potem kliknąć „Rozpocznij uwierzytelnianie.” Strona Google o konfiguracji DKIM opisuje całą ścieżkę:

1. W konsoli administracyjnej Google przejdź do Aplikacje > Google Workspace > Gmail > Uwierzytelniaj pocztę e-mail. (Potrzebne są uprawnienia administratora Ustawienia Gmaila.)
2. Wybierz domenę i wygeneruj nowy rekord.
3. Wybierz długość klucza. Google każe wybrać 2048, „jeśli dostawca domeny obsługuje klucze 2048-bitowe”, ponieważ „dłuższe klucze są bezpieczniejsze niż krótsze”, a 1024 tylko wtedy, „gdy host domeny nie obsługuje kluczy 2048-bitowych.”
4. Zachowaj domyślny selektor prefiksu, czyli google — Google nazywa go „zalecaną opcją” dla Workspace.
5. Google pokazuje nazwę hosta DNS google._domainkey oraz wartość TXT zaczynającą się od v=DKIM1. Skopiuj obie do nowego rekordu TXT u dostawcy DNS.
6. Wróć do konsoli administracyjnej i kliknij Rozpocznij uwierzytelnianie.

Wartość TXT generowana przez Google ma taką postać (sam klucz to długi ciąg znaków unikalny dla domeny):

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

Czas: Google podaje, że po dodaniu klucza „może minąć nawet 48 godzin, zanim uwierzytelnianie DKIM zacznie działać”. Jeśli Gmail dopiero co skonfigurowano dla nowej domeny, Google zaznacza, że „trzeba odczekać od 24 do 72 godzin”, zanim klucz DKIM będzie w ogóle dostępny w konsoli administracyjnej.

Jeśli pocztę w imieniu domeny wysyła inna usługa, poda własny rekord DKIM z własnym selektorem. Należy opublikować również ten rekord — wiele kluczy DKIM z różnymi selektorami może współistnieć, w przeciwieństwie do SPF.

Jak skonfigurować DMARC, nie blokując własnej poczty?

Należy najpierw opublikować rekord TXT w _dmarc.yourcompany.com z p=none, przeczytać raporty i dopiero potem zaostrzyć politykę. Strona Google o konfiguracji DMARC mówi: „Gdy zaczynasz używać DMARC, zalecamy ustawić opcję polityki (p) na none.” Zaleca też, aby „odczekać 48 godzin po skonfigurowaniu SPF lub DKIM przed skonfigurowaniem DMARC.”

Strona Google podaje taki pełny przykładowy rekord:

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

Ten przykład pokazuje stan końcowy, najbardziej rygorystyczny. Na pierwszy rekord wystarczy ten sam format z polityką monitorowania i jednym adresem raportów — na przykład v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. Znacznik rua wysyła raporty zbiorcze na tę skrzynkę; Google zaleca osobną skrzynkę lub grupę, ponieważ raportów może przychodzić dużo.

Trzy wartości polityki, zgodnie ze specyfikacją DMARC:

Jedna domena ma mieć jeden rekord DMARC. Zgodnie z RFC 9989, jeśli zwróconych zostanie wiele rekordów DMARC, „wszystkie są odrzucane” — czyli nie obowiązuje żadna polityka.

Co oznacza „zgodność domen” (alignment) i dlaczego DMARC zawodzi, mimo że SPF przechodzi?

DMARC przechodzi tylko wtedy, gdy SPF lub DKIM przechodzi dla domeny zgodnej z adresem From, który widzą ludzie. SPF może przejść dla własnej domeny usługi wysyłającej, podczas gdy w nagłówku From widnieje domena nadawcy — i wtedy DMARC mimo to zawodzi, ponieważ domena, która przeszła kontrolę, nie jest zgodna.

Specyfikacja DMARC stanowi, że wiadomość przechodzi, gdy co najmniej jedna metoda uwierzytelniania daje wynik pozytywny „na podstawie identyfikatora, który jest w zgodności” (RFC 7489, kontynuowany obecnie w RFC 9989). Domyślnie zgodność jest luźna (adkim i aspf mają domyślnie wartość r): mail.yourcompany.com i yourcompany.com uznaje się za dopasowanie, ponieważ mają tę samą domenę organizacyjną. Tryb ścisły (s), jak w przykładzie Google, wymaga dokładnego dopasowania.

W praktyce dlatego DKIM ma tak duże znaczenie przy zimnych e-mailach: gdy usługa wysyłająca podpisuje wiadomości domeną nadawcy, zgodność DKIM przechodzi, nawet jeśli zgodność SPF nie przechodzi.

Czy standard DMARC zmienił się w 2026 roku?

Tak. RFC 9989, opublikowany w maju 2026 roku jako dokument na ścieżce standaryzacji (Standards Track), zastępuje pierwotny RFC 7489 — i usuwa znacznik pct. Istniejące rekordy v=DMARC1 nadal działają.

Główna zmiana, którą zauważy większość nadawców: pct (stosowanie polityki tylko do określonego odsetka wiadomości, które nie przeszły kontroli) zniknął. RFC wyjaśnia, że „doświadczenie operacyjne pokazało, że znacznik 'pct' zwykle nie był stosowany dokładnie, chyba że podana wartość wynosiła 0 lub 100.” Zastępuje go flaga testowa t=y, która prosi odbiorców, aby nie stosowali zadeklarowanej polityki, gdy jest ona testowana.

Strona pomocy Google nadal pokazuje pct=100 w swoim przykładzie. To niczego nie psuje: RFC 9989 stanowi, że „nieznane znaczniki MUSZĄ być ignorowane”, więc pozostały pct jest po prostu pomijany. Przy następnej edycji rekordu można go usunąć.

Jak sprawdzić, czy wszystko działa?

Należy sprawdzić opublikowane rekordy, a potem wysłać prawdziwą wiadomość na adres Gmail i przeczytać wyniki jej uwierzytelniania. Dwie szybkie kontrole:

1. Sprawdź rekordy DNS. Nasze bezpłatne narzędzie sprawdza rekordy SPF, DKIM i DMARC dla domeny wpisanego adresu — bez rejestracji. Sprawdza domyślny selektor DKIM Google (google._domainkey); jeśli usługa wysyłająca używa innego selektora, narzędzie zgłosi DKIM jako niepotwierdzony, nawet gdy jest skonfigurowany. Narzędzie jest dostępne po angielsku i koreańsku; należy wpisać adres e-mail, z którego się wysyła.
2. Sprawdź prawdziwą wiadomość. Wyślij e-mail na konto Gmail, nad którym masz kontrolę, otwórz go, wybierz „Pokaż oryginał” i poszukaj SPF: PASS, DKIM: PASS oraz DMARC: PASS.

Potem należy dać raportom DMARC tydzień lub dwa. Gdy każde używane legalne źródło widnieje jako przechodzące kontrolę, można przejść z p=none na p=quarantine, a później na p=reject, jeśli potrzebna jest najsilniejsza ochrona przed podszywaniem się.

Jakie błędy najczęściej psują uwierzytelnianie?

Dwa rekordy SPF, zbyt wiele zapytań SPF, DKIM wygenerowany, ale nigdy nieuruchomiony, oraz DMARC opublikowany, zanim SPF i DKIM zdążyły zacząć działać. Lista kontrolna:

• Jeden rekord SPF, w którym każdy nadawca występuje jako include:, i nie więcej niż 10 terminów zapytań.
• Kliknij „Rozpocznij uwierzytelnianie” po opublikowaniu klucza DKIM — sam rekord DNS nie wystarczy.
• Odczekaj około 48 godzin po SPF i DKIM, zanim dodasz DMARC, i opublikuj go w _dmarc, a nie w domenie głównej.
• Wysyłaj z domeny, którą kontrolujesz. Nie można opublikować DMARC dla adresu @gmail.com.

Uwierzytelnianie sprawia, że poczta jest brana pod uwagę; nie sprawia, że odbiorcy jej chcą. Skargi na spam nadal się liczą — Google i Yahoo zalecają utrzymywać odsetek spamu poniżej 0.3%, jak opisujemy w tekście dlaczego zimne e-maile trafiają do spamu. A wysyłanie na adresy, które nie istnieją, powoduje odbicia, dlatego zalecamy zweryfikować adresy przed wysyłką.

W skrócie

• Google i Yahoo wymagają SPF lub DKIM od każdego nadawcy, a od nadawców masowych (5 000 lub więcej wiadomości dziennie do Gmaila) — wszystkich trzech oraz zgodności domen.
• SPF: jeden rekord TXT w @, na przykład v=spf1 include:_spf.google.com ~all; w granicach 10 terminów zapytań DNS.
• DKIM: klucz 2048-bitowy, selektor google, TXT w google._domainkey, potem Rozpocznij uwierzytelnianie.
• DMARC: jeden rekord TXT w _dmarc, start od p=none z adresem raportów, zaostrzenie później. RFC 9989 (maj 2026) zastąpił pct przez t=y.
• Rekordy można sprawdzić naszym bezpłatnym narzędziem do sprawdzania uwierzytelniania poczty, a potem potwierdzić na prawdziwej wiadomości.