Wiadomości z formularza trafiają do spamu? SPF, DKIM i DMARC wyjaśnione po ludzku

Klient wypełnia formularz na stronie, a wiadomość nie dociera do skrzynki firmy albo ląduje w folderze ze spamem. Oferta wysłana z adresu firmowego pozostaje bez odpowiedzi, bo odbiorca nigdy jej nie zobaczył. W większości takich spraw przyczyna jest ta sama: serwer odbiorcy nie potrafi potwierdzić, że wiadomość naprawdę wysłała firma, do której należy domena.

Do takiego potwierdzenia służą trzy wpisy w ustawieniach domeny: SPF, DKIM i DMARC. Brzmią technicznie, ale ich dodanie sprowadza się do wklejenia kilku wierszy tekstu w panelu, w którym zarządza się domeną. Ta instrukcja jest przeznaczona dla właścicieli firm i osób opiekujących się stroną, które nie zajmują się pocztą zawodowo.

Po lekturze czytelnik będzie umiał sprawdzić w Gmailu, jak jego wiadomości przechodzą kontrolę, dodać brakujące rekordy w strefie DNS, przestawić WordPressa na wysyłkę przez SMTP i ocenić, czy naprawa zadziałała. Osobno opisuję błędy, przez które po zmianach poczta potrafi działać gorzej niż przedtem.

Po czym poznać, że wiadomości z domeny trafiają do spamu, i skąd to się bierze?

Objawy rzadko są oczywiste, bo nadawca nie dostaje żadnego komunikatu o tym, że jego wiadomość trafiła do spamu. Najczęściej sprawa wychodzi na jaw przypadkiem: klient dzwoni z pytaniem, dlaczego nikt nie odpowiedział na zapytanie, albo kontrahent znajduje fakturę w folderze „Spam” po kilku dniach.

Na problem z uwierzytelnianiem poczty wskazują przede wszystkim takie sygnały:

• powiadomienia z formularza kontaktowego przychodzą nieregularnie albo wcale, choć formularz wyświetla potwierdzenie wysłania,
• odbiorcy korzystający z Gmaila lub poczty Microsoftu znajdują wiadomości firmy w spamie, a odbiorcy z innych skrzynek dostają je normalnie,
• w Gmailu obok nazwy nadawcy widać znak zapytania, co według pomocy Gmaila oznacza wiadomość nieuwierzytelnioną,
• wracają zwroty z informacją, że wiadomość została odrzucona z powodu zasad uwierzytelniania domeny nadawcy,
• klienci sklepu nie dostają potwierdzeń zamówień ani wiadomości z odnośnikiem do ustawienia hasła.

Przyczyn jest kilka i zwykle występują razem. Pierwsza to brak rekordów SPF, DKIM i DMARC albo rekordy ustawione dawno temu, przed zmianą dostawcy poczty. Druga dotyczy stron na WordPressie: system domyślnie wysyła wiadomości przez funkcję pocztową serwera WWW, czyli z maszyny, która nie jest serwerem poczty firmy i nie podpisuje wiadomości kluczem domeny.

Trzecia przyczyna tkwi w ustawieniach samego formularza. Wiele formularzy wstawia w polu nadawcy adres osoby, która wypełniła formularz. Dla serwera odbiorcy wygląda to jak podszywanie się: wiadomość twierdzi, że pochodzi z cudzej domeny, a przychodzi z serwera strony firmy. Im ostrzejsze zasady ma domena klienta, tym pewniej taka wiadomość zostanie odrzucona.

Czwarta grupa przyczyn nie ma związku z rekordami: zła opinia adresu IP współdzielonego serwera, wysyłka do osób, które jej nie chciały, treść przypominająca niechcianą reklamę. Uwierzytelnianie należy jednak naprawić w pierwszej kolejności, bo bez niego nie da się wiarygodnie ocenić pozostałych czynników.

Czym są SPF, DKIM i DMARC, wyjaśnione prostymi słowami

Poczta elektroniczna powstała w czasach, gdy nikt nie sprawdzał, kto naprawdę jest nadawcą. W polu „Od” da się wpisać dowolny adres, tak jak na kopercie da się napisać dowolnego nadawcę. SPF, DKIM i DMARC to trzy uzupełniające się sposoby, dzięki którym serwer odbiorcy może odróżnić prawdziwą wiadomość firmy od podróbki.

SPF, czyli lista serwerów upoważnionych do wysyłki

SPF to jeden wiersz tekstu zapisany w ustawieniach domeny. Zawiera listę serwerów, które mają prawo wysyłać pocztę w imieniu tej domeny. Serwer odbiorcy sprawdza, z jakiego adresu IP przyszła wiadomość, i porównuje go z listą. Można to porównać do listy osób upoważnionych do odbioru przesyłek w imieniu firmy: kogo nie ma na liście, ten budzi podejrzenia.

DKIM, czyli podpis na każdej wiadomości

DKIM działa jak pieczęć. Serwer poczty dodaje do każdej wychodzącej wiadomości podpis utworzony kluczem prywatnym, którego nikt poza nim nie zna. W ustawieniach domeny publikuje się drugi klucz z pary, publiczny. Serwer odbiorcy pobiera klucz publiczny i sprawdza, czy podpis się zgadza oraz czy wiadomość nie została po drodze zmieniona.

DMARC, czyli instrukcja dla serwera odbiorcy

DMARC łączy oba mechanizmy i odpowiada na pytanie, co zrobić z wiadomością, która nie przeszła kontroli: dostarczyć ją normalnie, skierować do spamu czy odrzucić. Wymaga też zgodności domen. Wiadomość przechodzi DMARC, gdy domena widoczna w polu „Od” zgadza się z domeną potwierdzoną przez SPF albo z domeną z podpisu DKIM. Wystarczy jedna z tych dwóch zgodności.

Czego Google wymaga od nadawców poczty?

Google opisuje swoje oczekiwania w pomocy, na stronie „Wskazówki dla nadawców e-maili”. Wymagania dotyczą wiadomości wysyłanych na osobiste konta Gmail i są podzielone na dwie grupy. Pierwsza, „Wymagania dotyczące wszystkich nadawców”, obejmuje każdą firmę, także taką, która wysyła kilka wiadomości dziennie.

Według tej strony każdy nadawca powinien uwierzytelniać pocztę za pomocą SPF lub DKIM, przesyłać wiadomości połączeniem zabezpieczonym protokołem TLS, mieć poprawne rekordy DNS serwera wysyłającego, w tym rekord odwrotny PTR, oraz nie podszywać się pod cudze adresy w nagłówku „Od”. Google oczekuje także, że wskaźnik spamu widoczny w narzędziu Postmaster Tools pozostanie poniżej 0,3%.

Druga grupa, „Wymagania dotyczące wysyłania co najmniej 5000 wiadomości dziennie”, jest ostrzejsza. Tacy nadawcy muszą mieć jednocześnie SPF, DKIM i DMARC, przy czym zasada DMARC może mieć wartość none. Domena w polu „Od” musi być zgodna z domeną SPF lub DKIM, a wiadomości marketingowe muszą umożliwiać rezygnację z subskrypcji jednym kliknięciem.

Mała firma formalnie mieści się w pierwszej grupie. Radzę jednak ustawić wszystkie trzy mechanizmy niezależnie od skali wysyłki. Wymagania skrzynek pocztowych zaostrzają się, a komplet rekordów chroni też przed podszywaniem się pod firmę. Kto prowadzi wysyłki do listy odbiorców, znajdzie więcej wskazówek we wpisie o tym, jak zwiększyć sprzedaż dzięki e-mail marketingowi.

Jak sprawdzić obecny stan w nagłówkach wiadomości w Gmailu?

Przed zmianami trzeba ustalić, co działa, a co nie. Najprościej wysłać wiadomość na konto Gmail i odczytać jej pełne nagłówki. Do testu potrzebna jest skrzynka Gmail, do której jest dostęp, najlepiej prywatna albo należąca do współpracownika. Test należy wykonać dwa razy: raz z programu pocztowego firmy, raz przez formularz na stronie, bo te dwie drogi często prowadzą przez różne serwery.

1. Z adresu firmowego wysyła się zwykłą wiadomość na adres w Gmailu. Następnie wypełnia się formularz na stronie tak, aby powiadomienie lub automatyczna odpowiedź również trafiły na ten adres.
2. W Gmailu na komputerze otwiera się otrzymaną wiadomość. Jeśli jej nie ma w odebranych, trzeba zajrzeć do folderu „Spam”.
3. Obok przycisku „Odpowiedz” należy kliknąć „Więcej”, a potem „Pokaż oryginał”.
4. W nowym oknie pojawi się pełny nagłówek. W górnej części Gmail wyświetla podsumowanie z wierszami SPF, DKIM i DMARC oraz wynikiem każdej kontroli, na przykład PASS albo FAIL.
5. Niżej, w treści nagłówka, znajduje się wiersz zaczynający się od Authentication-Results. Zawiera te same wyniki w postaci spf=pass, dkim=pass i dmarc=pass razem z nazwami domen, których dotyczyła kontrola.
6. Przycisk „Kopiuj do schowka” pozwala skopiować nagłówek. Można go wkleić do narzędzia „Nagłówek wiadomości” z zestawu Narzędzi administracyjnych Google i kliknąć „Analizuj powyższy nagłówek”, aby zobaczyć drogę wiadomości w czytelniejszej postaci.

Jak czytać wyniki?

Wynik pass oznacza, że kontrola się powiodła. Brak wiersza SPF albo DKIM w podsumowaniu zwykle znaczy, że domena nie ma danego rekordu lub wiadomości w ogóle nie są podpisywane. Według pomocy Google wyniki softfail, fail, neutral, temperror i permerror przy SPF wymagają reakcji: najczęściej serwera, który wysłał wiadomość, nie ma w rekordzie SPF albo sam rekord zawiera błąd.

Trzeba też spojrzeć na nazwy domen podane przy wynikach. Częsta sytuacja przy formularzach: SPF ma wynik pass, ale dla domeny firmy hostingowej, a nie dla domeny firmy. Taka wiadomość nie spełnia warunku zgodności i DMARC kończy się wynikiem fail. To znak, że wysyłka ze strony wymaga przestawienia na SMTP, co opisuję w dalszej części.

Kto na tym etapie woli nie zajmować się tym samodzielnie, może po prostu zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Chętnie przejmę sprawę: sprawdzę nagłówki wiadomości, dodam rekordy SPF, DKIM i DMARC i przetestuję dostarczanie.

Gdzie znajduje się strefa DNS domeny i co przygotować przed zmianami?

Wszystkie trzy rekordy dodaje się w strefie DNS domeny, czyli w zbiorze ustawień, który mówi internetowi, gdzie znajduje się strona i poczta firmy. Strefa nie zawsze jest tam, gdzie kupiono domenę. Obsługuje ją ta firma, na której serwery nazw wskazuje domena: może to być rejestrator, firma hostingowa albo zewnętrzna usługa DNS. Rekord dodany w niewłaściwym panelu nie zadziała, choć panel go zapisze.

Jeśli nie wiadomo, kto obsługuje strefę, należy sprawdzić w panelu rejestratora, jakie serwery nazw są przypisane do domeny. Ich adresy zwykle zdradzają nazwę firmy. W jej panelu trzeba odszukać część nazwaną najczęściej „Strefa DNS”, „Rekordy DNS” lub „Zarządzanie DNS”.

Zanim cokolwiek zostanie zmienione, radzę przygotować trzy rzeczy. Bez nich łatwo o rekord, który wygląda poprawnie, a pomija część poczty.

• Kopię obecnej strefy: zrzut ekranu albo eksport wszystkich rekordów, szczególnie typu TXT i MX. W razie pomyłki pozwoli wrócić do stanu wyjściowego.
• Listę wszystkich miejsc, z których wychodzi poczta z domeny: skrzynki pracowników, strona i sklep, system do wysyłek do listy odbiorców, program do faktur, system rezerwacji, narzędzie do obsługi zgłoszeń.
• Instrukcje dostawców tych usług. Każdy dostawca poczty podaje w swojej pomocy wartość, którą należy dopisać do SPF, oraz sposób uzyskania klucza DKIM.

Uwaga dla firm po zmianie hostingu lub serwerów nazw: rekordy pocztowe nie przenoszą się same. To jeden z punktów, które opisuję przy okazji tego, jak przeprowadzić migrację strony bez utraty pozycji w Google. Poczta, która po przenosinach nagle zaczęła trafiać do spamu, to zwykle skutek pominięcia SPF albo DKIM w nowej strefie.

Jak dodać rekord SPF w strefie DNS?

Rekord SPF to rekord typu TXT, którego wartość zaczyna się od v=spf1. Dalej następują upoważnieni nadawcy, a na końcu znajduje się wskazówka, jak traktować pozostałych. Najprostszy rekord dla firmy, która całą pocztę wysyła przez Google Workspace, pochodzi wprost z pomocy Google:

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

Element include: oznacza: „upoważniam serwery wymienione w rekordzie SPF tej domeny”. Każdy dostawca poczty ma własną wartość do wstawienia po dwukropku i podaje ją w swojej pomocy. Element ip4: upoważnia pojedynczy adres IP, na przykład serwer strony. Rekord firmy, która korzysta z Google Workspace, wysyła też pocztę z własnego serwera i używa zewnętrznego systemu wysyłkowego, może wyglądać tak:

v=spf1 ip4:203.0.113.15 include:_spf.google.com include:servers.mcsv.net ~all

Adres IP w przykładzie jest umowny i służy tylko pokazaniu składni. Wartość include:servers.mcsv.net to według tabeli w pomocy Google wpis dla usługi Mailchimp. W rekordzie firmy muszą się znaleźć wartości jej własnych dostawców.

1. Otwarcie strefy DNS domeny i przejrzenie rekordów typu TXT. Trzeba ustalić, czy istnieje już rekord zaczynający się od v=spf1.
2. Jeśli taki rekord istnieje, należy go edytować, a nie dodawać drugi. Brakujących nadawców dopisuje się przed końcowym ~all.
3. Jeśli rekordu nie ma, należy dodać nowy rekord. W polu typu wybiera się „TXT”.
4. W polu nazwy, opisywanym w panelach jako „Host”, „Nazwa” lub „Nazwa hosta”, wpisuje się znak @ albo zostawia pole puste, zależnie od panelu. Oznacza to domenę główną.
5. W polu wartości wkleja się cały rekord w jednym wierszu. Niektóre panele wymagają ujęcia wartości w cudzysłów, co powinna wyjaśniać pomoc dostawcy.
6. Zapisanie zmian i ponowne otwarcie strefy, aby potwierdzić, że widnieje w niej dokładnie jeden rekord SPF.

Jeden rekord SPF na domenę

Pomoc Google stwierdza wprost, że domena może mieć tylko jeden rekord SPF. Dwa rekordy zaczynające się od v=spf1 powodują błąd kontroli i wiadomości mogą trafiać do spamu, nawet jeśli każdy z rekordów osobno jest poprawny. Gdy nowy dostawca prosi o „dodanie rekordu SPF”, w praktyce chodzi o dopisanie jego wartości do rekordu, który już istnieje. Subdomena używana do wysyłki potrzebuje natomiast własnego rekordu.

Limit dziesięciu zapytań DNS

Rekord SPF nie powinien wymagać więcej niż 10 zapytań DNS. Liczą się elementy include, a, mx, exists, ptr oraz redirect, a także zapytania zagnieżdżone: jeśli wskazany dostawca ma w swoim rekordzie kolejne trzy include, wszystkie obciążają limit domeny firmy. Elementy ip4 i ip6 nie zużywają limitu.

Po przekroczeniu limitu kontrola SPF kończy się błędem. Rozwiązaniem jest porządek: usunięcie dostawców, z których firma już nie korzysta, i powtórzonych wpisów. Liczbę zapytań pokazuje narzędzie Check MX z zestawu Narzędzi administracyjnych Google. Pomoc Google podaje jeszcze jedno ograniczenie: rekord SPF może mieć najwyżej 255 znaków.

Zakończenie ~all czy -all?

Końcówka ~all mówi serwerom odbiorców, że wiadomości od nadawców spoza listy są podejrzane, ale zwykle zostaną przyjęte. Końcówka -all pozwala je odrzucać. Na początek radzę ~all. Ostrzejszy wariant ma sens dopiero wtedy, gdy raporty DMARC potwierdzą, że lista nadawców jest pełna.

Jak dodać klucz DKIM od dostawcy poczty?

Klucza DKIM nie układa się samodzielnie. Parę kluczy tworzy dostawca poczty, a właściciel domeny dostaje gotowe dane do wklejenia w strefie: nazwę rekordu i jego wartość. W Google Workspace służy do tego strona „Uwierzytelniaj pocztę e-mail” w ustawieniach Gmaila w konsoli administracyjnej. U firm hostingowych podobna opcja znajduje się zwykle w panelu poczty, przy ustawieniach domeny.

Nazwa rekordu składa się z selektora, czyli etykiety klucza, oraz stałej końcówki ._domainkey. Google Workspace domyślnie używa selektora google, więc rekord wygląda tak:

Typ:     TXT
Nazwa:   google._domainkey
Wartość: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC... (długi ciąg znaków od dostawcy)

1. W panelu dostawcy poczty należy odszukać ustawienia DKIM dla domeny i utworzyć klucz. Jeśli panel pozwala wybrać długość, lepiej wskazać dłuższy klucz. Google wymaga co najmniej 1024 bitów.
2. Skopiowanie nazwy rekordu oraz całej wartości, bez pomijania żadnego znaku.
3. W strefie DNS dodaje się nowy rekord typu „TXT”. W polu nazwy wkleja się nazwę podaną przez dostawcę, w polu wartości cały klucz publiczny.
4. Zapisanie zmian. Wielu dostawców wymaga jeszcze włączenia podpisywania po swojej stronie. W Google Workspace służy do tego przycisk „Rozpocznij uwierzytelnianie”.
5. Powtórzenie czynności dla każdej usługi, która wysyła pocztę w imieniu domeny. Każda ma własny selektor i własny klucz, a rekordów DKIM może być w strefie wiele.

Trzy uwagi praktyczne. Większość paneli sama dopisuje nazwę domeny do nazwy rekordu, więc wpisanie pełnej nazwy z domeną na końcu tworzy błędny rekord z podwojoną domeną. Część dostawców zamiast rekordu TXT podaje rekordy typu CNAME, które wskazują na klucz przechowywany u nich. Wtedy należy dodać dokładnie taki typ, jaki podano. Wreszcie, przy bardzo długich kluczach niektóre panele wymagają podziału wartości na części, co opisuje pomoc danej firmy.

Jak wdrożyć DMARC stopniowo, od p=none do ostrzejszych zasad?

DMARC dodaje się na końcu. Google zaleca, aby SPF i DKIM działały co najmniej 48 godzin przed jego ustawieniem. Rekord DMARC to także rekord typu TXT, ale o stałej nazwie _dmarc. Jego wartość zaczyna się od v=DMARC1, po czym następuje zasada oznaczona literą p. Te dwa elementy muszą stać na początku, w tej kolejności.

Zasada może mieć trzy wartości. Przy p=none wiadomości są dostarczane jak dotąd, a właściciel domeny otrzymuje raporty. Przy p=quarantine wiadomości, które nie przeszły kontroli, trafiają do spamu. Przy p=reject serwer odbiorcy odrzuca je i nigdy nie docierają do adresata. Rekord na początek wygląda tak:

Typ:     TXT
Nazwa:   _dmarc
Wartość: v=DMARC1; p=none; rua=mailto:dmarc@nazwafirmy.pl

Element rua wskazuje adres, na który serwery odbiorców wysyłają raporty zbiorcze. Raportów bywa dużo, dlatego Google zaleca osobną skrzynkę lub grupę przeznaczoną wyłącznie do tego celu. Adres powinien należeć do tej samej domeny, w której stoi rekord. Wysyłanie raportów na adres w innej domenie wymaga dodatkowego rekordu po stronie tamtej domeny.

1. Założenie skrzynki na raporty, na przykład dmarc@ w domenie firmy.
2. Dodanie w strefie DNS rekordu typu „TXT” o nazwie _dmarc z zasadą p=none i adresem w elemencie rua. Podobnie jak przy DKIM trzeba sprawdzić, czy panel sam dopisuje nazwę domeny.
3. Obserwowanie raportów przez co najmniej tydzień. Według zaleceń Google tyle zwykle wystarcza, aby raporty objęły wszystkie strumienie poczty firmy.
4. Wyszukanie w raportach nadawców, którzy wysyłają w imieniu domeny i nie przechodzą kontroli. Każdego prawdziwego nadawcę trzeba dopisać do SPF i objąć podpisem DKIM.
5. Gdy raporty nie pokazują już problemów z prawdziwą pocztą firmy, zmienia się zasadę na p=quarantine dla części wiadomości, korzystając z elementu pct.
6. Stopniowe podnoszenie wartości pct aż do objęcia całej poczty, a na końcu ewentualne przejście na p=reject.

Kolejne etapy, zgodne z przykładami w pomocy Google, wyglądają następująco:

v=DMARC1; p=none; rua=mailto:dmarc@nazwafirmy.pl
v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@nazwafirmy.pl
v=DMARC1; p=reject; rua=mailto:dmarc@nazwafirmy.pl

W strefie ma się znajdować zawsze tylko jeden z tych wierszy: przy przejściu na kolejny etap edytuje się istniejący rekord. Element pct określa, jaki odsetek wiadomości podlega zasadzie, i przyjmuje liczbę całkowitą od 1 do 100. Bez niego zasada dotyczy całej poczty.

Jak czytać raporty DMARC?

Raporty przychodzą jako załączniki w formacie XML, zwykle raz na dobę od każdego większego dostawcy skrzynek. W surowej postaci są mało czytelne, ale da się z nich odczytać trzy rzeczy: adres IP serwera wysyłającego, liczbę wiadomości oraz wynik SPF i DKIM. Istnieją usługi, które zamieniają te pliki na czytelne zestawienia. Przy małej firmie zwykle wystarcza przejrzenie raportów z pierwszych tygodni.

Jak ustawić wysyłkę z WordPressa przez SMTP zamiast funkcji serwera?

WordPress wysyła powiadomienia za pomocą funkcji wp_mail, która domyślnie przekazuje wiadomość mechanizmowi pocztowemu serwera WWW. Taka wiadomość wychodzi z adresu IP hostingu, często współdzielonego z setkami innych stron, i nie ma podpisu DKIM domeny firmy. Dokumentacja WordPressa zaznacza też, że pozytywny wynik tej funkcji nie oznacza dostarczenia wiadomości, a jedynie brak błędu przy przekazaniu jej dalej.

Rozwiązaniem jest wysyłka przez SMTP: strona loguje się do prawdziwej skrzynki firmowej albo do usługi wysyłkowej i wysyła wiadomość tak, jak robi to program pocztowy. Wiadomość przechodzi wtedy przez serwer wymieniony w SPF i dostaje podpis DKIM. Służą do tego wtyczki, na przykład WP Mail SMTP albo FluentSMTP. Wybór konkretnej ma mniejsze znaczenie niż poprawne dane.

1. Założenie osobnej skrzynki do wysyłki ze strony, na przykład formularz@ w domenie firmy. Osobna skrzynka ułatwia zmianę hasła i przegląd wysłanych wiadomości.
2. Odszukanie w pomocy dostawcy poczty danych serwera poczty wychodzącej: adresu serwera SMTP, portu i rodzaju szyfrowania. Najczęściej jest to port 587 z szyfrowaniem STARTTLS albo port 465 z szyfrowaniem SSL/TLS.
3. Instalacja wybranej wtyczki SMTP w panelu WordPressa i wybranie w jej ustawieniach wysyłki przez własny serwer SMTP albo przez gotowe połączenie z dostawcą poczty, jeśli wtyczka takie oferuje.
4. Wpisanie adresu serwera, portu, rodzaju szyfrowania, nazwy użytkownika i hasła skrzynki. Uwierzytelnianie musi być włączone.
5. Ustawienie adresu nadawcy na adres tej samej skrzynki i włączenie opcji wymuszającej ten adres dla wszystkich wiadomości ze strony, jeśli wtyczka ją ma.
6. Wysłanie wiadomości próbnej z ekranu testowego wtyczki na adres w Gmailu i sprawdzenie jej nagłówków przez „Pokaż oryginał”.

Adres nadawcy w formularzu kontaktowym

Po przestawieniu wysyłki trzeba jeszcze otworzyć ustawienia samego formularza. W polu nadawcy powinien stać adres z domeny firmy, ten sam, którego używa wtyczka SMTP. Adres osoby wypełniającej formularz należy przenieść do pola „Odpowiedz do”, w ustawieniach często zapisywanego jako „Reply-To”. Dzięki temu kliknięcie „Odpowiedz” nadal kieruje odpowiedź do klienta, a wiadomość nie udaje, że pochodzi z jego domeny.

Hasło do skrzynki zapisane w ustawieniach wtyczki jest tak bezpieczne, jak cała strona. Dlatego lepiej użyć osobnej skrzynki niż skrzynki właściciela firmy, a tam, gdzie dostawca to umożliwia, hasła utworzonego specjalnie dla aplikacji. Zbędne wtyczki pocztowe pozostawione po wcześniejszych próbach należy wyłączyć, bo potrafią przejmować wysyłkę. Przy okazji warto przejrzeć pozostałe dodatki, o czym piszę we wpisie o tym, jak sprawdzić, co spowalnia WordPressa.

Ile trwa propagacja zmian i jak wykonać test po zmianie?

Zmiany w strefie DNS nie są widoczne od razu na całym świecie. Google podaje, że zanim uwierzytelnianie SPF lub DKIM zacznie działać, może minąć do 48 godzin. W praktyce nowe rekordy często widać znacznie szybciej, ale nie należy wyciągać wniosków z testu wykonanego kilka minut po zapisaniu zmian. O tym, jak długo serwery pamiętają starą wartość, decyduje czas TTL ustawiony przy rekordzie.

Test po zmianie przebiega tak samo jak sprawdzenie stanu wyjściowego: wiadomość z programu pocztowego, wiadomość z formularza, a przy sklepie także wiadomość systemowa, na przykład potwierdzenie zamówienia próbnego. Google zwraca uwagę, że podpisu DKIM nie sprawdzi się, wysyłając wiadomość do samego siebie. Odbiorcą powinna być inna skrzynka w Gmailu.

Naprawa zadziałała, jeśli w oknie „Pokaż oryginał” wszystkie trzy wiersze mają wynik pass, a przy SPF i DKIM widnieje domena firmy, nie domena hostingu. Rekordy można dodatkowo skontrolować narzędziem Check MX z zestawu Narzędzi administracyjnych Google, które pokazuje między innymi liczbę zapytań w rekordzie SPF i obecność rekordu DMARC.

Jakich błędów unikać i co zrobić, gdy poczta nadal trafia do spamu?

Większość kłopotów po wdrożeniu wynika z kilku powtarzalnych pomyłek. Każdą da się wykryć w strefie DNS albo w nagłówkach wiadomości.

• Dwa rekordy SPF. Powstają, gdy nowy dostawca prosi o dodanie rekordu, a stary nie zostaje usunięty. Oba wpisy trzeba połączyć w jeden.
• Brak dostawcy w SPF. Poczta pracowników przechodzi kontrolę, a faktury z programu księgowego lub wysyłki do listy odbiorców już nie, bo ich serwerów nie ma w rekordzie.
• Zasada p=reject ustawiona od razu. Jeśli jakikolwiek prawdziwy nadawca został pominięty, jego wiadomości przestaną docierać do odbiorców, a firma dowie się o tym od klientów. Bezpieczna droga prowadzi przez p=none i raporty.
• Rekord dodany w panelu, który nie obsługuje strefy, albo z podwojoną nazwą domeny w nazwie rekordu.
• Klucz DKIM dodany w strefie, ale podpisywanie niewłączone po stronie dostawcy poczty.
• Rekord DMARC bez adresu do raportów. Zasada działa, ale właściciel domeny nie widzi, co się dzieje z jego pocztą.

Gdy rekordy są poprawne, a wiadomości nadal trafiają do spamu, zostają przyczyny związane z opinią nadawcy i treścią. Przy wysyłce do większej liczby odbiorców należy założyć konto w Postmaster Tools i obserwować wskaźnik spamu. Pomaga usunięcie z listy adresów, które nie reagują, wysyłanie wyłącznie do osób, które wyraziły zgodę, oraz widoczny odnośnik do rezygnacji.

W pojedynczych wiadomościach szkodzą skracane odnośniki, załączniki w nietypowych formatach i tematy pisane wielkimi literami. Jeśli strona stoi na współdzielonym serwerze o złej opinii, przejście na SMTP zwykle rozwiązuje sprawę, bo wiadomości przestają wychodzić z adresu IP hostingu. Kupowanie baz adresów ani zmienianie domen w celu ominięcia filtrów nie jest drogą, którą mogę polecić: narusza zasady skrzynek pocztowych i trwale psuje opinię nadawcy.

Najczęstsze pytania

Czy mała firma, która wysyła kilkanaście wiadomości dziennie, potrzebuje wszystkich trzech rekordów?

Google wymaga od każdego nadawcy co najmniej SPF lub DKIM, a kompletu trzech mechanizmów dopiero przy wysyłce co najmniej 5000 wiadomości dziennie. Mimo to radzę ustawić wszystkie trzy. Zajmuje to niewiele czasu, poprawia dostarczalność także u innych dostawców skrzynek i utrudnia podszywanie się pod firmę.

Czy zmiana rekordów TXT może zepsuć stronę albo odbieranie poczty?

Rekordy SPF, DKIM i DMARC nie wpływają na działanie strony ani na odbieranie wiadomości, bo za te sprawy odpowiadają inne rekordy, między innymi A i MX. Ryzyko dotyczy wyłącznie poczty wychodzącej: błędny SPF albo zbyt ostry DMARC mogą pogorszyć jej dostarczanie. Dlatego przed zmianami należy zachować kopię strefy i nie ruszać rekordów innych typów.

Skąd wziąć wartość include dla własnego dostawcy poczty?

Z pomocy tego dostawcy. Każda firma hostingowa i każda usługa wysyłkowa publikuje gotowy wpis do SPF oraz instrukcję uzyskania klucza DKIM, zwykle pod hasłem „SPF” lub „uwierzytelnianie domeny”. Nie należy przepisywać wartości z przypadkowych stron ani z przykładów w tym tekście, bo upoważnienie niewłaściwych serwerów jest równie szkodliwe jak pominięcie właściwych.

Dlaczego wiadomości przekazywane dalej nie przechodzą SPF?

Przy automatycznym przekazywaniu wiadomość dociera do ostatecznego odbiorcy z serwera pośredniczącego, którego nie ma w rekordzie SPF pierwotnego nadawcy. Pomoc Google potwierdza, że poprawny rekord SPF nie gwarantuje wyniku pass po przekazaniu. Podpis DKIM zwykle taką drogę wytrzymuje, co jest kolejnym powodem, by ustawić oba mechanizmy.

Czy wystarczy sama wtyczka SMTP, bez zmian w DNS?

Nie zawsze. Wtyczka sprawia, że wiadomości wychodzą przez serwer poczty firmy, ale to rekordy w strefie mówią odbiorcom, że ten serwer ma do tego prawo i jakim kluczem podpisuje. Jeśli dostawca poczty ustawił SPF i DKIM przy zakładaniu usługi, wtyczka może wystarczyć. Rozstrzyga test przez „Pokaż oryginał”.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zupełnie zrozumiałe. Opisane czynności wymagają spokoju i kilku wolnych godzin, a w firmie zwykle brakuje jednego i drugiego. Chętnie zrobię to od początku do końca: sprawdzę nagłówki wiadomości, dodam rekordy SPF, DKIM i DMARC i przetestuję dostarczanie.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i w kilku zdaniach opisać sprawę. Odpowiadam osobiście i od razu mówię, co da się zrobić.