Błędy rekordu SPF: jak je naprawić krok po kroku

Cichy błąd, przez który maile „nie dochodzą”

Przypomnienia o płatnościach wyszły pierwszego dnia miesiąca. Tydzień później trzech klientów twierdzi, że nic nie dostało, a wiadomości leżą w spamie. W samej treści nie było nic podejrzanego. Problem siedział w DNS: błędny rekord SPF mówił Gmailowi i Outlookowi, że Twojej domenie nie można ufać.

Błędy SPF zdarzają się często, bo rekord wygląda prosto, przez lata edytują go różne osoby, a kiedy się psuje, nikt nie dostaje powiadomienia. Poniżej znajdziesz najczęstsze pomyłki, każdą z błędnym i poprawionym przykładem.

SPF w dwóch zdaniach

SPF (Sender Policy Framework) to rekord TXT w DNS Twojej domeny, który wskazuje, które serwery mogą wysyłać pocztę w jej imieniu. Serwer odbiorcy porównuje IP nadawcy z tą listą i zapisuje wynik: pass, fail, softfail, neutral albo error.

Jeden szczegół wyjaśnia połowę nieporozumień: SPF jest sprawdzany dla domeny z Return-Path (nadawcy kopertowego), a nie dla adresu „Od”, który widzi odbiorca.

Krok 1: sprawdź, co masz teraz

Zanim cokolwiek zmienisz, wpisz domenę w nasz darmowy tester rekordu SPF. Pokaże rekord, wszystkie mechanizmy, liczbę wykorzystanych zapytań DNS (z 10 dozwolonych) i ostrzeżenia o problemach opisanych niżej. W terminalu wystarczy dig TXT example.com +short, żeby zobaczyć wszystkie rekordy TXT.

Przy okazji uruchom test kondycji domeny. Sprawdza za jednym razem SPF, DKIM, DMARC, MX i czarne listy, więc od razu zobaczysz, czy SPF to jedyny problem.

8 najczęstszych błędów SPF i jak je naprawić

W przykładach example.com to Twoja domena, a nazwy typu _spf.crm-example.com zastępują narzędzia, z których korzystasz. Właściwe wartości weźmiesz z dokumentacji każdego dostawcy.

1. Dwa rekordy SPF w jednej domenie

Instrukcja nowego narzędzia mówi „dodaj ten rekord TXT”, więc ktoś dodaje go obok starego. Domena może mieć dokładnie jeden rekord zaczynający się od v=spf1. Przy dwóch serwery zwracają PermError, a wiele z nich traktuje to jak porażkę.

• Źle: v=spf1 include:_spf.google.com ~all i drugi rekord v=spf1 include:_spf.crm-example.com ~all
• Dobrze: v=spf1 include:_spf.google.com include:_spf.crm-example.com ~all

Połącz mechanizmy w jeden rekord, a drugi usuń. Inne rekordy TXT, na przykład kody weryfikacyjne, mogą zostać.

2. Więcej niż 10 zapytań DNS (PermError)

Każde include, a, mx, ptr, exists i redirect to jedno zapytanie DNS. Liczą się też zapytania zagnieżdżone wewnątrz include. Limit wynosi 10. Przekroczysz go choćby o jedno, a SPF zwróci PermError dla każdej wiadomości. ip4, ip6 i all nic nie kosztują.

• Źle: v=spf1 a mx include:_spf.google.com include:spf.protection.outlook.com include:_spf.crm-example.com include:mail.helpdesk-example.com include:servers.old-mailer.net ~all
• Dobrze: v=spf1 ip4:203.0.113.10 include:_spf.google.com include:_spf.crm-example.com ~all

Żeby zejść poniżej 10, usuń narzędzia, z których już nie korzystasz. Wyrzuć a i mx, jeśli te serwery nie wysyłają poczty, a jeśli wysyłają, wpisz ich IP przez ip4:. Rozważ też przeniesienie automatycznej wysyłki na subdomenę z własnym rekordem i własnym limitem 10 zapytań. Uważaj na „spłaszczanie” include'ów do surowych adresów IP: działa tylko do czasu, gdy dostawca zmieni adresy.

3. Brak include dla usługi, która wysyła maile

Rekord obejmuje Google Workspace, ale program do faktur też wysyła z @example.com i nie ma go na liście. SPF nie przechodzi tylko dla tych maili, więc trudno to zauważyć.

• Źle: v=spf1 include:_spf.google.com ~all
• Dobrze: v=spf1 include:_spf.google.com include:_spf.invoicing-example.com ~all

Spisz wszystko, co wysyła maile z Twojej domeny: skrzynkę, CRM, helpdesk, fakturowanie, formularze na stronie, platformę do wysyłki e-maili. Potem zajrzyj do dokumentacji każdego dostawcy. Wiele usług ma własny lub dedykowany Return-Path i zamiast include potrzebuje rekordu CNAME albo DKIM. Niepotrzebny include tylko zużyje Ci zapytania.

4. ~all, -all czy ?all: złe zakończenie

• -all (fail): serwery spoza listy nie mają prawa wysyłać. Najbardziej rygorystyczna opcja.
• ~all (softfail): serwery spoza listy są podejrzane. Najczęstszy wybór.
• ?all (neutral): brak zdania, czyli w praktyce ochrona taka jak bez rekordu.

• Źle: v=spf1 include:_spf.google.com ?all
• Dobrze: v=spf1 include:_spf.google.com ~all

Używaj ~all, dopóki potwierdzasz wszystkich nadawców, a -all dopiero wtedy, gdy lista jest kompletna. Przy egzekwowanym DMARC to on wykonuje większość pracy, dlatego wiele dobrze utrzymanych domen zostaje przy ~all.

5. +all, czyli SPF, który nic nie daje

+all oznacza: „każdy serwer w internecie może wysyłać jako ta domena”. Czasem ktoś dodaje to jako szybką łatkę, gdy prawdziwe maile nie przechodzą. Efekt? Zapraszasz do podszywania się pod Twoją domenę, a filtry antyspamowe dobrze o tym wiedzą.

• Źle: v=spf1 +all
• Dobrze: v=spf1 include:_spf.google.com include:_spf.crm-example.com ~all

Zamień to jeszcze dziś, a potem znajdź nadawcę, który nie przechodził SPF (zwykle chodzi o błąd nr 3).

6. Literówki w składni

Parsery SPF są bezlitosne. Jeden zły znak potrafi unieważnić cały rekord albo po cichu pominąć mechanizm.

• Źle: v=spf1 ipv4:203.0.113.10 include: _spf.google.com ~all include:_spf.crm-example.com
• Dobrze: v=spf1 ip4:203.0.113.10 include:_spf.google.com include:_spf.crm-example.com ~all

Typowe wpadki to ipv4: zamiast ip4:, spacja po dwukropku, mechanizmy po all (ignorowane), „drukarskie” cudzysłowy wklejone z Worda i błędne zakresy typu /33.

7. Za długi rekord

Pojedynczy ciąg w rekordzie TXT może mieć najwyżej 255 znaków. Dłuższy panel DNS odrzuci albo opublikuje w uszkodzonej formie.

• Źle: jeden ciąg na 300 znaków z dwudziestoma osobnymi adresami ip4:
• Dobrze: v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/26 include:_spf.google.com ~all

Zamiast pojedynczych IP używaj zakresów CIDR. Jeśli rekord nadal jest długi, podziel go na kilka ciągów w cudzysłowach w tym samym rekordzie TXT: "v=spf1 ip4:203.0.113.0/24 " "include:_spf.google.com ~all". Ciągi są sklejane bez separatora, więc zostaw spację na końcu pierwszego.

8. Zapomniane subdomeny

SPF się nie dziedziczy. Rekord na example.com nie działa dla billing.example.com.

• Źle: SPF tylko na example.com, choć przypomnienia wychodzą z billing.example.com jako nadawcą kopertowym
• Dobrze: na billing.example.com: v=spf1 include:_spf.invoicing-example.com ~all

Domeny, które w ogóle nie wysyłają poczty (stare marki, domeny zaparkowane), powinny mieć v=spf1 -all, żeby spamerzy nie mogli się pod nie podszywać.

Po poprawce: szybka checklista

1. Dokładnie jeden rekord TXT zaczyna się od v=spf1.
2. Tester SPF pokazuje najwyżej 10 zapytań, najlepiej z zapasem.
3. Każda usługa wysyłająca z Twojej domeny jest w include albo ma własny Return-Path.
4. Rekord kończy się na ~all lub -all.
5. Subdomeny, z których wysyłasz, mają własne rekordy.

Potem wyślij test na adres w Gmailu, wybierz „Pokaż oryginał” i poszukaj SPF: PASS.

Sam SPF to za mało

SPF nie sprawdza adresu „Od”, który widzi odbiorca, i często nie przechodzi, gdy wiadomość zostanie przekierowana. Dlatego od lutego 2024 Gmail i Yahoo wymagają od masowych nadawców SPF, DKIM i DMARC. Następny krok to najczęstsze błędy konfiguracji DKIM, a potem przejście z DMARC p=none na p=reject.

Jak pomaga MailerBit

MailerBit wymaga weryfikacji własnej domeny przed wysłaniem pierwszej kampanii. W ustawieniach domeny dostajesz dokładne rekordy DNS do dodania (klucz DKIM i CNAME dla własnego Return-Path) z przyciskami do kopiowania, a gdy rekordy zaczną działać, potwierdzasz je jednym kliknięciem „Sprawdź weryfikację”.

Własny Return-Path kieruje zwroty przez Twoją domenę, a SPF jest sprawdzany dla tej subdomeny Return-Path. Dlatego konfiguracja nie wymaga dopisywania include do głównego rekordu SPF i nie zużywa limitu zapytań. Maile są podpisane Twoją domeną, więc budujesz własną reputację domeny; nowe domeny przechodzą automatyczne rozgrzewanie, a konta z odsetkiem zwrotów powyżej 5% lub zgłoszeń spamu powyżej 0,1% są automatycznie wstrzymywane. Testery SPF, DKIM, DMARC, MX, czarnych list i kondycji domeny są darmowe i nie wymagają konta.

Jeśli Twoje przypomnienia o płatnościach i zestawienia dla klientów lądują w spamie, zacznij od naprawy SPF. Potem rozpocznij 7-dniowy darmowy okres próbny MailerBit, zweryfikuj domenę i wysyłaj każdemu klientowi jego własne kwoty i terminy z uwierzytelnionej domeny.