Jak poprawnie skonfigurować DMARC

DMARC mówi serwerom odbiorców, co zrobić z wiadomościami, które podają się za pochodzące z Twojej domeny, ale nie przechodzą uwierzytelnienia, i prosi je o raporty o tym, co widzą. Wdrożony starannie powstrzymuje bezpośrednie podszywanie się pod Twoją domenę. Wdrożony w pośpiechu potrafi zablokować Twoje własne faktury.

W maju 2026 roku IETF opublikowała DMARC jako proponowany standard w trzech dokumentach — RFC 9989 (protokół), RFC 9990 (raporty zbiorcze) i RFC 9991 (raporty o błędach) — które zastąpiły RFC 7489 z 2015 roku. Istniejące rekordy pozostają ważne; zmieniło się kilka tagów. Ten poradnik opiera się na nowej specyfikacji i wskazuje, gdzie odbiorcy, którzy jeszcze jej nie wdrożyli, zachowują się inaczej.

Co sprawdza DMARC

Wiadomość przechodzi DMARC, gdy spełniony jest co najmniej jeden z warunków:

• SPF przechodzi dla domeny nadawcy z koperty i ta domena jest zgodna z domeną w nagłówku From;
• podpis DKIM jest poprawny i domena podpisująca (d=) jest zgodna z domeną z From.

„Zgodna” (aligned) oznacza, że domeny do siebie pasują. W domyślnym trybie swobodnym (relaxed) muszą się zgadzać domeny organizacyjne: mail.example.com jest zgodna z example.com. W trybie ścisłym (strict) domeny muszą być identyczne.

To najważniejsze: SPF i DKIM mogą przejść dla jakiejś domeny, a DMARC i tak nie przejdzie, bo żadna z tych domen nie jest Twoją domeną. Dzieje się tak zawsze, gdy usługa pocztowa wysyła z własnym adresem dla odbić i podpisuje wiadomości własnym kluczem. Przykład krok po kroku znajdziesz w poradniku SPF, DKIM i DMARC: czym się różnią i co robią.

Zanim cokolwiek opublikujesz

Spisz wszystko, co wysyła pocztę z Twoją domeną w adresie From:

• Twojego dostawcę skrzynek (Google Workspace, Microsoft 365, …);
• narzędzia do newsletterów i marketingu;
• pocztę transakcyjną (resetowanie haseł, potwierdzenia zamówień);
• sklep internetowy, CRM, helpdesk, systemy do fakturowania i kadrowe;
• serwery, drukarki i skanery, które wysyłają raporty e-mailem.

Dla każdego z nich skonfiguruj podpisywanie DKIM Twoją własną domeną (większość usług nazywa to uwierzytelnianiem własnej domeny — „custom domain authentication” — i podaje rekordy CNAME do opublikowania) i upewnij się, że jest ujęty w Twoim rekordzie SPF. Część systemów i tak przeoczysz — od tego są raporty z następnego kroku.

Krok 1: opublikuj politykę monitorującą

Opublikuj rekord TXT pod nazwą Twojej domeny poprzedzoną prefiksem _dmarc.:

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

• v=DMARC1 musi być na początku, a wielkość liter ma znaczenie.
• p=none prosi odbiorców, by niczego nie zmieniali; wiadomości, które nie przejdą DMARC, są doręczane tak jak dotąd.
• rua= to adres, na który odbiorcy codziennie wysyłają raporty zbiorcze. Bez niego niczego się nie dowiesz.

p=none spełnia już minimum, którego Gmail, Yahoo i Outlook.com oczekują od nadawców masowych. Nie chroni jednak domeny.

Krok 2: czytaj raporty i naprawiaj to, co nie przechodzi

Raporty zbiorcze to pliki XML, które dla każdego wysyłającego adresu IP podają, ile wiadomości dotarło i czy przeszły SPF, DKIM i DMARC. Trudno je czytać ręcznie; usługa raportowa albo parser open source zamieni je w listę źródeł poczty. Pojedynczy raport od razu obejrzysz w analizatorze raportów DMARC.

Przejrzyj każde źródło, które wysyła prawidłową pocztę, ale nie przechodzi DMARC:

• Usługa pocztowa, która przechodzi SPF i DKIM dla własnej domeny — włącz w niej podpisywanie DKIM Twoją domeną albo ustaw własną domenę return-path (dla odbić) w obrębie Twojej domeny.
• System, który wysyła pocztę bezpośrednio — dodaj jego adresy IP do SPF albo kieruj jego pocztę przez usługę, która podpisuje ją DKIM.
• Poczta przekazywana dalej i listy dyskusyjne — przekazywanie psuje SPF, a listy, które zmieniają temat albo dodają stopki, psują DKIM. Duzi odbiorcy używają ARC (RFC 8617), aby rozpoznawać zaufanych pośredników. Po Twojej stronie nie da się tego naprawić, a gdy cała Twoja poczta jest podpisana DKIM, większość tych przypadków rozwiązuje się sama.

Źródła, których nie rozpoznajesz, to zazwyczaj próby podszywania się — dokładnie to, co zatrzyma polityka quarantine lub reject.

Daj tej fazie kilka tygodni, najlepiej pełny cykl rozliczeniowy, aby w raportach pojawili się też nadawcy wysyłający pocztę raz w miesiącu.

Krok 3: zaostrzaj politykę stopniowo

Gdy raporty pokazują, że Twoja prawidłowa poczta przechodzi DMARC, przejdź na kwarantannę:

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

Większość odbiorców kieruje wtedy pocztę, która nie przeszła DMARC, do folderu ze spamem. Po kolejnym spokojnym okresie przejdź na odrzucanie:

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

Tryb testowy. RFC 9989 dodaje t=y, który prosi odbiorców o zastosowanie polityki o jeden poziom łagodniejszej niż podana (quarantine działa jak none, a reject jak quarantine), podczas gdy Ty obserwujesz raporty. Usuń go, gdy nabierzesz pewności.

Subdomeny

Rekord dla domeny example.com obejmuje też jej subdomeny, a do dyspozycji są trzy polityki:

Tag	Dotyczy	Domyślnie
p	samej domeny (i subdomen, jeśli nie nadpisano polityki)	none (zawsze ustawiaj jawnie)
sp	istniejących subdomen, na przykład shop.example.com	wartość p
np	subdomen, które nie istnieją, na przykład invoice-dept.example.com	wartość sp, a gdy jej brak — p

Autorzy phishingu chętnie używają zmyślonych subdomen, więc np=reject to rozsądny dodatek, nawet gdy p ma jeszcze wartość quarantine. Subdomena może też opublikować własny rekord _dmarc, jeśli potrzebuje innej polityki.

Pełna lista tagów

Tag	Wartości	Uwagi
v	DMARC1	Wymagany, pierwszy, wielkość liter ma znaczenie
p	none, quarantine, reject	Polityka dla domeny; zalecany, a gdy go brak przy poprawnym rua — traktowany jak none
sp	jak p	Istniejące subdomeny
np	jak p	Nieistniejące subdomeny (nowość w RFC 9989)
t	y, n (domyślnie)	Tryb testowy (nowość)
rua	URI mailto: oddzielone przecinkami	Raporty zbiorcze
ruf	URI mailto:	Raporty o błędach; wysyłane rzadko, mogą zawierać treść wiadomości
fo	0, 1, d, s	Opcje raportów o błędach; tylko razem z ruf
adkim, aspf	r (domyślnie), s	Zgodność swobodna lub ścisła
psd	y, n, u (domyślnie)	Dla operatorów sufiksów publicznych (nowość)
pct, rf, ri	—	Usunięte w RFC 9989

Wielkość liter w nazwach tagów ma znaczenie: P=reject nie jest tagiem polityki i zostanie zignorowany.

Jak odbiorcy znajdują Twój rekord

Odbiorcy najpierw szukają rekordu _dmarc.<domena z From>. Jeśli go nie ma, RFC 9989 każe im przejść w górę drzewa DNS — dla poczty z news.mail.example.com pytają o _dmarc.mail.example.com, potem o _dmarc.example.com, a potem o _dmarc.com, łącznie nigdy więcej niż osiem zapytań — aby znaleźć rekord domeny organizacyjnej. RFC 7489 używał w tym samym celu listy sufiksów publicznych (Public Suffix List). Dla zwykłych domen obie metody dają ten sam wynik; jeśli zarządzasz złożoną, wielopoziomową strukturą domen, opublikuj jawne rekordy dla domen, z których wysyłasz pocztę.

Typowe błędy

• Rekord ląduje pod _dmarc.example.com.example.com. Wiele paneli DNS dokleja domenę do wpisanej nazwy. Wpisz samo _dmarc.
• v=dmarc1 małymi literami albo wersja nie na początku — rekord jest ignorowany.
• Dwa rekordy DMARC — odbiorcy pomijają oba.
• Adres raportów w innej domenie bez autoryzacji — raporty po cichu nigdy nie docierają.
• p=reject od pierwszego dnia — prawidłowa poczta z zapomnianego systemu jest odrzucana.
• Przekonanie, że sam rekord chroni domenę — przy p=none sfałszowana poczta nadal jest doręczana.

Sprawdź swoją konfigurację

Uruchom Sprawdzanie DMARC, aby zobaczyć, który rekord obowiązuje, co odbiorcy zrobią z pocztą, która nie przejdzie DMARC, i czy Twoje adresy raportów są autoryzowane. Potem potwierdź zgodność domen na prawdziwej wiadomości: wyślij ją na skrzynkę w Gmailu albo Outlooku i wklej jej nagłówki do analizatora nagłówków e-mail — szukaj dmarc=pass.