DMARC záznam je publikovaný, ale příjemci ho zahazují

Co to je

Na _dmarc.example.cz TXT záznam je, ale jeho verzovací tag není přesně v=DMARC1. Přijímající servery takový záznam přeskočí a s doménou zacházejí, jako by DMARC neměla vůbec.

Proto vám sken neříká, že záznam chybí — vy ho v DNS vidíte. Říká, že ho příjemci nepoužijí. Dopad je přitom stejný jako u chybějícího záznamu: nikdo nevynucuje nic a žádné reporty nechodí.

Které tvary to jsou

Vždycky jde o začátek záznamu, ne o politiku p= za ním. Rozlišujeme dvě skupiny.

Tvary, které standard nařizuje ignorovat

RFC 9989 v sekci 4.7 požaduje, aby tag v= byl první a měl hodnotu přesně DMARC1; jinak má příjemce celý záznam ignorovat.

• v=dmarc1; p=reject — hodnota napsaná malými písmeny.
• v=DMARC10; p=reject — za DMARC1 je něco navíc.
• p=reject; v=DMARC1 — verzovací tag až za politikou.
•  v=DMARC1; p=none — záznam začíná mezerou. Typicky vznikne kopírováním hodnoty z návodu do DNS panelu.
• v=DMARC1 p=reject — za verzí chybí středník, takže hodnotou verze je celé DMARC1 p=reject.
• v=DMARC2; p=reject — verze, která neexistuje; jediná platná je DMARC1.

Tvary, které standard připouští, ale servery je stejně zahazují

Tady je potřeba být přesný: podle gramatiky v sekci 4.8 jsou tyhle dva zápisy v pořádku. Přesto je tři ze čtyř rozšířených implementací, jejichž zdrojový kód jsme v září 2026 četli (OpenDMARC, rspamd, go-msgauth, Mail::DMARC), zahodí — jejich filtr nad odpovědí z DNS je přísnější než jejich vlastní parser tagů.

• V=DMARC1; p=reject — velké V ve jménu tagu.
• v = DMARC1; p=reject — mezery kolem =.

Netvrdíme tedy, že je zakazuje standard. Tvrdíme, že s nimi ochrana v praxi neplatí, a oprava stojí jeden znak.

Proč je to horší než chybějící záznam

• Falešný klid. V DNS je vidět p=reject, takže doména vypadá chráněně. Podvržená pošta přitom prochází dál.
• Nechodí reporty. Adresa v rua= je součástí záznamu, který příjemce zahodil, takže se o spoofingu nedozvíte.
• Past při opravě. Návod „přidejte DMARC záznam“ vás svede publikovat druhý TXT záznam vedle toho stávajícího. RFC 9989 sekce 4.10 ale říká, že když jsou na názvu _dmarc dva záznamy, neplatí ani jeden. Skončíte hůř, než jste začali.

Jak to opravit

Opravujte stávající záznam, nepřidávejte nový.

1. Vypište, co je publikované: dig +short TXT _dmarc.example.cz (na Windows nslookup -type=TXT _dmarc.example.cz).
2. V DNS panelu ten jeden záznam upravte. Vše za verzovacím tagem nechte být — politiku, rua= i ostatní tagy.
3. Uložte a počkejte, než vyprší TTL (typicky minuty až hodiny).

špatně:  v=dmarc1; p=quarantine; rua=mailto:dmarc@example.cz
správně: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.cz

Pozor na dvě věci, které do hodnoty přidává editor DNS, ne vy: mezeru na začátku a uvozovky navíc uvnitř hodnoty. Po uložení si proto záznam vždycky přečtěte zpátky přes dig, ne z formuláře.

Ověření

Když dig vrátí přesně jeden záznam začínající v=DMARC1;, je hotovo. Potvrdit to můžete novým skenem na vulscan.app — kontrola DMARC je součástí bezplatného skenu.

Teprve potom má smysl řešit sílu politiky: co znamená p=none, p=quarantine a p=reject a v jakém pořadí je nasazovat, rozebírá článek Doména nemá DMARC záznam.

Reference

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