SPF, DKIM i DMARC: jak chronić domenę przed podszywaniem

Protokół SMTP sam z siebie nie sprawdza, kto wysyła wiadomość. Adres w polu „Od” może wpisać każdy. SPF, DKIM i DMARC to trzy rekordy DNS, które pozwalają odbiorcy zweryfikować, czy poczta z twoją domeną w adresie naprawdę pochodzi od ciebie. Ten przewodnik opiera się na dokumentach RFC i oficjalnych wymaganiach Google, Yahoo i Microsoft.

1. Po co trzy mechanizmy

Każdy mechanizm sprawdza co innego. SPF weryfikuje, czy serwer, który łączy się z odbiorcą, jest uprawniony do wysyłki w imieniu domeny z koperty SMTP. DKIM weryfikuje podpis kryptograficzny wiadomości i to, że treść nie zmieniła się po drodze. Żaden z nich nie sprawdza jednak adresu w polu „Od”, który widzi użytkownik.

Tę lukę zamyka DMARC. Wymaga, by domena zweryfikowana przez SPF albo DKIM była zgodna (aligned) z domeną w polu „Od”. Domena, która publikuje politykę DMARC, mówi też odbiorcom, co mają zrobić z wiadomościami, które nie przejdą tej kontroli, i prosi o raporty.

2. SPF: lista uprawnionych serwerów

SPF opisuje RFC 7208. Rekord publikujesz wyłącznie jako rekord TXT. Dedykowany typ rekordu SPF został porzucony (sekcja 3.1). Rekord wymienia mechanizmy, a na końcu określa, co zrobić z resztą serwerów.

example.com.  IN TXT  "v=spf1 mx include:_spf.example.net -all"

Przykład dopuszcza serwery MX domeny i serwery dostawcy wskazane przez include. Kwalifikator przed mechanizmem określa wynik: + to pass (domyślny), - to fail, ~ to softfail, a ? to neutral (sekcja 4.6.2).

Dwie zasady powodują najwięcej błędów. Domena może mieć tylko jeden rekord SPF, bo kilka rekordów daje wynik permerror (sekcja 4.5). Mechanizmy include, a, mx, ptr i exists oraz modyfikator redirect mogą łącznie wywołać najwyżej 10 zapytań DNS (sekcja 4.6.4). Ta sama sekcja zaleca też limit dwóch „pustych” zapytań, czyli takich, które nie zwracają rekordu albo kończą się błędem nieistniejącej nazwy. Przekroczenie go również daje permerror, a mało kto o nim wie.

3. DKIM: podpis w nagłówku, klucz w DNS

DKIM opisuje RFC 6376. Serwer wysyłający dodaje nagłówek DKIM-Signature z podpisem wybranych nagłówków i treści. Tag d= wskazuje domenę, a s= selektor. Odbiorca pobiera klucz publiczny z rekordu TXT o nazwie <selektor>._domainkey.<domena> (sekcja 3.6.2.1).

s2026._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Pusty tag p= oznacza klucz unieważniony. Wymagania kryptograficzne zaostrzył RFC 8301. Algorytmu rsa-sha1 nie wolno używać ani do podpisywania, ani do weryfikacji, a podpisujący muszą używać rsa-sha256. Klucze RSA muszą mieć co najmniej 1024 bity, a zalecane są co najmniej 2048 bitów. Selektor pozwala opublikować nowy klucz obok starego i wymienić je bez przerwy w podpisywaniu.

4. DMARC: zgodność domen i polityka

Rekord DMARC publikujesz jako TXT pod nazwą _dmarc.<domena>. Musi zaczynać się od v=DMARC1. Tag p= określa politykę: none oznacza tylko obserwację, quarantine traktowanie wiadomości jako podejrzanej, zwykle przeniesienie do spamu, a reject odrzucenie. Tag sp= ustawia politykę dla subdomen, a rua= wskazuje adres na raporty zbiorcze.

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

Zgodność domen ma dwa tryby, ustawiane tagami adkim= i aspf=. W trybie relaxed, domyślnym, wystarczy ta sama domena organizacyjna, więc mail.example.com pasuje do example.com. W trybie strict nazwy muszą być identyczne. Raporty zbiorcze to pliki XML od odbiorców. Pokazują, które serwery wysyłały pocztę z twoją domeną i z jakim wynikiem SPF i DKIM.

5. DMARC w 2026 roku: RFC 9989

W maju 2026 IETF opublikował RFC 9989, który zastępuje RFC 7489. Raporty opisują teraz osobne dokumenty, RFC 9990 dla raportów zbiorczych i RFC 9991 dla raportów o błędach. Poprzedni DMARC miał status informacyjny. Nowy trafił na ścieżkę standardów internetowych.

Zmiany w rekordzie opisuje dodatek C do RFC 9989:

• usunięto tag pct, dotąd używany do stosowania polityki tylko do części wiadomości, oraz tagi rf i ri dotyczące formatu i częstotliwości raportów,
• nowy tag t=y włącza tryb testowy, w którym odbiorca stosuje politykę o poziom łagodniejszą, czyli none zamiast quarantine i quarantine zamiast reject,
• nowy tag np ustawia politykę dla subdomen, które nie istnieją w DNS, a psd oznacza domenę sufiksu publicznego,
• domenę organizacyjną odbiorca ustala teraz przeszukując drzewo DNS, najwyżej w 8 zapytaniach, zamiast korzystać z publicznej listy sufiksów (Public Suffix List).

Tag p= jest teraz zalecany, a nie wymagany. Rekord bez niego jest traktowany tak, jakby miał p=none. Jeśli twój rekord zawiera pct, usuń go i do stopniowego wdrażania używaj t=y.

6. Czego wymagają Google, Yahoo i Microsoft

Od 1 lutego 2024 Google wymaga od wszystkich nadawców do Gmaila co najmniej SPF albo DKIM. Nadawcy masowi, czyli wysyłający blisko 5000 wiadomości dziennie na prywatne konta Gmail, potrzebują SPF, DKIM i DMARC z polityką co najmniej p=none. Domena w polu „Od” musi być zgodna z domeną SPF albo DKIM. Ich wiadomości marketingowe muszą umożliwiać rezygnację z subskrypcji jednym kliknięciem, a wskaźnik spamu musi być niższy niż 0,3%. Od listopada 2025 Gmail zaostrza egzekwowanie, aż do odrzucania wiadomości.

Yahoo wprowadziło od lutego 2024 zasady w tym samym kształcie i dopuszcza zgodność w trybie relaxed. Microsoft od 5 maja 2025 wymaga od domen wysyłających ponad 5000 wiadomości dziennie do Outlook.com przechodzącego SPF i DKIM oraz rekordu DMARC z polityką co najmniej p=none, co podaje strona Outlook.com Postmaster. Niespełniające wymagań wiadomości trafiają najpierw do spamu, a docelowo są odrzucane z błędem 550 5.7.515.

7. Bezpieczne wdrożenie od p=none do reject

Zacznij od inwentaryzacji wszystkich systemów, które wysyłają pocztę z twoją domeną: serwera pocztowego, systemu newslettera, formularzy na stronie, faktur i powiadomień z aplikacji. Każdy z nich musi mieć pokrycie w SPF albo podpisywać wiadomości DKIM z domeną zgodną z polem „Od”.

Kolejne kroki wdrożenia wyglądają tak:

1. Opublikuj jeden rekord SPF i sprawdź, czy nie przekracza limitu 10 zapytań DNS.
2. Włącz DKIM z kluczem 2048 bitów u każdego nadawcy.
3. Opublikuj DMARC z p=none i adresem rua, a potem przez kilka tygodni analizuj raporty.
4. Przejdź na p=quarantine, najpierw z t=y, a potem bez niego.
5. Po kolejnym okresie bez nieoczekiwanych błędów ustaw p=reject.

Przekierowania i listy dyskusyjne mogą psuć SPF i DKIM, bo zmieniają serwer albo treść wiadomości. Rozwiązuje to ARC z RFC 8617, który zapisuje wyniki uwierzytelnienia u każdego pośrednika. Ma on jednak status eksperymentalny i wdrażają go pośrednicy, a nie właściciel domeny.

8. Podsumowanie

SPF, DKIM i DMARC działają dopiero razem. SPF i DKIM potwierdzają serwer i podpis, a DMARC wiąże je z adresem, który widzi odbiorca. Pilnuj jednego rekordu SPF i limitu zapytań, używaj kluczy DKIM 2048 bitów i sprawdź rekord DMARC pod kątem RFC 9989, zwłaszcza jeśli zawiera pct. Drogę do p=reject wyznaczają raporty zbiorcze, a nie kalendarz.