SPF, DKIM i DMARC - jak je ustawić, żeby maile firmy dochodziły

Kiedy maile z firmy trafiają do spamu, winne są zwykle trzy wpisy w DNS, których nikt nie ustawił przy zakładaniu domeny. Nie wtyczka, nie hosting, nie treść wiadomości. Kto wpisuje w Google „spf dkim dmarc”, ma zwykle za sobą kilka rozmów w stylu „wysłałem ofertę w poniedziałek, nie dostałeś?” i szuka jednej konkretnej rzeczy: co wkleić w panelu domeny i jak sprawdzić, że zadziałało.

Ten tekst jest o konfiguracji od zera, dla domeny małej firmy, która ma pocztę w jednym miejscu, a stronę w drugim. Diagnozę sklepu, który w ogóle nie wysyła powiadomień, rozłożyłem osobno w tekście o WooCommerce, który nie wysyła maili o zamówieniach. Tutaj zakładam, że wiadomości wychodzą poprawnie, tylko nikt po drugiej stronie nie ma powodu im wierzyć.

Jedno ostrzeżenie na start. DNS to jedno z niewielu miejsc, w których literówka zatrzymuje całą pocztę firmy, nie tylko tę ze strony. Rób to na spokojnie, przed każdą zmianą skopiuj sobie obecną wartość rekordu do notatnika i zmieniaj po jednym wpisie.

SPF, DKIM i DMARC - po co są i dlaczego bez nich maile firmy lądują w spamie

Serwer odbiorcy dostaje wiadomość, która twierdzi, że jest od Twojej firmy. Nie ma powodu w to wierzyć, bo pole nadawcy w mailu można wpisać dowolne, tak samo jak nadawcę na kopercie. Trzy wpisy w DNS Twojej domeny są jedynym miejscem, w którym możesz mu powiedzieć, jak odróżnić Twoją wiadomość od podróbki.

SPF odpowiada na pytanie „czy ten serwer ma prawo wysyłać w imieniu tej domeny”. To lista adresów i usług, którym na to pozwalasz. Jeśli poczta stoi w Google Workspace, a strona wysyła przez hosting, na liście muszą być oba, bo to dwa niezależne kanały.

DKIM odpowiada na pytanie „czy treść nie została po drodze podmieniona i czy nadawca ma klucz”. Serwer wysyłający podpisuje wiadomość kluczem prywatnym, a klucz publiczny leży w Twoim DNS. Odbiorca sam sprawdza podpis, nikogo o nic nie pytając.

DMARC odpowiada na pytanie „co zrobić, kiedy pierwsze dwa nie przeszły”. To Twoja instrukcja dla całego internetu: przepuść mimo wszystko, wrzuć do spamu albo odrzuć. Przy okazji DMARC każe odbiorcom przysyłać Ci raporty o tym, kto wysyła z Twojej domeny.

Ważny szczegół, który gubi najwięcej osób: DMARC nie patrzy tylko na to, czy SPF lub DKIM przeszły. Sprawdza jeszcze, czy domena z podpisu zgadza się z domeną widoczną w polu nadawcy. Można mieć poprawny SPF i nadal oblać DMARC, jeśli wiadomość wychodzi z cudzej domeny technicznej. To dlatego sama wtyczka SMTP czasem nie wystarcza.

Czego wymaga dziś Gmail od nadawcy

Warto wiedzieć, jaka jest poprzeczka, zanim zaczniesz cokolwiek wpisywać. Według wytycznych Google dla nadawców każdy, kto wysyła maile na adresy Gmaila, ma mieć ustawione SPF lub DKIM, poprawny rekord PTR dla adresu IP serwera, wysyłkę szyfrowaną połączeniem TLS i poziom zgłoszeń spamu poniżej 0,3 procent mierzony w narzędziu Postmaster Tools.

Nadawcy masowi, czyli tacy, którzy wysyłają ponad pięć tysięcy wiadomości dziennie na adresy Gmaila, mają w tej samej dokumentacji wymagania ostrzejsze: SPF i DKIM równocześnie, do tego DMARC, zgodność domeny nadawcy z domeną z podpisu oraz wypisanie się z newslettera jednym kliknięciem. Zasady obowiązują od lutego 2024 roku i inne duże skrzynki poszły w tę samą stronę.

Mała firma rzadko dobija do progu nadawcy masowego, ale konfiguracja niżej i tak jest kompletna - przy trzech rekordach nie ma sensu robić połowy roboty.

Jak ustawić po kolei: rekordy w DNS dla poczty firmowej

Zaczynasz od poczty, bo to kanał, na którym stoją oferty i faktury. Wszystkie przykłady piszę na domenie twojafirma.pl - podstaw swoją i nie kopiuj wartości w ciemno.

Krok 1. Sprawdź, co już masz. W panelu, w którym trzymasz DNS domeny (rejestrator, hosting albo Cloudflare), otwórz listę rekordów i poszukaj wpisów typu TXT. Interesuje Cię wpis zaczynający się od v=spf1 i wpis na nazwie _dmarc. Zapisz sobie ich obecną treść. Jeśli jest już jakiś SPF, będziesz go poprawiał, nie dodawał drugiego.

Krok 2. SPF. Jeden rekord TXT na głównej nazwie domeny. Dla poczty w Google Workspace wygląda tak:

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

Jeśli oprócz poczty wysyła też serwer hostingu ze stroną, dopisujesz go do tego samego rekordu, nie zakładasz drugiego:

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

Dwie zasady, które ratują przed najczęstszymi wpadkami. Rekord SPF w domenie może być tylko jeden - dwa oznaczają błąd i odbiorca traktuje oba jako nieważne. I druga: na końcu zostaw ~all (miękkie odrzucenie), dopóki nie masz pewności, że wymieniłeś wszystkie serwery, które faktycznie wysyłają. Twarde -all jest docelowo lepsze, ale zakłada, że o niczym nie zapomniałeś.

Krok 3. DKIM. Tego rekordu nie wymyślasz - dostajesz go od dostawcy poczty. W Google Workspace idziesz w konsoli administratora do Aplikacje, dalej Google Workspace, dalej Gmail i wybierasz „Uwierzytelnij e-mail”. Zgodnie z dokumentacją Google Workspace domyślny prefiks klucza to google, a zalecana długość to 2048 bitów, o ile Twój dostawca DNS ją obsługuje. Konsola wygeneruje klucz i pokaże gotowy rekord TXT do wklejenia:

google._domainkey.twojafirma.pl    TXT    v=DKIM1; k=rsa; p=MIIBIjANBgkq...

Po wklejeniu rekordu wracasz do konsoli i uruchamiasz podpisywanie przyciskiem, który w interfejsie angielskim nazywa się „Start authentication”. To krok, o którym łatwo zapomnieć: sam rekord w DNS niczego nie włącza, dopóki dostawca nie zacznie podpisywać.

Krok 4. DMARC. Jeden rekord TXT na nazwie _dmarc. Zaczynasz od trybu obserwacji, żeby zobaczyć ruch, zanim zaczniesz cokolwiek odrzucać. Przykład rekordu DMARC na start:

_dmarc.twojafirma.pl    TXT    v=DMARC1; p=none; rua=mailto:dmarc@twojafirma.pl

p=none znaczy „nic nie blokuj, tylko mi raportuj”. rua to adres, na który mają przychodzić zbiorcze raporty. Po kilku tygodniach, kiedy raporty potwierdzą, że wszystkie Twoje kanały wysyłki przechodzą, zaostrzasz politykę do p=quarantine, a docelowo do p=reject. Ta kolejność nie jest ostrożnościowa dla ozdoby: ustawienie p=reject od razu przy niekompletnym SPF kasuje własne faktury w locie.

Na propagację zmian daj sobie dobę. Rekordy TXT zwykle wchodzą w kilkanaście minut, ale stare wartości potrafią siedzieć w pamięci podręcznej serwerów odbiorców znacznie dłużej.

DKIM na WordPressie i w WooCommerce, czyli drugi kanał wysyłki

Tu zaczyna się część, której nie widać w poradnikach od dostawców poczty. Strona firmowa i sklep to osobny nadawca, nawet jeśli adres w polu „od” jest ten sam. Formularz kontaktowy, potwierdzenie zamówienia i reset hasła wychodzą z serwera hostingu, nie ze skrzynki w Workspace.

Domyślnie WordPress wysyła funkcją wp_mail(), czyli przez lokalną pocztę serwera, bez podpisu i bez uwierzytelnienia. Taka wiadomość nie ma jak przejść DKIM, a przy DMARC z polityką inną niż none po prostu znika.

Poprawna kolejność jest taka:

1. Podepnij wysyłkę pod prawdziwą skrzynkę przez SMTP. Strona zaczyna wtedy wysyłać jako uwierzytelniony nadawca i dziedziczy podpis DKIM Twojego dostawcy poczty, więc jej wiadomości w ogóle mają szansę przejść DMARC. Samo ustawienie wtyczki, dopasowanie adresów i limity skrzynki rozpisałem przy diagnozie sklepu i nie powtarzam tego tutaj.
2. Gdy wolumen przerasta skrzynkę, przejdź na osobny serwis wysyłek transakcyjnych - i w tym samym ruchu dołóż jego include: do SPF oraz jego własny rekord DKIM, zwykle na innym prefiksie niż google.

Ten ostatni punkt to najczęstsza przyczyna sytuacji „ustawiłem wszystko, a i tak nie dochodzi”. Ktoś wpina serwis wysyłkowy, zapomina dodać go do SPF, i sklep nadal wysyła jako nadawca, którego domena się nie przyznaje.

Jak sprawdzić, że działa, i jak czytać raporty DMARC

Sprawdzam zawsze w tej kolejności i dopiero po trzecim punkcie uznaję temat za zamknięty.

Najpierw nagłówki jednej wiadomości. Wyślij maila ze strony i drugiego ze skrzynki na adres w Gmailu. W Gmailu rozwiń menu otwartej wiadomości i wybierz podgląd oryginału. Zobaczysz trzy linijki, SPF, DKIM i DMARC, z wynikiem przy każdej. Interesuje Cię wynik przy obu wiadomościach, bo to dwa różne kanały i bardzo często jeden przechodzi, a drugi nie.

Potem test z zewnętrznego walidatora. Wpisujesz domenę i dostajesz składniowy przegląd wszystkich trzech rekordów. To wyłapuje rzeczy, których nie widać w jednej wiadomości: dwa rekordy SPF naraz, przekroczony limit odwołań include:, literówkę w kluczu DKIM.

Na końcu raporty DMARC. Na adres z pola rua zaczną przychodzić pliki XML, po jednym dziennie od każdego większego dostawcy poczty. Surowy XML jest nieczytelny dla człowieka, więc albo wrzucasz go do darmowej przeglądarki raportów, albo podajesz w rua adres u usługi, która robi z nich tabelę.

W raporcie szukasz trzech rzeczy. Po pierwsze, listy adresów IP wysyłających z Twojej domeny - powinny tam być tylko Twoje kanały, a każdy obcy wpis to albo zapomniana usługa, albo ktoś podszywający się pod firmę. Po drugie, kolumny z wynikiem SPF i DKIM - przy poprawnej konfiguracji rośnie udział wiadomości z obydwoma zgodnymi. Po trzecie, liczby przy wierszach, które oblały: jeśli po dwóch, trzech tygodniach zostały przy zerze, możesz bezpiecznie zaostrzyć politykę.

Dopóki w raportach widać ruch, którego nie umiesz nazwać, nie przestawiaj p=none. To jedyna reguła w tym tekście, którą warto traktować dosłownie.

Co robię inaczej - maile ze strony i sklepu przez osobny serwis wysyłkowy

U klientów, u których wysyłka ze strony cokolwiek znaczy dla sprzedaży, rozdzielam kanały od razu. Poczta ludzka zostaje tam, gdzie jest, a strona i sklep dostają własnego dostawcę wysyłek transakcyjnych, z własnym DKIM i własnym wpisem w SPF.

Trzy powody, wszystkie z praktyki. Po pierwsze, limity: skrzynka pocztowa nie jest projektowana do wysyłania dwustu potwierdzeń dziennie i przy skoku sprzedaży zatrzymuje się w połowie dnia. Po drugie, widoczność: osobny kanał ma własny log, więc na pytanie „czy klient dostał fakturę” odpowiadasz w minutę zamiast zgadywać. Po trzecie, ryzyko: jeśli formularz na stronie zostanie zasypany fałszywymi zamówieniami i spamem, reputacja obrywa na koncie wysyłkowym, a nie na skrzynce, z której wysyłasz oferty.

Trzy rekordy DNS to nie jest robota, którą robi się raz i zapomina. Dostawcy zmieniają wartości include:, klucze DKIM się rotuje, a każdy nowy system, który wysyła w imieniu firmy, wymaga aktualizacji SPF. U klientów, których mam pod stałą opieką, stan tych rekordów i raporty DMARC sprawdzam cyklicznie, razem z backupami i aktualizacjami - dokładnie dlatego, że to awaria, której nikt nie zauważa w dniu, w którym się wydarza.

Podszywanie się pod firmę i granica, przy której kończy się moja rola

Poprawny DMARC ma jeszcze jeden skutek, o którym mało kto myśli przy wdrożeniu: utrudnia wysyłanie fałszywych faktur i próśb o przelew w imieniu Twojej firmy. Przy polityce p=reject wiadomość podszywająca się pod Twoją domenę zostaje odrzucona zanim ktokolwiek ją zobaczy.

Nie jest to ochrona pełna, bo nie obejmuje adresów łudząco podobnych, założonych na innej domenie. I nie jest to porada prawna. Kwestie odpowiedzialności za skutki podszycia, obowiązki wobec danych osobowych w skrzynce i to, co zgłasza się organom po incydencie, potwierdź u prawnika - ja odpowiadam za to, żeby rekordy były poprawne, nie za kwalifikację prawną zdarzenia.

Najczęstsze pytania

Czy potrzebuję wszystkich trzech, czy wystarczy SPF? Do minimum wymaganego przez Gmaila od zwykłego nadawcy wystarczy SPF albo DKIM. W praktyce sam SPF przestaje działać przy przekierowaniach wiadomości, bo zmienia się serwer wysyłający, a podpis DKIM przeżywa przekierowanie bez szwanku. DMARC dokładany na końcu zamienia dwa poprzednie w rzeczywistą ochronę i daje raporty. Robiąc to raz, zrób od razu wszystkie trzy.

Mam pocztę na hostingu, nie w Google Workspace. Co się zmienia? Tylko wartości. W SPF wpisujesz include: swojego hostingu zamiast _spf.google.com, a rekord DKIM generujesz w panelu hostingu, gdzie zwykle siedzi pod nazwą „podpis DKIM” albo „uwierzytelnianie poczty”. Prefiks klucza bywa inny niż google - bierzesz ten, który poda panel. Rekord DMARC jest identyczny niezależnie od dostawcy.

Ustawiłem wszystko, a maile ze sklepu nadal idą do spamu. Gdzie szukać? Prawie zawsze w kanale, o którym zapomniano. Otwórz nagłówki wiadomości ze sklepu, nie ze skrzynki, i sprawdź, jaka domena widnieje przy podpisie DKIM. Jeśli jest to domena hostingu albo wtyczki, a nie Twoja, wiadomość oblewa zgodność domen w DMARC mimo poprawnych rekordów. Rozwiązaniem jest wysyłka przez SMTP albo osobny serwis transakcyjny.

Jak długo czekać między p=none a p=reject? Do momentu, w którym raporty przez dwa tygodnie z rzędu nie pokazują ruchu z nieznanych źródeł. Kalendarzowo wychodzi zwykle miesiąc, przy firmie z kilkoma systemami wysyłającymi dłużej. Pośredni krok p=quarantine warto zrobić, bo kieruje podejrzane wiadomości do spamu zamiast je kasować, więc błąd da się jeszcze zauważyć.

Czy zmiana tych rekordów może zablokować moją zwykłą pocztę? Tak i to jest realne ryzyko, dlatego kolejność w tym tekście jest taka, a nie inna. Błędny SPF z -all albo p=reject przy niekompletnej liście nadawców zatrzymuje także maile, które wysyłasz ręcznie z Outlooka. Dlatego zaczyna się od ~all i p=none, a zaostrza dopiero na podstawie raportów.

Nie chcesz pilnować tego co miesiąc samemu? Biorę strony i sklepy pod stałą opiekę - backupy, aktualizacje, monitoring i priorytet, kiedy coś padnie. Napisz, co masz pod sobą, a odeślę zakres i cenę.