SPF, DKIM i DMARC: twoja domena wysyła pocztę, nawet jeśli ty nie

Dlaczego każda domena strony potrzebuje rekordów uwierzytelniania poczty, jak SPF, DKIM i DMARC współpracują i jak dojść do polityki reject bez utraty własnych wiadomości.

Infrastruktura · Opublikowano: 30 września 2026 · 6 min czytania · Анна Ковалёва

„Nie wysyłamy maili” to jedna z najczęstszych odpowiedzi, gdy skan wykrywa brak rekordu SPF albo DMARC. I zupełnie nie w tym rzecz. Każdy w internecie może wpisać twoją domenę w pole From. O tym, czy Gmail albo Outlook mu uwierzy, decyduje kilka rekordów TXT w twoim DNS — a jeśli ich nie ma, nikt nie wypowiada się w imieniu twojej domeny.

Dlaczego właściciel strony powinien się tym przejąć

Podszywanie się i phishing. Bez polityki DMARC serwery odbiorcze nie dostają od ciebie żadnej instrukcji, co robić z wiadomościami, które udają twoją domenę i nie przechodzą weryfikacji. Fałszywe faktury i maile „reset hasła” od support@twojadomena są tanie w wysyłce, a zaufanie do prawdziwej strony podkopują skutecznie.

Twoje własne powiadomienia. Formularze kontaktowe, potwierdzenia zamówień, resetowanie hasła — nawet „statyczna” strona zwykle coś wysyła. Obsługa formularza, która wywołuje PHP mail() prosto z serwera WWW i wstawia w From adres odwiedzającego, oblewa wszystkie testy i ląduje w spamie albo nie dociera wcale.

Wymagania dostawców poczty. Od lutego 2024 roku Gmail i Yahoo wymagają od wszystkich nadawców SPF lub DKIM, a od nadawców masowych — obu, do tego rekordu DMARC (minimum p=none) i domeny w From zgodnej z przynajmniej jednym z nich. Inni dostawcy idą w tę samą stronę. Wiadomości niespełniające reguł są coraz częściej odrzucane, a nie tylko filtrowane.

SPF: kto może wysyłać

SPF to rekord TXT na samej domenie z listą serwerów uprawnionych do wysyłki w jej imieniu:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Na czym najczęściej się potykamy:

• Tylko jeden rekord. Dwa rekordy TXT zaczynające się od v=spf1 to nie „obowiązują oba”, tylko trwały błąd — odbiorcy uznają SPF za zepsuty. Połącz je w jeden.
• Dziesięć zapytań DNS. include, a, mx, exists, redirect i ptr kosztują po jednym zapytaniu, zagnieżdżone include też się liczą. Powyżej dziesięciu weryfikacja kończy się błędem. Zanim dodasz nowe usługi, usuń te, z których już nie korzystasz.
• Zakończenie ma znaczenie. -all oznacza, że wszyscy pozostali nie przechodzą; ~all to miękkie odrzucenie, rozsądne, dopóki kompletujesz listę nadawców; +all upoważnia cały internet i jest gorsze niż brak rekordu.

SPF sprawdza nadawcę z koperty (adres zwrotny), a nie nagłówek From, który widzi użytkownik. Dlatego sam SPF nie wystarcza.

DKIM: podpis na każdej wiadomości

DKIM podpisuje wychodzące wiadomości kluczem prywatnym, a klucz publiczny jest publikowany w DNS pod selektorem:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Każda usługa wysyłająca — dostawca skrzynek, narzędzie do newslettera, API poczty transakcyjnej — daje własny selektor i klucz albo CNAME na rekord, którym sama zarządza. Używaj 2048-bitowych kluczy RSA, jeśli dostawca na to pozwala, i usuwaj selektory usług, z których zrezygnowałeś. W przeciwieństwie do SPF podpis DKIM przetrwa przekazanie dalej, więc z tych dwóch mechanizmów jest bardziej niezawodny.

DMARC: polityka, która spina całość

DMARC mieszka pod _dmarc i mówi odbiorcom, co zrobić z wiadomością, która nie przeszła weryfikacji, oraz dokąd wysyłać raporty:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Wiadomość przechodzi DMARC, gdy SPF lub DKIM przeszły i domena, dla której przeszły, jest zgodna (aligned) z domeną w From. SPF zaliczony dla domeny zwrotnej twojego dostawcy poczty się nie liczy; podpis DKIM z d=example.com — tak.

Wdrażaj etapami:

1. p=none z raportami rua. Nic nie jest blokowane; dostajesz codzienne zbiorcze raporty XML o wszystkich serwerach wysyłających jako twoja domena. Użyj parsera albo usługi do raportów zamiast czytać XML ręcznie.
2. Napraw każdego prawowitego nadawcę, który nie przechodzi: dodaj go do SPF, skonfiguruj DKIM, upewnij się, że From używa twojej domeny.
3. p=quarantine — opcjonalnie najpierw z pct=, by objąć polityką tylko część niezaliczonych wiadomości.
4. p=reject. Podrobione wiadomości są odrzucane już na wejściu.

p=none to tryb obserwacji, a nie ochrona. Tkwienie w nim latami oznacza, że zebrałeś dane i nic z nimi nie zrobiłeś.

Domeny, które nie wysyłają poczty

Domeny zaparkowane, domeny służące tylko do przekierowań i stare nazwy marek to ulubione cele podszywania się, bo nikt ich nie pilnuje. Zamknij je całkowicie:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject"

Pusty rekord MX (example.net. MX 0 .) dodatkowo informuje inne serwery, że domena nie przyjmuje poczty.

Jak to sprawdzić

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s1._domainkey.example.com

Pierwsze polecenie powinno zwrócić dokładnie jeden ciąg v=spf1. Do DKIM potrzebny jest selektor: otwórz wysłaną przez siebie wiadomość, znajdź nagłówek DKIM-Signature i weź wartość s=. Nagłówek Authentication-Results odebranej wiadomości pokazuje werdykty SPF, DKIM i DMARC w jednym miejscu.

Raport SiteScan sprawdza za ciebie część DNS: oznacza brak rekordu SPF, kilka rekordów SPF, zbyt liberalne +all, brak rekordu DMARC oraz politykę DMARC pozostawioną na p=none. DKIM nie sprawdza — selektorów nie da się wykryć przez DNS bez znajomości ich nazw — więc zweryfikuj go na prawdziwej wiadomości.

Lista kontrolna

1. Dokładnie jeden rekord SPF, poniżej dziesięciu zapytań, zakończony ~all lub -all.
2. DKIM skonfigurowany dla każdej usługi wysyłającej jako twoja domena.
3. Powiadomienia strony idą przez uwierzytelnionego dostawcę, From to twoja domena, odwiedzający w Reply-To.
4. DMARC istnieje, raporty rua docierają, a polityka zmierza od p=none do p=reject.
5. Domeny, które nie wysyłają poczty, mają v=spf1 -all i p=reject.