Poczta z Twojej domeny

Bot może pisać do Twoich klientów pocztą elektroniczną — z adresu w Twojej domenie, np. noreply@example.com. Samą wiadomość wysyła jednak nasz serwer. Dlatego przed pierwszą wysyłką trzeba raz dodać trzy rekordy do DNS Twojej domeny. Poniżej: po co to jest, co dokładnie dodać i co dzieje się dalej.

Dlaczego bez rekordów DNS poczta nie dojdzie

Spójrz na to oczami odbiorcy — Gmail, Outlook albo serwer pocztowy Twojego klienta. Przychodzi wiadomość, która twierdzi, że jest z Twojej domeny, ale przychodzi z serwera, który do Twojej domeny nie należy. To dokładnie tak wygląda podszywanie się: tak działa phishing.

Odbiorca może odróżnić jedno od drugiego tylko w jeden sposób — pytając samą domenę: „czy ten nadawca naprawdę działa w Twoim imieniu?". Odpowiedź publikujesz w DNS swojej domeny, bo DNS to jedyne miejsce, którym rozporządzasz wyłącznie Ty — i dlatego jedyne, któremu odbiorca wierzy.

Dopóki tej odpowiedzi nie ma, rzetelny serwer pocztowy musi uznać wiadomość za podejrzaną. W najlepszym razie trafi do spamu, w najgorszym zostanie odrzucona, a odbiorca nigdy się o niej nie dowie.

Trzy rekordy poniżej to więc nie formalność ani „ptaszek" w interfejsie. One Twoim zezwoleniem.

Trzy rekordy i co robi każdy

DKIM — podpis dowodzący autentyczności

DKIM to podpis kryptograficzny dołączany do każdej wychodzącej wiadomości. Platforma generuje dla Twojej domeny parę kluczy: prywatny zostaje u nas i podpisuje pocztę, publiczny publikujesz w DNS. Odbiorca bierze klucz publiczny z Twojego DNS i sprawdza podpis. Zgadza się — wiadomość wysłał ten, kto ma klucz prywatny, a treść nie została po drodze podmieniona.

Bez DKIM: nie ma czym sprawdzić podpisu. Wiadomość wygląda na niepodpisaną i niewiarygodną, a żadne inne ustawienie tego nie nadrobi. DKIM jest najważniejszy z trzech.

SPF — jakie serwery mogą wysyłać w Twoim imieniu

SPF odpowiada na inne pytanie: z jakich serwerów w ogóle dopuszczalna jest poczta z tej domeny. To lista źródeł — serwery pocztowe Twojego hostingu, używane już usługi wysyłkowe oraz, żeby bot mógł pisać, nasze serwery wysyłkowe.

Bez SPF: wiadomość przychodzi z serwera, którego Twoja domena „nie zna". Dla filtra to klasyczna oznaka podszycia i dokłada się do wszystkich innych podejrzeń.

DMARC — co odbiorca ma zrobić, gdy weryfikacje zawiodą

DKIM i SPF odpowiadają na pytanie „czy wiadomość jest prawdziwa". DMARC odpowiada na kolejne: co robić, jeśli nie. To Twoja instrukcja dla odbiorcy — nic nie robić i tylko przysłać raport, wrzucić do spamu albo odrzucić. DMARC to również adres, na który odbiorcy wysyłają zbiorcze raporty o poczcie w Twoim imieniu, łącznie z cudzymi próbami podszycia.

Zacznij od najłagodniejszej polityki, „tylko raporty". Zaostrzaj później, gdy upewnisz się, że wszyscy Twoi prawdziwi nadawcy (księgowość, CRM, newslettery, ten bot) przechodzą weryfikacje. Zbyt wcześnie włączona ostra polityka zaczyna wycinać Twoją własną pocztę.

Bez DMARC: każdy odbiorca decyduje po swojemu, a Ty nigdy się nie dowiesz, co dzieje się z pocztą wysyłaną w Twoim imieniu.

Jakie rekordy dodać

Najpierw dodaj domenę w panelu: sekcja Email„Sending domains" → przycisk „Add domain". Okno ma trzy pola: samą domenę (na przykład shop.example.com), część lokalną adresu (to, co przed @, zwykle noreply) oraz nazwę nadawcy, którą odbiorca zobaczy zamiast adresu. Po zapisaniu na ekranie pojawią się Twoje rekordy DNS.

Wszystkie trzy to rekordy TXT w DNS Twojej domeny. Dodaje się je tam, gdzie zarządzasz domeną: w panelu rejestratora albo u dostawcy DNS.

Wartości poniżej używają example.com jako przykładu — podstaw swoją. Dokładne wartości dla Twojej domeny pokazane są w panelu na karcie domeny — kopiuj je stamtąd, zwłaszcza DKIM: jego wartość zawiera Twój własny klucz publiczny, inny dla każdej domeny i nie do wzięcia z dokumentacji.

Na ekranie każdy rekord rozbity jest na dwa osobne pola — „Host" i „Value" — każde z własnym przyciskiem „Copy". Kopiuj je pojedynczo do odpowiednich pól u swojego dostawcy DNS: obie części nie wkleją się jednym kawałkiem.

TypNazwa rekordu (host)Wartość
TXTmybot._domainkey.example.comv=DKIM1; k=rsa; p= i dalej długi klucz z panelu
TXTexample.com (korzeń domeny)v=spf1 include:esp.getmybot.dev ~all
TXT_dmarc.example.comv=DMARC1; p=none; rua=mailto:dmarc@example.com

Dwie rzeczy, na których potyka się najwięcej osób:

  • Wiele paneli samo dokleja domenę do nazwy. Jeśli w polu nazwy widnieje już „.example.com", wpisz tylko mybot._domainkey, a nie pełną nazwę — inaczej wyjdzie mybot._domainkey.example.com.example.com.
  • Wartość DKIM jest długa i nie może zawierać złamań linii ani spacji wewnątrz klucza. Kopiuj ją przyciskiem, nie zaznaczeniem myszą.

Jeśli domena ma już rekord SPF

Domena może mieć tylko jeden rekord SPF. Jeśli już wysyłasz pocztę przez hosting, CRM albo inną usługę newsletterową, taki rekord istnieje. Nie dodawaj drugiego — dopisz do istniejącego kolejny include, przed końcowym ~all:

v=spf1 include:spf.twojdostawca.pl include:esp.getmybot.dev ~all

Dwa rekordy SPF w domenie to ten sam błąd co żaden: weryfikacja nie przechodzi, bo odbiorca nie wie, któremu z nich wierzyć.

Uwaga: „pokrycie" przez cudzy rekord nie wystarcza. Nawet jeśli Twój obecny dostawca zawiera nas we własnym SPF, nasz include musi stać bezpośrednio w Twoim rekordzie — dlaczego, wyjaśnia niżej rozdział o weryfikacji domeny.

Dlaczego w SPF include, a nie adres IP

Najczęstszy błąd to wpisanie adresu IP zauważonego w nagłówku wiadomości albo na forum. Nie rób tak.

include:esp.getmybot.dev to odsyłacz do naszej własnej, utrzymywanej przez nas listy serwerów wysyłkowych. Dziś kryje się za tą nazwą jeden serwer. Jutro może być ich więcej, mogą się przenieść albo zostać wymienione. Kiedy to nastąpi, zaktualizujemy listę u siebie — a Twój rekord będzie działał dalej, bez żadnych zmian z Twojej strony. O to właśnie chodzi: adres zmienia się w jednym miejscu, a nie w DNS każdego klienta.

Wpisany ręcznie adres IP po prostu przestaje wtedy być prawdziwy. Poczta zaczyna oblewać SPF bez żadnego ostrzeżenia — ani błędu w panelu, ani powiadomienia. Dowiesz się od klientów, którzy „nic nie dostali".

Wpisz dokładnie include:esp.getmybot.dev i nic do tego nie dodawaj.

Weryfikacja domeny

Weryfikacja domeny to sytuacja, w której platforma sama zagląda do DNS Twojej domeny i potwierdza, że wszystkie trzy rekordy są w porządku. Gdy wszystkie trzy przejdą, domena dostaje status zweryfikowana i wysyłka jest dozwolona. Dopóki któryś nie przejdzie, domena czeka.

Sprawdzane jest coś więcej niż „rekord istnieje":

RekordCo jest naprawdę sprawdzane
DKIMRekord jest opublikowany i zawiera właśnie Twój klucz publiczny. Cudzy albo stary DKIM z poprzedniego klucza nie przejdzie.
SPFRekord istnieje i zawiera bezpośrednio include:esp.getmybot.dev. Podobnie wyglądające wartości w rodzaju include:esp.getmybot.dev.obca-domena.example się nie liczą.
DMARCRekord jest opublikowany i zaczyna się od v=DMARC1. Sama polityka (p=, rua=) nie jest sprawdzana — to Twoja decyzja, a nie zgoda dla nas.

Dlaczego DMARC sprawdzany jest łagodniej: mówi odbiorcom, co zrobić z wynikami DKIM i SPF, ale nie daje nam prawa do wysyłki w Twoim imieniu. To prawo dają wyłącznie dwa pierwsze rekordy i oba są w pełni sprawdzane co do treści.

Cudzy include się nie liczy

include:esp.getmybot.dev musi znaleźć się w Twoim własnym rekordzie SPF. Jeśli Twój SPF zawiera zewnętrznego dostawcę, którego rekord z kolei zawiera nas, weryfikacja tego nie uzna: platforma nie rozwija łańcuchów cudzych include. Powód jest prosty — dzięki temu odpowiedź na pytanie „czy właśnie ta domena nas upoważniła" pozostaje jednoznaczna.

W praktyce: nawet jeśli masz pewność, że jesteś „pokryty przez dostawcę", dopisz nasz include bezpośrednio do siebie. Dokładnie to samo mówi sam ekran w objaśnieniu rekordu SPF: jeśli domena ma już rekord SPF, dodaj do niego wartość include:..., zamiast zastępować cały rekord, bo domena może wysyłać pocztę nie tylko przez nas. Ta podpowiedź wisi tam zawsze, a nie pojawia się dopiero po nieudanej weryfikacji.

DNS nie aktualizuje się natychmiast. Po zapisaniu rekordów u rejestratora muszą one rozejść się po serwerach nazw: zwykle minuty, czasem godziny, rzadziej do doby. Zależy to od dostawcy i od TTL. To normalne i nie zależy od nas.

Nie trzeba jednak czekać biernie. Platforma sama sprawdza oczekujące domeny raz na godzinę, ale na karcie domeny jest przycisk „Verify now" — ta sama weryfikacja uruchomiona natychmiast, z wynikiem od razu na ekranie. Użyj go zaraz po zapisaniu rekordów: przy literówce dowiesz się w sekundę, a nie po godzinie. Można go wywoływać dowolnie wiele razy.

Status domeny widać na karcie: „Pending verification", „Verified" albo „Not verified". Dopóki domena nie jest zweryfikowana, na karcie wisi też ostrzeżenie „Sending from this domain is disabled until it is verified."*

Wynik to nie samo „nie powiodło się". Każdy z trzech rekordów ma na ekranie własny status — „Passing", „Not passing" lub „Not checked yet" — i własny wiersz z wyjaśnieniem, co jest nie tak.

Dla SPF ekran rozróżnia dwie sytuacje i jest to najważniejsze rozróżnienie w całej procedurze:

  • Domena nie ma żadnego rekordu SPF. Opublikuj go, wartością z tabeli powyżej.
  • Rekord SPF istnieje, ale nie zawiera naszego include. Dopisz include do istniejącego rekordu: nie twórz drugiego i nie zastępuj go w całości. Ten sam komunikat wprost obejmuje też przypadek łańcucha: jeśli include dociera do nas wyłącznie przez rekord SPF innego dostawcy, to się nie liczy — łańcuchy nie są rozwijane.

Drugi przypadek to najbardziej mylący moment całej procedury: rekord już jest, właśnie sam go przeczytałeś, a weryfikacja i tak odmawia. Komunikat błędu mówi teraz dokładnie to samo co stale widoczna podpowiedź obok rekordu — dopisz nasz include do tego, co już masz.

Jeśli weryfikacja nie przechodzi:

  1. Przeczytaj, który z trzech rekordów ma „Not passing" i co mówi jego wyjaśnienie, a potem działaj według niego.
  2. Upewnij się, że rekordy naprawdę są opublikowane — wiele paneli wymaga osobnego „zastosuj zmiany".
  3. Sprawdź nazwę rekordu pod kątem zdublowanej domeny (patrz wyżej).
  4. Sprawdź, że rekord SPF jest jeden i że nasz include stoi w tym właśnie rekordzie.
  5. Odczekaj i sprawdź ponownie: zmiana mogła jeszcze się nie rozejść.

Do czasu weryfikacji wysyłka nie działa — tak ma być

Dopóki domena nie jest zweryfikowana, wiadomości nie są wysyłane. Nie „wysyłane i lądują w spamie" — nie wychodzą w ogóle: próba kończy się błędem o niezweryfikowanej domenie, widocznym w dzienniku.

To celowe i nie jest awarią. Poczta z domeny, która sama za siebie nie poręczyła, zamienia się w zgłoszenia spamu, a zgłoszenia psują reputację infrastruktury wysyłkowej wspólnej dla wszystkich klientów platformy. Taniej jest nie wysłać wiadomości niż wysłać ją i przez pół roku wygrzebywać się z czarnych list. Stąd zakaz, a nie ostrzeżenie.

Widząc taki błąd, sprawdź rekordy DNS i naciśnij weryfikację, zanim napiszesz do wsparcia. W zdecydowanej większości przypadków to literówka w nazwie rekordu.

Wypisania, skargi i odrzucenia

Trzy zasady, które zaskakują, jeśli się o nich nie wie.

Każda wiadomość marketingowa ma wypisanie jednym kliknięciem. Platforma sama dodaje link wypisu w stopce oraz nagłówki techniczne, na podstawie których program pocztowy rysuje przycisk „Wypisz się" obok adresu nadawcy. Nie da się tego usunąć — ani ustawieniem, ani składem wiadomości. Wypisanie działa natychmiast, bez otwierania wiadomości i bez kroku potwierdzenia. Gmail i inni duzi dostawcy wymagają tego od nadawców masowych: wiadomość bez tego trafia do spamu na pewno.

Wypisanie jest ostateczne i nie da się go cofnąć z interfejsu. Wypisany adres nie dostaje już poczty od tego bota. Nie ma przycisku „przywróć" ani obejścia przez ponowny import listy: wypisania nigdy nie odwraca się ponad głową człowieka. Wrócić może tylko on sam, zostawiając adres w Twoim formularzu zapisu.

Jest przypadek jeszcze ostrzejszy: jeśli ktoś nacisnął w programie pocztowym „To jest spam", adres zostaje zamknięty na zawsze. Nie otworzy go nawet ponowny zapis przez Twój formularz — bo wiemy już, jak skończyła się poprzednia próba, a pisanie na takie adresy najszybciej niszczy reputację domeny. Adresy zamknięte ręcznie na żądanie prawne zachowują się tak samo.

Trwałe odrzucenie zamyka adres na stałe. Jeśli serwer odbiorcy odpowie, że takiej skrzynki nie ma, adres zostaje oznaczony jako niedoręczalny i wypada z kolejnych wysyłek. To nie jest stan tymczasowy: dalsze dobijanie się do nieistniejącej skrzynki to najkrótsza droga do filtrów antyspamowych, razem ze wszystkimi pozostałymi adresami.

Odrzucenia tymczasowe (pełna skrzynka, chwilowo niedostępny serwer) nie zamykają adresu — wysyłka trwa dalej.

Dlaczego otwarcia są zaniżone

W statystykach poczty jest wskaźnik otwarć i zawsze jest mniejszy od rzeczywistego. To nie błąd liczenia, tylko sposób, w jaki otwarcia w ogóle się mierzy.

Otwarcie zapisuje się wtedy, gdy program pocztowy przy wyświetlaniu wiadomości pobiera z serwera maleńki obrazek śledzący. Współczesne programy domyślnie nie pobierają zdalnych obrazków; a te, które pobierają (Apple Mail i podobne mechanizmy prywatności), robią to z wyprzedzeniem za wszystkich, także za tych, którzy wiadomości nigdy nie otworzyli. W pierwszym przypadku otwarcie ginie, w drugim przypisuje się je komuś, kogo nie było. Dokładniej policzyć otwarć poczty się nie da — ani nam, ani nikomu innemu.

Dlatego w interfejsie obok liczby jest zastrzeżenie: to dolna granica, a nie dokładna wartość. Używaj jej do porównywania wiadomości między sobą, gdzie ten sam błąd dotyczy wszystkich, ale nie jako odpowiedzi na pytanie „ile osób przeczytało wiadomość".

Jeśli potrzebujesz wiarygodnej miary zaangażowania, patrz na „Link clicks". Kliknięcie w link to realne działanie realnego człowieka; nikt nie wykonuje go za niego z wyprzedzeniem. „Delivered", „Unsubscribes", „Complaints" i „Bounces" też liczone są dokładnie: zgłaszają je serwery pocztowe, a nie obrazek w wiadomości. Wszystko to jest w bloku „Sending stats" na tym samym ekranie Email.

Co dalej