Maile z firmowej domeny w spamie: SPF, DKIM, DMARC

Zanim zaczniesz przepisywać treść oferty i wycinać z tematu słowo „promocja”, otwórz nagłówki jednego listu, który wylądował w spamie. Serwer odbiorcy zapisał w nich czarno na białym, czy uwierzył, że wiadomość naprawdę wysłała Twoja domena. Jeśli nie uwierzył, przyczyna siedzi w DNS, a nie w treści. Poprawka zajmuje zwykle kwadrans.

Za tę wiarygodność odpowiadają trzy rekordy TXT. SPF to lista serwerów, które mogą wysyłać pocztę z Twoją domeną w kopercie listu. DKIM to podpis cyfrowy w nagłówku. Klucz publiczny, którym odbiorca go sprawdza, leży w DNS Twojej domeny. DMARC spina oba i mówi odbiorcy, co zrobić z listem, który nie przeszedł testu dla domeny widocznej w polu „Od”.

Ten ostatni warunek łatwo przeoczyć. SPF i DKIM mogą przejść dla zupełnie innej domeny, na przykład technicznej domeny dostawcy newslettera. DMARC wymaga, żeby przynajmniej jeden z nich przeszedł dla Twojej. Od lutego 2024 roku Gmail wymaga od każdego, kto wysyła na prywatne skrzynki Gmail, co najmniej SPF albo DKIM, a od wysyłających tam ponad 5000 listów dziennie kompletu z DMARC włącznie. Pierwszy warunek dotyczy także firmy, która wysyła dziesięć faktur dziennie.

Krok 1: przeczytaj, co zapisał odbiorca (5 minut)

Wyślij list z firmowej skrzynki na prywatny adres w Gmailu. Otwórz go, rozwiń menu z trzema kropkami obok przycisku „Odpowiedz” i wybierz „Pokaż oryginał”. Nad treścią źródła Gmail wypisuje osobno wynik SPF, DKIM i DMARC. Wszystkie trzy mają mieć PASS.

W Thunderbirdzie źródło otworzysz skrótem Ctrl+U. Szukasz nagłówka Authentication-Results, a w nim takich fragmentów:

dkim=pass ... header.i=@example.pl
spf=pass ... smtp.mailfrom=jan@example.pl
dmarc=pass ... header.from=example.pl

Najwięcej mówi ostatnia linia. spf=pass przy adresie technicznym w cudzej domenie wygląda dobrze, ale dla DMARC nic nie znaczy.

Obok znajdziesz nagłówek DKIM-Signature. Poniżej podpis postawiony przez nasz serwer pocztowy. Pochodzi z listu testowego wysłanego ze strony klienta przez SMTP skrzynki, w środowisku testowym. Domenę i selektor zamieniliśmy na przykładowe, a sam podpis skróciliśmy:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.pl;
	s=rdc1; t=1790407031;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc; bh=+PgDC9bCFd8Ee3qdVeXjPe5gc4bA2Dfiscf7NmQkBUE=;
	b=FxzCci8QWxQppRWdyeXbbvvF5Gu/NwV6OvhekXAbtlD88YOiqyAgkRah4bEL7NESnynfwk
	 b90X/AjINWipB4Tr5P6TyRSsv3kmoGlk0+qgGtydJTx58RkLVpn08/5u78gJ3inRD96gz3...

d= to domena, w imieniu której podpisano list, a s= to selektor. Razem wskazują rekord, pod który zajrzy odbiorca: rdc1._domainkey.example.pl. W h= stoi lista podpisanych nagłówków. from występuje w niej dwa razy celowo: podpis pęka, gdy ktoś po drodze dopisze drugie pole „Od”. bh= to skrót treści, więc zmiana treści po drodze też unieważnia podpis. Tryb c=relaxed wybacza tylko drobne różnice w odstępach i końcach linii.

Krok 2: odczytaj rekordy z DNS (5 minut)

Selektor znasz już z nagłówka. Trzy polecenia pokażą, co widzi świat:

dig +short TXT example.pl
dig +short TXT rdc1._domainkey.example.pl
dig +short TXT _dmarc.example.pl

Na Windowsie zamiast dig użyjesz nslookup -type=TXT example.pl. Dla domeny, której DNS prowadzimy, komplet wygląda tak:

example.pl.                  TXT  "v=spf1 include:_spf.isbre.pl ~all"
rdc1._domainkey.example.pl.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
_dmarc.example.pl.           TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@isbre.pl; adkim=r; aspf=r"

include:_spf.isbre.pl odsyła do jednego rekordu z adresami naszych serwerów wysyłkowych. Gdy adres się zmieni, poprawiamy jeden rekord u siebie, a Twój zostaje bez zmian. Klucz DKIM ma 2048 bitów, więc rekord nie mieści się w jednym łańcuchu znaków i dig pokaże go w dwóch kawałkach w osobnych cudzysłowach. To poprawny zapis, odbiorca skleja kawałki sam.

Całość chcesz sprawdzić jednym ruchem? Wyślij list na adres wygenerowany przez mail-tester.com. Dostaniesz ocenę i rozpisane wyniki SPF, DKIM i DMARC dla konkretnej wiadomości.

Pięć błędów, które psują dostarczanie (10 minut na poprawki)

Dwa rekordy SPF. Po zmianie dostawcy ktoś dopisuje nowy rekord v=spf1 obok starego. Norma SPF (RFC 7208) każe wtedy zwrócić błąd trwały i SPF nie przechodzi wcale, dla żadnego z serwerów. Rekord ma być jeden, a wszystkie mechanizmy stoją w nim obok siebie: v=spf1 include:_spf.isbre.pl include:spf.dostawca-newslettera.pl ~all.

~all czy -all. Dla listu spoza listy -all daje wynik fail, a ~all łagodniejszy softfail. Co zrobić z listem, decyduje serwer odbiorcy. Gdy domena ma DMARC, to on powinien decydować o losie listu. Surowe -all potrafi go wyprzedzić: część serwerów odrzuca list już na etapie SPF, zanim sprawdzi podpis DKIM, a to boli przy przekierowaniach. W domenach klientów stawiamy więc ~all. Własną domenę isbre.pl, z której wysyłają wyłącznie nasze serwery, trzymamy na -all.

Limit 10 odwołań do DNS. Każde include, a, mx, ptr, exists i redirect, które serwer odbiorcy musi sprawdzić, liczy się do limitu, i to łącznie z tymi w rekordach dostawców dołączonych przez include. Gdy sprawdzanie dojdzie do jedenastego, kończy się błędem trwałym, czyli SPF przestaje działać w całości. Nasze include zużywa jedno odwołanie z dziesięciu, bo w środku stoją same adresy IP. Za to trzech, czterech dostawców marketingowych z rozbudowanymi rekordami potrafi zjeść limit bez reszty.

DKIM zgubiony po zmianie dostawcy. Poczta przeszła gdzie indziej, a nowy dostawca nie ma włączonego podpisu albo jego rekord …._domainkey nie trafił do DNS. Bywa i odwrotnie: strefę przeniesiono do nowego DNS bez starego klucza. Odbiorca widzi wtedy dkim=none albo dkim=fail. Nasz serwer przed podpisaniem sprawdza w DNS, czy klucz pod selektorem pasuje do prywatnego. Gdy rekordu brakuje, list wychodzi bez podpisu, a nie z podpisem, którego nikt nie zweryfikuje.

DMARC od razu na reject. Kusi, bo brzmi najbezpieczniej. Jeśli jednak sklep, program do faktur albo system newslettera wysyła jako Twoja domena i nie przechodzi dla niej ani SPF, ani DKIM, od tej chwili jego listy są odrzucane. Zwrotka trafia na adres zwrotny ustawiony w tym systemie, często nie do Ciebie, więc bywa, że dowiadujesz się dopiero wtedy, gdy klient zadzwoni, że nie ma faktury. Rozsądna kolejność to p=none z raportami (rua) przez kilka tygodni, potem quarantine, na końcu reject.

Co ustawia za Ciebie panel

Gdy prowadzimy DNS Twojej domeny (kupiłeś ją u nas albo wskazałeś u rejestratora parę serwerów nazw z panelu), strefa od razu dostaje MX, SPF, DKIM i DMARC w postaci pokazanej wyżej. Klucz DKIM powstaje razem ze strefą. Podpis stawiamy na poczcie wysłanej ze skrzynki po zalogowaniu: z programu pocztowego, z poczty w przeglądarce albo przez SMTP z hasłem skrzynki.

W strefach klientów DMARC ma od początku p=quarantine, a nie p=none. Poczta z naszych skrzynek ten test przechodzi, bo ma nasz SPF i podpis DKIM Twojej domeny. Strefa nie wie natomiast, z jakich usług zewnętrznych korzystasz Ty, i o tym jest następna sekcja.

Rekordy ustawione przez nas są zarządzane. Przy każdym panel wyjaśnia jednym zdaniem, po co jest i co się stanie po zmianie, a zapis odblokowuje zaznaczenie „Wiem, co robię”. Jeśli coś pójdzie nie tak, ustawienia przywrócisz jednym kliknięciem, pojedynczo albo całym kompletem.

A jeśli DNS zostaje u dotychczasowego dostawcy? Wtedy rekordy poczty wpisujesz tam sam. Zanim założysz skrzynki, napisz na bok@isbre.pl, a ustalimy komplet rekordów dla Twojej domeny. Pilnuj też, żeby rekord SPF był dokładnie jeden. Więcej o obu drogach piszemy w pomocy, w części o domenach.

Co zostaje po Twojej stronie

Wszystko, co wysyła pocztę jako Twoja domena, a nie przechodzi przez nasze skrzynki. Najczęściej jest to system newslettera, CRM albo program do faktur. Większość takich dostawców podaje w swoim panelu rekord DKIM (zwykle CNAME albo TXT pod jego selektorem), część także include do SPF albo własną domenę zwrotną w Twojej domenie. Rekord DKIM dodajesz jako zwykły rekord własny i nie koliduje on z naszym selektorem rdc1. SPF ustawiasz dla tej nazwy, której dostawca używa jako adresu zwrotnego. Gdy jest to Twoja główna domena, include dopisujesz do naszego rekordu SPF, nie obok niego. Gdy adresem zwrotnym jest poddomena, np. bounce.example.pl, rekord SPF zakładasz dla tej nazwy według jego instrukcji. Najważniejszy i tak jest podpis DKIM Twojej domeny: zwykle przetrwa też przekierowanie, a SPF nie. Jeśli usługa nie przejdzie dla Twojej domeny ani SPF, ani DKIM, przy p=quarantine jej listy trafią do spamu.

Nie masz pewności, co jeszcze wysyła w Twoim imieniu? Na czas sprawdzania ustaw w DMARC p=none i dopisz do rua własny adres, np. rua=mailto:dmarc@isbre.pl,mailto:raporty@example.pl. Raporty przychodzą zwykle raz na dobę jako załączniki XML i pokażą serwery, które wysyłały jako Twoja domena do skrzynek u dostawców wysyłających raporty (m.in. Gmail, Yahoo, Outlook). Gdy wszystkie wypadną na PASS, wróć do quarantine.

Osobna sprawa to formularz kontaktowy i powiadomienia ze sklepu na Twojej stronie. Wtyczki WordPressa domyślnie wysyłają przez funkcję mail() w PHP i nie musisz tego zmieniać: taki list podpisujemy kluczem DKIM Twojej domeny, jeśli adres nadawcy (pole From) jest w domenie z Twojego konta, a rekord DKIM tej domeny jest w DNS. DMARC patrzy wtedy na podpis i list przechodzi. Uważaj na formularze, które wpisują w From adres odwiedzającego, na przykład jan@gmail.com. Takiego listu nie podpiszemy, bo nie jest z Twojej domeny, a serwer odbiorcy uzna go za podszywanie się pod gmail.com: w najlepszym razie trafi do spamu. Ustaw w formularzu nadawcę w swojej domenie (np. formularz@example.pl, najlepiej jako istniejący adres albo alias), a adres odwiedzającego wpisz w Reply-To. Odpowiedź i tak trafi do niego jednym kliknięciem.

Masz skrzynki u nas albo dopiero się zastanawiasz? Zakładka Poczta w panelu ma adresy serwerów i porty, a pakiety samej poczty opisujemy na stronie Poczta. Jeśli po tych dwudziestu minutach nagłówek dalej pokazuje fail, wyślij nam go na bok@isbre.pl. Wystarczy sam nagłówek Authentication-Results, treść listu zostaw u siebie.