Domena nie ma rekordu DMARC

Co to jest

Twoja domena nie ma rekordu DNS _dmarc.example.cz typu TXT. DMARC mówi odbierającym serwerom pocztowym (Gmail, Seznam, Outlook), co mają zrobić, gdy otrzymają wiadomość, która udaje wiadomość od example.cz, ale nie przejdzie weryfikacji SPF ani DKIM.

Bez DMARC odpowiedź brzmi „zdecyduj sam” — a duzi dostawcy w praktyce dostarczają sfałszowaną wiadomość.

Dlaczego to problem

Każdy może wysłać e-mail w imieniu Twojej domeny. Konkretnie:

Jak to naprawić

DMARC wdrażaj etapami. Przeskok od razu na politykę wymuszającą, zanim przeczytasz swoje raporty, zaszkodzi legalnemu mailingowi.

Faza 1 (1-2 tygodnie) — monitoring

Utwórz rekord DNS TXT:

Name:  _dmarc.example.cz
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.cz; fo=1

p=none nie wyraża żadnej preferencji co do tego, co odbiorca ma zrobić z niezaliczoną pocztą (RFC 9989, sekcja 4.7) — każdy filtruje ją dalej po swojemu. To, o co ten rekord faktycznie prosi, to raporty: rua to adres e-mail, na który dostawcy będą wysyłać raporty zbiorcze.

Faza 2 (po 1-2 tygodniach) — kwarantanna

Z raportów widzisz wszystkie legalne serwery, które wysyłają w Twoim imieniu (Mailchimp, Mailgun, Microsoft 365, własny serwer). Dodaj je do SPF i DKIM. Następnie eskaluj:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.cz

p=quarantine to pełnoprawna polityka wymuszająca (RFC 9989, sekcja 3.2.9) — poczta, która nie przejdzie DMARC, trafia do spamu zamiast do skrzynki odbiorczej.

Nie dodawaj tu pct=10. Starsze poradniki używają pct= do stopniowego wdrażania polityki na części niezaliczonej poczty, ale tag pct został usunięty z DMARC w RFC 9989 (maj 2026) i zgodny z normą odbiorca go ignoruje. U każdego odbiorcy, który przeszedł na RFC 9989, p=quarantine; pct=10 jest więc stosowane do 100 % niezaliczonej poczty, a nie do 10 % — a pct=0 jako „bezpieczny test” jest tam pełnym wymuszaniem. Ponieważ nie kontrolujesz, którzy odbiorcy już przeszli, na pct w ogóle nie da się oprzeć stopniowego wdrożenia.

Do przebiegu testowego RFC 9989 definiuje w sekcji 4.7 tag t=. U odbiorcy, który przeszedł na RFC 9989, t=y prosi o politykę o jeden poziom łagodniejszą niż opublikowana, a raporty nadal przychodzą: p=quarantine; t=y jest tam traktowane jak p=none, a p=reject; t=y jak p=quarantine.

t= i pct to jednak nie to samo: pct zniknął z protokołu i odbiorcy stosujący RFC 9989 go ignorują, a t= jest jego prawidłowym następcą — działa jednak tylko u odbiorców, którzy przeszli na RFC 9989. Sam tag jest w RFC 9989 nowy (dodatek A.6), a sekcja 4.8 nakazuje odbiorcy ignorować tagi, których nie zna: ten, kto nie przeszedł na RFC 9989, stosuje opublikowaną przez Ciebie politykę w pełni — przy p=quarantine; t=y trafia tam do kwarantanny wszystko, co nie przejdzie DMARC. Dlatego publikuj t= tylko przy polityce, której pełny skutek jesteś gotów przyjąć; jedyną fazą, która nigdzie niczego nie wymusza, pozostaje p=none. Po zakończeniu testu usuń tag (albo ustaw t=n).

Faza 3 (opcjonalna) — reject

v=DMARC1; p=reject; rua=mailto:dmarc@example.cz

Przy p=reject odbiorca od razu odrzuca sfałszowaną wiadomość. RFC 9989 sekcja 7.4 wiąże z tym dwa warunki: domena publikująca p=reject musi podpisywać pocztę ważnym DKIM i nie może polegać wyłącznie na SPF (SPF psuje się przy przekazywaniu poczty), a domeny, które hostują użytkowników mogących pisać na internetowe listy dyskusyjne, nie powinny publikować p=reject w ogóle.

Jeśli któryś z tych warunków dotyczy Ciebie, pozostanie na p=quarantine to uprawniony stan docelowy, a nie niedokończone wdrożenie.

Weryfikacja

Po każdej fazie zweryfikuj rekord nowym skanem na vulscan.app — kontrola DMARC (razem z SPF) jest częścią bezpłatnego skanu. Raporty zbiorcze przychodzą na adres z rua jako załączniki XML; na początek wystarczy obserwować, które serwery wysyłają pocztę niezaliczającą DMARC.

Źródła