SPF, DKIM i DMARC w praktyce – bezpieczna droga do p=reject

Każdy może wpisać Państwa domenę w polu Od (From) wiadomości e-mail. SPF, DKIM i DMARC pozwalają serwerowi odbiorcy sprawdzić, czy wiadomość naprawdę pochodzi od Państwa, i mówią mu, co zrobić, jeśli tak nie jest. Starannie wdrożone znacznie utrudniają podszywanie się pod dokładnie tę samą domenę. Wdrożone w pośpiechu mogą zablokować Państwa własne faktury.

Co robi każdy z mechanizmów

SPF (Sender Policy Framework, RFC 7208) to rekord DNS typu TXT, który wymienia serwery uprawnione do wysyłania poczty w imieniu domeny. Odbiorca porównuje adres IP łączącego się serwera z tą listą. SPF sprawdza nadawcę koperty (tożsamości MAIL FROM i HELO), a nie adres Od, który widzi adresat.

DKIM (DomainKeys Identified Mail, RFC 6376) dodaje do każdej wiadomości podpis kryptograficzny. Znacznik d= wskazuje domenę podpisującą, a s= selektor. Klucz publiczny jest publikowany w DNS pod nazwą selector._domainkey.domain. Prawidłowy podpis pokazuje, że podpisane części wiadomości nie zmieniły się od chwili, gdy domena ją podpisała.

DMARC wiąże oba mechanizmy z widoczną domeną w polu Od. Zmieniona wersja została opublikowana w maju 2026 roku jako RFC 9989, dokument Standards Track, który zastępuje RFC 7489. Rekord DMARC określa Państwa politykę i prosi odbiorców o przesyłanie raportów.

Zgodność domen, o której się zapomina

Wiadomość przechodzi DMARC, gdy SPF lub DKIM zakończą się powodzeniem i uwierzytelniona domena jest zgodna (aligned) z domeną w polu Od. Zgodność swobodna, czyli domyślna, akceptuje dopasowanie na poziomie domeny organizacyjnej, więc mail.example.eu jest zgodna z example.eu. Zgodność ścisła (adkim=s lub aspf=s) wymaga dokładnego dopasowania.

Najczęściej problem pojawia się przy zewnętrznych nadawcach. Platforma newsletterowa może używać domeny koperty takiej jak bounces.platform.example. SPF przechodzi dla domeny platformy, ale ta domena nie jest zgodna z example.eu, więc nie wpływa na Państwa wynik DMARC.

Rozwiązaniem jest skonfigurowanie platformy tak, aby podpisywała wiadomości DKIM z d=example.eu, albo ustawienie własnej ścieżki zwrotnej (return-path) w jednej z Państwa subdomen. RFC 9989 zaleca właścicielom domen stosowanie zarówno SPF, jak i DKIM. Dzięki temu jeden mechanizm może zapewnić wynik, gdy drugi zawiedzie, na przykład po przekazaniu wiadomości dalej.

Jak wyglądają rekordy

Poniższe przykłady wykorzystują adres IP przeznaczony do dokumentacji i przykładowego dostawcę. Należy zastąpić je własnymi wartościami.

example.eu.                    TXT  "v=spf1 include:spf.mail-provider.example ip4:203.0.113.25 ~all"
s2026._domainkey.example.eu.   TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.eu.             TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.eu"

Powyższy rekord DMARC działa w trybie monitorowania. Prosi o raporty zbiorcze, ale nie żąda żadnych działań wobec poczty, która nie przechodzi weryfikacji. Raporty zbiorcze, opisane obecnie w RFC 9990, pokazują, które serwery wysyłają pocztę z użyciem Państwa domeny i czy przechodzą weryfikację.

W przypadku kluczy DKIM RFC 6376 wymaga dla kluczy długoterminowych kluczy RSA o długości co najmniej 1024 bitów. Google wymaga co najmniej 1024 bitów dla poczty kierowanej do prywatnych kont Gmail i zaleca 2048 bitów, jeśli dostawca to obsługuje.

Bezpieczne przejście od p=none do p=reject

1. Spisać wszystkich nadawców. Należy uwzględnić platformę pocztową, CRM, systemy fakturowe i płacowe, helpdesk, formularze na stronie oraz urządzenia, takie jak skanery wysyłające dokumenty e-mailem.
2. Skonfigurować SPF i DKIM dla każdego z nich. Każdą usługę warto poprosić o podpisywanie DKIM w Państwa własnej domenie, wszędzie tam, gdzie to możliwe.
3. Opublikować p=none z adresem rua. RFC 9989 opisuje to jako typowy punkt wyjścia, który pozwala znaleźć nadawców pominiętych podczas konfiguracji.
4. Czytać raporty i usuwać luki. Należy na to przeznaczyć co najmniej kilka tygodni, a więcej, jeśli wysyłają Państwo pocztę cyklicznie co miesiąc lub co kwartał, np. listy płac czy roczne zestawienia.
5. Przejść na p=quarantine, a następnie na p=reject. RFC 9989 usunęło dawny znacznik pct. Zastąpił go tryb testowy: t=y prosi odbiorców o zastosowanie polityki o jeden poziom łagodniejszej, więc p=reject; t=y jest traktowane jak kwarantanna.
6. Objąć ochroną subdomeny i domeny nieużywane (parked). Znacznik sp ustala politykę dla istniejących subdomen, a nowy znacznik np obejmuje subdomeny, które nie istnieją.

t=y należy traktować jako złagodzenie, a nie gwarancję. Zarówno RFC 7489, jak i RFC 9989 każą odbiorcom ignorować nierozpoznane znaczniki. Odbiorca, który nie wdrożył jeszcze nowej specyfikacji, może więc zastosować opublikowaną politykę w pełni.

W kroku 6 domena, która nigdy nie wysyła poczty, powinna to jasno zadeklarować. Należy opublikować rekord SPF, który nikogo nie upoważnia, oraz politykę odrzucenia:

parked-example.eu.                              TXT  "v=spf1 -all"
_dmarc.parked-example.eu.                       TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.eu"
parked-example.eu._report._dmarc.example.eu.    TXT  "v=DMARC1"

Trzeci rekord jest ważny, ponieważ raporty trafiają do innej domeny. RFC 9990 wymaga, aby przed wysłaniem raportów odbiorcy sprawdzili, czy domena docelowa zgodziła się przyjmować raporty dla domeny, której dotyczy polityka.

Duzi dostawcy skrzynek pocztowych już oczekują tej pracy. Od 1 lutego 2024 roku Google wymaga od nadawców masowych (ponad 5000 wiadomości dziennie do Gmaila) stosowania SPF, DKIM i DMARC ze zgodnością domen. Polityka p=none spełnia to minimum, ale nie chroni Państwa domeny.

Typowe błędy

Dwa rekordy SPF

Domena może publikować tylko jeden rekord SPF. Jeśli odbiorca znajdzie więcej niż jeden, wynikiem SPF jest permerror, a nie pass. Dodając nową usługę, należy włączyć jej include do istniejącego rekordu, zamiast tworzyć drugi.

Więcej niż dziesięć zapytań DNS

RFC 7208 ogranicza ocenę SPF do 10 elementów powodujących zapytania DNS: include, a, mx, ptr, exists oraz modyfikatora redirect. Liczą się również include zagnieżdżone w Państwa include. Po przekroczeniu limitu wynikiem jest permerror.

Elementy ip4, ip6 i all się nie liczą, więc wymienienie własnych serwerów z adresu pomaga. Należy usunąć include dla usług, z których Państwo już nie korzystają. RFC sugeruje też ograniczenie tzw. pustych zapytań (void lookups), czyli zapytań bez odpowiedzi, do dwóch.

+all i ?all

Mechanizm all zawsze pasuje, a o wyniku decyduje jego kwalifikator. +all upoważnia więc każdy serwer w internecie, dlatego nigdy nie należy go publikować. ?all zwraca wynik neutralny, który według RFC 7208 trzeba traktować dokładnie tak jak brak wyniku SPF. Należy używać ~all (softfail) lub -all (fail).

Które z nich? Pierwotna specyfikacja DMARC (RFC 7489, sekcja 6.7) zauważa, że odrzucanie wiadomości po niepowodzeniu SPF uniemożliwia odbiorcy ocenę DKIM. Może to zaszkodzić poczcie przekazywanej dalej, w której SPF zawodzi, ale podpis DKIM nadal jest prawidłowy. Gdy DMARC jest już egzekwowany, ~all pozwala, aby ostateczną decyzję podjął DMARC.

Pomijanie przekazywania poczty i list mailingowych

Wiadomość przekazana dalej przychodzi z adresu IP serwera przekazującego, którego nie ma w Państwa rekordzie SPF. Podpis DKIM zwykle przetrwa przekazanie, jeśli wiadomość nie zostanie zmieniona. Listy mailingowe, które edytują temat lub dodają stopkę, mogą go jednak unieważnić. Dlatego przy przejściu na p=reject niezawodne podpisywanie DKIM we własnej domenie jest ważniejsze niż SPF.

Używanie ptr

Według RFC 7208 mechanizm ptr nie powinien być publikowany. Jest powolny, mniej niezawodny i nadal wlicza się do limitu zapytań.

Egzekwowanie polityki bez czytania raportów

Przejście od razu na p=reject to łatwy sposób na zablokowanie własnych wiadomości z resetem hasła, faktur czy odpowiedzi działu wsparcia. Raporty pokazują, o których nadawcach Państwo zapomnieli. Należy je czytać przed egzekwowaniem polityki i nadal po nim, bo dochodzą nowe usługi.

Od czego zacząć

• Sprawdzić, co publikuje dziś Państwa domena, za pomocą naszego testu bezpieczeństwa poczty.
• Utworzyć lub uporządkować rekordy w generatorze SPF i DMARC.
• Spisać wszystkie systemy, które wysyłają pocztę w imieniu Państwa domeny. Ta lista będzie potrzebna przed egzekwowaniem polityki.
• Już teraz opublikować p=none z adresem do raportów i wyznaczyć termin przeglądu pierwszych raportów.
• Dodać v=spf1 -all i rekord DMARC z p=reject do każdej posiadanej domeny, która nie wysyła poczty.

Jeśli wolą Państwo powierzyć komuś analizę raportów i przejście do egzekwowania polityki, nasze zarządzane usługi bezpieczeństwa mogą pomóc w obu tych zadaniach.