Rekord DMARC jest opublikowany, ale odbiorcy go odrzucają

Co to jest

Pod _dmarc.example.cz rekord TXT jest, ale jego tag wersji nie brzmi dokładnie v=DMARC1. Serwery odbiorcze pomijają taki rekord i traktują domenę tak, jakby w ogóle nie miała DMARC.

Dlatego skan nie mówi, że rekordu brakuje — przecież widzisz go w DNS. Mówi, że odbiorcy go nie użyją. Skutek jest ten sam co przy braku rekordu: nikt niczego nie egzekwuje i nie przychodzą żadne raporty.

O jakie postacie chodzi

Zawsze chodzi o początek rekordu, nigdy o politykę p= za nim. Są dwie grupy.

Postacie, które standard każe ignorować

RFC 9989 w sekcji 4.7 wymaga, aby tag v= był pierwszy i miał wartość dokładnie DMARC1; w przeciwnym razie odbiorca ma zignorować cały rekord.

• v=dmarc1; p=reject — wartość zapisana małymi literami.
• v=DMARC10; p=reject — po DMARC1 jest coś jeszcze.
• p=reject; v=DMARC1 — tag wersji dopiero za polityką.
•  v=DMARC1; p=none — rekord zaczyna się spacją. Zwykle bierze się to z kopiowania wartości z poradnika do panelu DNS.
• v=DMARC1 p=reject — po wersji brakuje średnika, więc wartością wersji jest całe DMARC1 p=reject.
• v=DMARC2; p=reject — wersja, która nie istnieje; jedyna to DMARC1.

Postacie, które standard dopuszcza, a serwery i tak je odrzucają

Tu trzeba być precyzyjnym: według gramatyki z sekcji 4.8 te dwa zapisy są poprawne. Mimo to odrzucają je trzy z czterech rozpowszechnionych implementacji, których kod źródłowy czytaliśmy we wrześniu 2026 (OpenDMARC, rspamd, go-msgauth, Mail::DMARC) — ich filtr nad odpowiedzią z DNS jest surowszy niż ich własny parser tagów.

• V=DMARC1; p=reject — wielkie V w nazwie tagu.
• v = DMARC1; p=reject — spacje wokół =.

Nie twierdzimy więc, że zabrania ich standard. Twierdzimy, że ochrona przy nich w praktyce nie działa, a poprawka kosztuje jeden znak.

Dlaczego to gorsze niż brak rekordu

• Fałszywy spokój. W DNS widać p=reject, więc domena wygląda na chronioną. Podszyta poczta i tak przechodzi.
• Nie przychodzą raporty. Adres w rua= należy do rekordu, który odbiorca odrzucił, więc o podszywaniu się nie dowiesz się wcale.
• Pułapka przy naprawie. Poradnik „dodaj rekord DMARC” skłania do opublikowania drugiego rekordu TXT obok istniejącego. Tymczasem RFC 9989 sekcja 4.10 mówi, że gdy pod nazwą _dmarc są dwa rekordy, nie obowiązuje żaden. Kończy się gorzej, niż było na starcie.

Jak to naprawić

Popraw istniejący rekord, nie dodawaj nowego.

1. Wypisz, co jest opublikowane: dig +short TXT _dmarc.example.cz (w Windows nslookup -type=TXT _dmarc.example.cz).
2. W panelu DNS edytuj ten jeden rekord. Wszystko za tagiem wersji zostaw bez zmian — politykę, rua= i pozostałe tagi.
3. Zapisz i poczekaj, aż wygaśnie TTL (zwykle minuty do godzin).

źle:      v=dmarc1; p=quarantine; rua=mailto:dmarc@example.cz
poprawnie: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.cz

Uwaga na dwie rzeczy, które do wartości dodaje edytor DNS, a nie Ty: spację na początku i dodatkowe cudzysłowy wewnątrz wartości. Po zapisaniu zawsze odczytaj więc rekord z powrotem przez dig, a nie z formularza.

Weryfikacja

Gdy dig zwróci dokładnie jeden rekord zaczynający się od v=DMARC1;, jest gotowe. Potwierdzisz to nowym skanem na vulscan.app — kontrola DMARC jest częścią bezpłatnego skanu.

Dopiero potem ma sens zajmowanie się siłą polityki: co znaczą p=none, p=quarantine i p=reject oraz w jakiej kolejności je wdrażać, omawia artykuł Domena nie ma rekordu DMARC.

Odnośniki

• Vulscan docs: DMARC od zera
• Vulscan docs: SPF
• RFC 9989 — DMARC — sekcja 4.7 (tag wersji), 4.8 (gramatyka rekordu), 4.10 (dwa rekordy = nie obowiązuje żaden)