SPF / DKIM / DMARC (uwierzytelnianie poczty)

SPF, DKIM i DMARC to trzy uzupełniające się mechanizmy uwierzytelniania poczty elektronicznej, publikowane jako rekordy w DNS domeny nadawcy. SPF pozwala właścicielowi domeny wskazać hosty uprawnione do wysyłania poczty w jej imieniu ^[1]. DKIM pozwala domenie przyjąć odpowiedzialność za wiadomość przez podpis kryptograficzny, sprawdzany kluczem publicznym pobieranym z DNS ^[2]. DMARC łączy wyniki obu i pozwala domenie wyrazić politykę postępowania z wiadomościami, które weryfikacji nie przeszły, oraz zamówić raporty ^[3]. Razem utrudniają spoofing domeny w poczcie.

Jak działa

Każdy mechanizm sprawdza coś innego. SPF weryfikuje dwie tożsamości z rozmowy SMTP: adres MAIL FROM (ścieżkę zwrotną) i nazwę podaną w HELO; pyta, czy adres IP łączącego się serwera wolno mu ich używać ^[1]. DKIM dołącza do wiadomości podpis; znacznik d= wskazuje domenę, która bierze odpowiedzialność za wprowadzenie wiadomości do obiegu, a klucz publiczny leży w rekordzie TXT pod nazwą selektor._domainkey.domena ^[2]. Selektor pozwala domenie mieć kilka kluczy jednocześnie ^[2], co ułatwia rotację kluczy.

Żaden z tych dwóch mechanizmów nie sprawdza jednak adresu, który odbiorca widzi w polu „Od”. Robi to dopiero DMARC: wymaga, by domena z nagłówka From była zgodna (ang. alignment) z domeną uwierzytelnioną przez SPF albo DKIM ^[3]. Zgodność może być ścisła, gdy domeny są identyczne, albo swobodna, gdy należą do tej samej domeny organizacyjnej ^[3]. Politykę publikuje się w rekordzie TXT pod nazwą _dmarc.example.com ^[3].

Przebieg sprawdzania wiadomości przez serwer odbiorcy pokazuje schemat poniżej.

RYS. 1Weryfikacja wiadomości od example.com

Przykładowe rekordy dla domeny example.com wyglądają tak:

example.com.                     TXT "v=spf1 ip4:192.0.2.10 include:_spf.example.net -all"
s1._domainkey.example.com.       TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.              TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Składniki

Wyniki SPF. Norma definiuje siedem wyników: pass, fail, softfail, neutral, none, temperror i permerror ^[1]. Kwalifikator przed mechanizmem wybiera wynik: + to pass (domyślny), - to fail, ~ to softfail, ? to neutral ^[1]. Implementacja musi ograniczyć do 10 liczbę mechanizmów i modyfikatorów wymagających zapytań DNS, żeby nie obciążać DNS ^[1]. Rozbudowany rekord z wieloma include: łatwo przekracza ten limit i kończy się wynikiem permerror.

Polityki DMARC. Znacznik p przyjmuje trzy wartości: none (brak preferencji), quarantine (wiadomość podejrzana) i reject (użycie nieuprawnione) ^[3]. RFC 9989 z maja 2026 roku zastąpił RFC 7489, podniósł DMARC do ścieżki standardów i usunął znacznik pct, który pozwalał stosować politykę tylko do części poczty ^[3].

DKIM nie szyfruje wiadomości i sam nie zapobiega jej modyfikacji; potwierdza jedynie, że domena podpisująca bierze za nią odpowiedzialność ^[2]. Opiera się na kryptografii asymetrycznej, tak jak każdy podpis cyfrowy.

W WordPressie

WordPress wysyła pocztę funkcją wp_mail(), opartą na bibliotece PHPMailer ^[6]. Domyślny nadawca to wordpress@ z domeną witryny ^[6]. Adres zmienia filtr wp_mail_from, a pełną konfigurację, na przykład wysyłkę przez zewnętrzny serwer SMTP, daje filtr phpmailer_init ^[6]. Dokumentacja zaznacza, że wartość true zwrócona przez funkcję nie oznacza, że wiadomość dotarła do odbiorcy ^[6].

Z tego wynikają typowe problemy. Formularz kontaktowy, reset hasła czy powiadomienie sklepu idą z serwera hostingu, którego adresu IP często nie ma w rekordzie SPF domeny. Jeśli domena ma politykę DMARC reject, a poczta z WordPressa nie ma ani zgodnego SPF, ani podpisu DKIM, serwery odbiorców mogą ją odrzucić. Rozwiązaniem jest wysyłka przez serwer pocztowy domeny albo usługę transakcyjną, która podpisuje wiadomości kluczem DKIM tej domeny. Wtyczki formularzy nie powinny też ustawiać w polu „Od” adresu wpisanego przez gościa, bo taka wiadomość z definicji nie przejdzie DMARC.

Nieuwierzytelniona poczta witryny to także ryzyko. Bez polityki DMARC łatwiej podszyć się pod domenę sklepu w phishingu do jego klientów albo w oszustwie BEC wobec kontrahentów.

Wymagania i przepisy

W Polsce art. 24 ust. 1 ustawy o zwalczaniu nadużyć w komunikacji elektronicznej nakłada na dostawcę poczty elektronicznej obsługującego co najmniej 500 000 użytkowników albo podmiot publiczny obowiązek stosowania SPF, DMARC i DKIM ^[5]. Ust. 2 zobowiązuje podmiot publiczny do korzystania z poczty wykorzystującej te mechanizmy ^[5]. Szerzej opisuje to hasło ustawa o zwalczaniu nadużyć w komunikacji elektronicznej.

Wymagania stawiają też duzi odbiorcy poczty. Google od 1 lutego 2024 roku wymaga od wszystkich nadawców do Gmaila SPF albo DKIM, a od nadawców ponad 5000 wiadomości dziennie SPF, DKIM i DMARC oraz zgodności domeny From z domeną SPF lub DKIM ^[4]. Tych samych nadawców dotyczy wymóg odsubskrybowania jednym kliknięciem w wiadomościach marketingowych ^[4].

Dobre praktyki

• Zinwentaryzować wszystkie źródła poczty domeny: serwer pocztowy, hosting WordPressa, system newslettera, CRM, fakturowanie.
• Zakończyć rekord SPF mechanizmem -all albo ~all i pilnować limitu 10 zapytań DNS ^[1].
• Podpisywać DKIM każdą usługę wysyłającą w imieniu domeny i wymieniać klucze przez nowy selektor ^[2].
• Opublikować DMARC z adresem raportów zbiorczych. Polityka p=none nie wyraża preferencji co do postępowania z pocztą ^[3], więc pozwala najpierw zebrać raporty i znaleźć pominięte źródła, a dopiero potem przejść do quarantine i reject.
• Chronić samą strefę DNS: przejęcie DNS pozwala podmienić rekordy SPF i klucze DKIM. Integralność odpowiedzi DNS wzmacnia DNSSEC.

Mechanizmy te nie chronią przed domenami łudząco podobnymi do prawdziwej. Taki typosquatting ma własne, poprawne rekordy, więc wiadomość przejdzie weryfikację. Pozostaje uważność odbiorcy i szkolenia pracowników.