Wdrażanie DMARC: od none do reject
Moduł 4: Dostarczalność: SPF, DKIM i DMARC w praktyce · Czas czytania: 12 minut
Cel lekcji: Po tej lekcji będą Państwo potrafili wyjaśnić, jak działa uwierzytelnianie (alignment), zaplanować wdrożenie DMARC etapami od p=none do p=reject, dobrać właściwe znaczniki (rua, sp, np, t) oraz poradzić sobie ze znanymi pułapkami przy przekierowaniu i listach mailingowych.
Kluczowe pojęcia: DMARC (RFC 9989), Author Domain (domena w polu Od), uwierzytelnianie (alignment), relaxed i strict (adkim, aspf), domena organizacyjna, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (tryb testowy), nieaktualne znaczniki pct, rf, ri, listy mailingowe, przepisywanie nagłówka From, ARC
Co dokładnie sprawdza DMARC
DMARC odpowiada na jedno pytanie w przypadku każdej przychodzącej wiadomości: czy SPF lub DKIM zakończyły się powodzeniem dla domeny powiązanej z adresem Od? Domena w adresie Od nazywana jest w standardzie Author Domain. Podstawy rekordu opisaliśmy w kursie DNS, w lekcji 4.5. W maju 2026 roku opublikowano zaktualizowany standard: RFC 9989, wraz z RFC 9990 dla raportów zbiorczych i RFC 9991 dla raportów o błędach. Istniejące rekordy z v=DMARC1 pozostają ważne.
Uwierzytelnianie (alignment) w praktyce
Określenie "jest powiązane z" nazywa się uwierzytelnianiem (alignment). Istnieją dwa tryby:
- relaxed (łagodny) (domyślny): domeny mają tę samą domenę organizacyjną.
nieuws.example.comiexample.comsą uwierzytelnione (aligned);example.comiexample.netnie. - strict (
adkim=slubaspf=s): domeny muszą być dokładnie takie same.
Dla SPF DMARC porównuje domenę z Return-Path z domeną w polu Od. Dla DKIM porównywana jest domena d= z ważnego podpisu. Kilka przykładów dla wiadomości z Od: info@example.com:
| Wynik SPF (Return-Path) | Wynik DKIM (d=) | DMARC |
|---|---|---|
pass dla example.com | brak podpisu | pass (SPF uwierzytelnione) |
pass dla bounce.mailer.example | pass dla mailer.example | fail (oba zakończone powodzeniem, ale żadne nie jest uwierzytelnione) |
pass dla bounce.mailer.example | pass dla example.com | pass (DKIM uwierzytelnione) |
| fail (wiadomość przekierowana) | pass dla example.com | pass (DKIM przetrwał) |
pass dla bounce.example.com | brak | pass przy relaxed, fail przy aspf=s |
Proszę zatem pozostawić adkim i aspf w trybie relaxed, chyba że mają Państwo dobry powód, by zrobić inaczej.
Skąd odbiorca wie, jaka jest domena organizacyjna? Dawniej korzystano z Public Suffix List, listy domen takich jak .nl, .co.uk i github.io. RFC 9989 zastępuje to mechanizmem DNS tree walk: odbiorca wyszukuje rekordy _dmarc dla domeny oraz domen nadrzędnych. Dla przeciętnego użytkownika nic się nie zmienia; różnicę odczują Państwo tylko wtedy, gdy pracują z rekordami na subdomenach.
Wdrożenie w czterech etapach
Celem jest p=reject: wtedy odbiorcy odrzucają wiadomości podszywające się pod Państwa domenę, co stanowi najlepszą ochronę przed fałszywymi fakturami i phishingiem wysyłanym w Państwa imieniu. Jednak kto od razu ustawi reject, nie znając swoich nadawców, zablokuje w ten sposób własne faktury. Dlatego zalecamy taką kolejność (linia zalecana w tym kursie):
Etap 0: przygotowanie
- Proszę sporządzić spis wszystkich nadawców wysyłających w Państwa imieniu (lekcja 4.2).
- Proszę upewnić się, że każdy nadawca ma uwierzytelnione SPF lub DKIM; najlepiej DKIM, ponieważ przetrwa przekierowanie.
- Proszę utworzyć osobny adres na raporty, na przykład
dmarc@example.com, albo skorzystać z usługi raportującej. Dość szybko będą Państwo otrzymywać kilka raportów dziennie.
Etap 1: pomiar z p=none
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"p=none nie wpływa w żaden sposób na samą wiadomość. Odbiorcy dostarczają wszystko tak jak dotychczas, ale codziennie przesyłają raport zbiorczy (aggregate report) z informacją o każdym serwerze wysyłającym w imieniu Państwa domeny oraz o tym, czy SPF, DKIM i DMARC zakończyły się powodzeniem. Dzięki temu spełniają Państwo również minimalne wymaganie Gmaila, Yahoo i Microsoftu dla nadawców masowych (lekcja 5.3).
Proszę pozostawić to ustawienie przez co najmniej dwa do czterech tygodni, a dłużej, jeśli korzystają Państwo z usług, które wysyłają wiadomości jedynie od czasu do czasu (coroczne przypomnienie, kwartalna faktura). Proszę przeczytać raporty (lekcja 4.5) i naprawić każde własne źródło, które zawodzi.
Etap 2: p=quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"Wiadomości, które nie przejdą DMARC, trafiają u odbiorcy do folderu spam. Jeśli mimo wszystko zapomną Państwo o jakimś źródle, taka wiadomość nie zostanie utracona, ale trudniej będzie ją znaleźć. Jeśli chcą Państwo zachować ostrożność, proszę najpierw dodać t=y (tryb testowy): odbiorcy stosują wtedy politykę o stopień łagodniejszą (w przypadku quarantine będzie to więc none), ale w raportach widać, co by się stało. Jest to w RFC 9989 odpowiednik dawnego znacznika pct=.
Proszę ponownie przez kilka tygodni obserwować raporty.
Etap 3: p=reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"Wiadomości, które nie przejdą DMARC, są odrzucane. Nadawca otrzymuje zwrotkę (bounce), na przykład u Microsoftu z kodem 5.7.509, a u Gmaila z odniesieniem do polityki DMARC (moduł 6). Proszę nadal śledzić raporty: nowe usługi stale się pojawiają.
Kiedy można przyspieszyć?
Czy cała Państwa poczta przechodzi przez jednego dostawcę, który zajmuje się SPF i DKIM, a nikt inny nie wysyła wiadomości w Państwa imieniu? Wtedy surową politykę można wdrożyć od razu. Niektóre firmy hostingowe domyślnie ustawiają dlatego p=reject. Jeśli później zaczną Państwo jednak korzystać z usługi newslettera lub programu księgowego, proszę najpierw tymczasowo wrócić do p=none z adresem raportującym, dopóki ta usługa nie zostanie poprawnie skonfigurowana.
Pozostałe znaczniki
| Znacznik | Do czego służy | Zalecenie |
|---|---|---|
rua=mailto:... | Adres(y) na raporty zbiorcze, oddzielone przecinkami | Zawsze wypełniać podczas wdrażania |
ruf=mailto:... | Adres na raporty o błędach wysyłane pocztą (RFC 9991) | Niemal żaden odbiorca ich nie wysyła, a mogą zawierać dane osobowe. Zwykle lepiej pominąć |
sp= | Polityka dla istniejących subdomen | Pominąć (wtedy obowiązuje p=), chyba że subdomeny wysyłają pocztę inaczej |
np= | Polityka dla subdomen, które nie istnieją | np=reject to dobre uzupełnienie, gdy główna polityka jest surowa: wtedy nikt nie może wysyłać poczty z factuur.example.com, jeśli taka nazwa nie istnieje |
adkim=, aspf= | Strict lub relaxed | Pozostawić relaxed |
t=y | Tryb testowy: o stopień łagodniej | Przydatne przy przejściu do quarantine lub reject |
fo= | Kiedy tworzone są raporty o błędach | Ma sens tylko razem z ruf |
pct=, rf=, ri= | Nieaktualne w RFC 9989 | Nie używać; odbiorcy stosujący nowy standard je ignorują |
Adres raportujący na innej domenie (na przykład usługi raportującej) działa tylko wtedy, gdy ta domena wyraża na to zgodę za pomocą rekordu takiego jak example.com._report._dmarc.rapportdienst.example. Usługa zwykle zajmuje się tym sama (RFC 9990, rozdział 4).
Pułapki
Listy mailingowe
Klasyczna lista mailingowa przekazuje Państwa wiadomość do wszystkich członków, wysyłając ją z własnego serwera, i często dodaje [lista] do tematu lub stopkę. Wtedy SPF zawodzi (inny serwer), podobnie jak DKIM (zmieniona wiadomość). Przy p=reject odbiorcy odrzucają wiadomość skierowaną do listy. Nowoczesne oprogramowanie list mailingowych rozwiązuje to, przepisując adres Od na adres listy (na przykład "Jan via Leden"), albo przekazując wiadomość bez zmian. Jeśli korzystają Państwo z listy, która tego nie robi, zobaczą to Państwo w swoich raportach.
Przekierowanie
Patrz lekcja 3.3: SPF się psuje, DKIM zwykle przetrwa. Odbiorca może za pomocą ARC zdecydować się zaufać znanemu serwerowi przekierowującemu. W raportach rozpoznają to Państwo jako wiadomość z nieznanego serwera z DKIM pass i SPF fail; to nie jest powód, by łagodzić swoją politykę.
Dwa rekordy albo literówka
Dwa rekordy DMARC na _dmarc unieważniają politykę, podobnie jak literówka w p= (p=rejected nie istnieje). Po każdej zmianie proszę to sprawdzić.
W praktyce: jak to wygląda w panelu
W pakiecie hostingowym WebOké domyślnie ustawiony jest v=DMARC1;p=reject, bez adresu raportującego. Jest to bezpieczne, jeśli cała Państwa poczta przechodzi przez te serwery. Jeśli wysyłają Państwo pocztę także za pośrednictwem innych usług, proszę ustawić p=none z adresem rua i przejść przez kolejne etapy. W DirectAdmin robi się to w sekcji Administracja DNS za pomocą ikony ołówka przy rekordzie _dmarc (pola Typ polityki dla domeny i Adres e-mail raportów zbiorczych (RUA)); w Moje WebOké za pomocą asystenta DMARC na karcie DNS. U innych dostawców tworzą Państwo rekord TXT dla nazwy _dmarc i wpisują tekst ręcznie; efekt jest taki sam.
Podsumowanie
- DMARC kończy się powodzeniem, jeśli SPF lub DKIM zakończą się powodzeniem dla domeny uwierzytelnionej z domeną z pola Od; uwierzytelnianie relaxed akceptuje subdomeny.
- Wdrożenie: spis nadawców,
p=nonezruai czytanie raportów,p=quarantine(ewentualnie zt=y), a następniep=reject. - Proszę używać
np=rejectdla nieistniejących subdomen, gdy główna polityka jest surowa.pct,rfirisą nieaktualne. - Listy mailingowe i przekierowania powodują spodziewane błędy; DKIM i ARC łagodzą część z nich.
- Dokładnie jeden rekord na
_dmarc, bez literówek.
Quiz
Zadanie
Zadanie Z4.4: Sprawdzenie DMARC własnej domeny i wybór kolejnego kroku. Proszę wpisać własną domenę (lub internet.nl). Proszę podać znaleziony rekord DMARC, wartość p= oraz informację, czy znajduje się w nim adres rua. Następnie proszę wybrać, który etap wdrożenia uznają Państwo za kolejny krok, i uzasadnić dlaczego. Program na żywo pobiera rekord, sprawdza składnię zgodnie z RFC 9989 (jeden rekord, prawidłowe p, znane znaczniki, nieaktualne znaczniki jako ostrzeżenie) i zestawia to z Państwa odpowiedziami.
Dalsza lektura
Kroki opisane w tych artykułach dotyczą paneli WebOké; u innych dostawców działa to w podobny sposób.
- Bezpłatny kurs DNS 4.5: DMARC: co odbiorcy powinni robić z fałszywą pocztą
- Instrukcja DirectAdmin 5.9: DMARC instellen
- Czym jest DMARC? Wyjaśnienie w prostych słowach
- Tworzenie rekordu DMARC w DirectAdmin
- RFC 9989 (DMARC), w szczególności sekcja 4.7 (znaczniki) i załącznik C (zmiany od RFC 7489)