Skonfigurowałeś SPF. Skonfigurowałeś DKIM. Włączyłeś DMARC, bo ktoś Ci powiedział, że tak trzeba. Tydzień później Twoje potwierdzenia zamówień lądują w spamie klientów, a Ty nie masz pojęcia dlaczego, przecież wszystko było "zrobione".
To jeden z najczęstszych scenariuszy, jakie widzimy w audytach dostarczalności. Nie dlatego, że SPF, DKIM i DMARC są trudne. Dlatego, że kolejność i sposób ich wdrożenia mają większe znaczenie niż sama obecność tych trzech rekordów.
Co to naprawdę są SPF, DKIM i DMARC
Trzy rekordy DNS, trzy różne pytania, na które odpowiadają dostawcy skrzynek pocztowych, zanim zdecydują, co zrobić z Twoim mailem.
SPF (Sender Policy Framework) odpowiada: czy ten serwer ma prawo wysyłać w imieniu tej domeny? To lista dozwolonych adresów IP wpisana w DNS.
DKIM (DomainKeys Identified Mail) odpowiada: czy wiadomość dotarła bez zmian po drodze? Twój serwer podpisuje każdy mail cyfrowo, odbiorca weryfikuje podpis kluczem publicznym z DNS.
DMARC (Domain-based Message Authentication, Reporting & Conformance) odpowiada na trzecie pytanie, ważniejsze niż dwa poprzednie razem wzięte: co zrobić, jeśli SPF lub DKIM zawiodą? Bez DMARC ta decyzja należy do każdego dostawcy skrzynki z osobna, czyli w praktyce do nikogo.
Protokół, podpis, polityka: kolejność, która oszczędza tygodnie naprawiania
Po dziesiątkach wdrożeń, u nas i u klientów, którzy przychodzą z już popsutą konfiguracją, sprowadza się to zawsze do tej samej kolejności: najpierw protokół (SPF), potem podpis (DKIM), na końcu polityka (DMARC).
Krok | Element | Co robi | Co się dzieje, jeśli pominięty |
|---|---|---|---|
1. Protokół | SPF | Autoryzuje serwery wysyłkowe | Maile z nieautoryzowanych serwerów przechodzą bez weryfikacji |
2. Podpis | DKIM | Potwierdza integralność treści | Brak dowodu, że mail nie został zmodyfikowany po drodze |
3. Polityka | DMARC | Mówi odbiorcy, co zrobić przy błędzie | Każdy dostawca decyduje sam, niespójnie |
To nie przypadek. DMARC jest tym elementem, o którym mówi się najgłośniej, bo to on pojawia się w wymaganiach Google i w checklistach "zgodności z 2024 rokiem".
SPF i DKIM brzmią jak technikalia dla informatyka, coś do zrobienia "przy okazji". DMARC brzmi jak coś, co trzeba włączyć, żeby być compliant. Więc ktoś włącza DMARC najpierw, bo to jest ta rzecz z artykułu, którą zapamiętał, i dopiero kilka tygodni później odkrywa, że pod spodem nic solidnego nie stoi, żadne źródło wysyłki nie jest jeszcze poprawnie zweryfikowane przez SPF i DKIM.
Choć, prawdę mówiąc, ta kolejność bywa mniej sztywna, niż to przedstawiamy. Zdarza się, że platforma ESP wymusza własny DKIM zanim jeszcze zdążysz dotknąć SPF. Wtedy protokół i podpis mogą się zamienić miejscami, ale polityka zawsze zostaje na końcu.
Najczęstszy błąd z audytów: DMARC na „reject" wdrożony za wcześnie
Ktoś przeczytał artykuł, że DMARC z polityką "reject" to najbezpieczniejsza opcja. Technicznie prawda. W praktyce, jeśli wdrożysz "reject" zanim upewnisz się, że wszystkie Twoje źródła wysyłki (ESP, CRM, system fakturowania, czasem nawet drukarka biurowa skonfigurowana do wysyłki skanów) przechodzą poprawnie SPF i DKIM, DMARC zacznie odrzucać Twoje własne maile. Nie maile spamerów. Twoje.
Widzieliśmy to u sklepu, który wdrożył"reject" w piątek po południu, bo "tak zalecał poradnik". W poniedziałek dział obsługi klienta dostał kilkanaście zgłoszeń o brakujących potwierdzeniach zamówień. Cofnięcie na "quarantine", a potem żmudne dochodzenie, które z pięciu systemów wysyłkowych w firmie nie miało poprawnego SPF, zajęło prawie dwa tygodnie. Nie każde źródło udało się zresztą do końca ustandaryzować, jeden ze starszych systemów faktur wciąż wysyła sporadycznie bez DKIM, więc "reject" u nich nadal czeka.
Dlatego zawsze zaczynamy od "p=none". Ten poziom niczego nie blokuje, tylko zbiera raporty o tym, co realnie wysyła w Twoim imieniu. Dopiero gdy raporty są czyste przez kilka tygodni, przechodzimy do "quarantine", a "reject" zostawiamy na koniec.
Zapamiętaj: "p=reject" od razu to najczęstsza przyczyna, dla której firmy same się blokują. Zacznij od "p=none", obserwuj raporty, dopiero potem zaostrzaj.
Limit 10 wyszukiwań DNS w SPF, cichy zabójca, o którym nikt nie mówi
To jest ta część, którą pomija większość poradników, bo brzmi zbyt technicznie. A jednak to ona najczęściej psuje SPF po cichu.
Rekord SPF ma twardy limit 10 wyszukiwań DNS (mechanizmy "include","a", "mx", "ptr", "exist"). Każda platforma, którą dodajesz do wysyłki, GetResponse, Klaviyo, system fakturowania, czasem Google Workspace, dokłada własny "include". Przekroczysz limit, SPF zwraca "permerror", a dostawcy skrzynek traktują to jak brak SPF w ogóle. Cicho. Bez żadnego komunikatu w Twoim panelu.
U jednego z klientów e-commerce, z którymi pracowaliśmy, rekord SPF zawierał siedem różnych "include", zbieranych latami przy każdej zmianie narzędzia, bez nigdy nieusuniętych starych wpisów. Trzynaście wyszukiwań łącznie, może czternaście, w dokumentacji audytu ta liczba nie jest do końca jednoznaczna. Przez ile dokładnie miesięcy to trwało, nie jesteśmy w stanie dziś odtworzyć, klient sam nie wiedział, kiedy dokładnie problem się zaczął. Wiemy tylko, że po spłaszczeniu rekordu do jednego zbiorczego "include" open rate wrócił do normy w ciągu kilku dni.
Sprawdzić limit możesz bezpłatnie w MXToolbox, zakładka SPF Record Lookup pokazuje dokładną liczbę wyszukiwań.
Jak wdrożyć SPF, DKIM i DMARC krok po kroku
Ale serio: całą powyższą teorię można streścić w pięciu krokach, bez żargonu.
- SPF najpierw. Zbierz wszystkie źródła wysyłki (ESP, CRM, fakturowanie, formularze na stronie) i dodaj je jako jeden rekord TXT. Jeśli zbliżasz się do limitu 10 wyszukiwań, spłaszcz rekord zamiast dodawać kolejne "include".
- DKIM zaraz potem. Każda platforma wysyłkowa generuje własny klucz DKIM, dodajesz go jako osobny rekord TXT z unikalnym selektorem.
- DMARC na "p=none". Zbieraj raporty (agregowane, RUA) przez minimum dwa do czterech tygodni.
- Przegląd raportów. Sprawdź, które źródła nie przechodzą SPF lub DKIM, popraw je pojedynczo.
- "p=quarantine"
potem "p=reject". Dopiero gdy raporty są czyste.
Poziom DMARC | Co robi | Kiedy stosować |
|---|---|---|
p=none | Nic nie blokuje, tylko raportuje | Zawsze na start, minimum kilka tygodni |
p=quarantine | Podejrzane maile trafiają do spamu | Po oczyszczeniu raportów z none |
p=reject | Podejrzane maile są całkowicie odrzucane | Na końcu, gdy wszystkie źródła są potwierdzone |
Od lutego 2024 roku Google i Yahoo wymagają poprawnego SPF, DKIM i DMARC (choćby na "p=none") od nadawców wysyłających powyżej 5000 wiadomości dziennie do adresów Gmail. Poniżej tego progu nie ma formalnego obowiązku, ale filtry antyspamowe i tak traktują brak uwierzytelnienia jako sygnał ryzyka.
Czy warto pomyśleć też o BIMI
Skoro DMARC jest już na "quarantine" lub "reject". Jeden krok dalej prowadzi do BIMI, standardu, który wyświetla logo firmy obok nazwy nadawcy w Gmailu. Nie poprawia bezpośrednio dostarczalności, ale w Polsce wciąż niewiele firm e-commerce z tego korzysta.
Najczęściej zadawane pytania
Technicznie tak, ale nie powinieneś. Bez SPF każdy serwer mógłby próbować wysyłać w Twoim imieniu, a DKIM sam w sobie nie ogranicza, kto wysyła, tylko potwierdza integralność treści już wysłanej wiadomości.
Zwykle dwa do czterech tygodni wystarczają, żeby zebrać reprezentatywne raporty. Jeśli firma ma sezonowość sprzedaży (święta, wyprzedaże), warto poczekać, aż raporty obejmą też okres zwiększonej wysyłki.
Rekord zwraca błąd "permerror", który większość dostawców skrzynek traktuje tak, jakby SPF w ogóle nie istniał. Rozwiązanie to spłaszczenie rekordu, czyli zastąpienie wielu include jednym zbiorczym wpisem.
Tak, zawsze. Nowy dostawca ma inny rekord DKIM i często inny "include" SPF. Pominięcie tego kroku to jeden z najczęstszych powodów nagłego spadku dostarczalności po migracji.
Sprawdzić własną konfigurację można w trzy minuty w MXToolbox. Jeśli wolisz, żebyśmy zrobili to za Ciebie, łącznie z bezpieczną kolejnością wdrożenia DMARC, umów się na rozmowę z Pikodeo.
Źródła:
- Google: Wymagania dla nadawców masowych emaili (2024) — support.google.com/mail/answer/81126
- dmarc.org, dokumentacja techniczna DMARC
- MXToolbox, SPF Record Lookup
Powiązane: dostarczalność emaili, co to jest i dlaczego Twoje maile lądują w spamie
