DMARC záznam je publikovaný, ale príjemcovia ho zahadzujú

Čo to je

Na _dmarc.example.cz TXT záznam je, ale jeho verzovací tag nie je presne v=DMARC1. Prijímajúce servery taký záznam preskočia a s doménou zaobchádzajú, akoby DMARC nemala vôbec.

Preto vám sken nehovorí, že záznam chýba — vy ho v DNS vidíte. Hovorí, že ho príjemcovia nepoužijú. Dopad je pritom rovnaký ako pri chýbajúcom zázname: nikto nič nevynucuje a žiadne reporty nechodia.

Ktoré tvary to sú

Vždy ide o začiatok záznamu, nie o politiku p= za ním. Rozlišujeme dve skupiny.

Tvary, ktoré štandard nariaďuje ignorovať

RFC 9989 v sekcii 4.7 požaduje, aby bol tag v= prvý a mal hodnotu presne DMARC1; inak má príjemca celý záznam ignorovať.

• v=dmarc1; p=reject — hodnota napísaná malými písmenami.
• v=DMARC10; p=reject — za DMARC1 je niečo navyše.
• p=reject; v=DMARC1 — verzovací tag až za politikou.
•  v=DMARC1; p=none — záznam začína medzerou. Typicky vznikne kopírovaním hodnoty z návodu do DNS panela.
• v=DMARC1 p=reject — za verziou chýba bodkočiarka, takže hodnotou verzie je celé DMARC1 p=reject.
• v=DMARC2; p=reject — verzia, ktorá neexistuje; jediná platná je DMARC1.

Tvary, ktoré štandard pripúšťa, ale servery ich aj tak zahadzujú

Tu treba byť presný: podľa gramatiky v sekcii 4.8 sú tieto dva zápisy v poriadku. Napriek tomu ich tri zo štyroch rozšírených implementácií, ktorých zdrojový kód sme v septembri 2026 čítali (OpenDMARC, rspamd, go-msgauth, Mail::DMARC), zahodia — ich filter nad odpoveďou z DNS je prísnejší než ich vlastný parser tagov.

• V=DMARC1; p=reject — veľké V v mene tagu.
• v = DMARC1; p=reject — medzery okolo =.

Netvrdíme teda, že ich zakazuje štandard. Tvrdíme, že s nimi ochrana v praxi neplatí, a oprava stojí jeden znak.

Prečo je to horšie než chýbajúci záznam

• Falošný pokoj. V DNS je vidieť p=reject, takže doména vyzerá chránene. Podvrhnutá pošta pritom prechádza ďalej.
• Nechodia reporty. Adresa v rua= je súčasťou záznamu, ktorý príjemca zahodil, takže sa o spoofingu nedozviete.
• Pasca pri oprave. Návod „pridajte DMARC záznam“ vás zvedie publikovať druhý TXT záznam vedľa toho existujúceho. RFC 9989 sekcia 4.10 však hovorí, že keď sú na názve _dmarc dva záznamy, neplatí ani jeden. Skončíte horšie, než ste začali.

Ako to opraviť

Opravujte existujúci záznam, nepridávajte nový.

1. Vypíšte, čo je publikované: dig +short TXT _dmarc.example.cz (na Windows nslookup -type=TXT _dmarc.example.cz).
2. V DNS paneli ten jeden záznam upravte. Všetko za verzovacím tagom nechajte tak — politiku, rua= aj ostatné tagy.
3. Uložte a počkajte, kým vyprší TTL (typicky minúty až hodiny).

zle:     v=dmarc1; p=quarantine; rua=mailto:dmarc@example.cz
správne: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.cz

Pozor na dve veci, ktoré do hodnoty pridáva editor DNS, nie vy: medzeru na začiatku a úvodzovky navyše vnútri hodnoty. Po uložení si preto záznam vždy prečítajte späť cez dig, nie z formulára.

Overenie

Keď dig vráti presne jeden záznam začínajúci v=DMARC1;, je hotovo. Potvrdiť to môžete novým skenom na vulscan.app — kontrola DMARC je súčasťou bezplatného skenu.

Až potom má zmysel riešiť silu politiky: čo znamená p=none, p=quarantine a p=reject a v akom poradí ich nasadzovať, rozoberá článok Doména nemá DMARC záznam.

Referencie

• Vulscan docs: DMARC od nuly
• Vulscan docs: SPF
• RFC 9989 — DMARC — sekcia 4.7 (verzovací tag), 4.8 (gramatika záznamu), 4.10 (dva záznamy = neplatí žiadny)