Doména nemá DMARC záznam

Co to je

Vaše doména nemá DNS záznam _dmarc.example.cz typu TXT. DMARC říká přijímajícím e-mailovým serverům (Gmail, Seznam, Outlook), co mají dělat, když dostanou zprávu, která se tváří jako od example.cz, ale nesplní SPF ani DKIM kontrolu.

Bez DMARC je odpověď „rozhodněte se sami“ — a velcí provideři v praxi spoofovanou zprávu doručí.

Proč je to problém

Kdokoliv může poslat e-mail jménem vaší domény. Konkrétně:

Jak to opravit

DMARC nasazujte po fázích. Skok rovnou na vynucující politiku dřív, než si přečtete reporty, ublíží legitimnímu mailingu.

Fáze 1 (1-2 týdny) — monitoring

Vytvořte DNS TXT záznam:

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

p=none nevyjadřuje žádnou preferenci k tomu, co má příjemce s neprocházející poštou udělat (RFC 9989, sekce 4.7) — každý si ji filtruje dál po svém. Co tenhle záznam skutečně žádá, jsou reporty: rua je e-mail, kam vám provideři budou posílat agregované reporty.

Fáze 2 (po 1-2 týdnech) — karanténa

Z reportů vidíte všechny legitimní servery, které posílají vaším jménem (Mailchimp, Mailgun, Microsoft 365, vlastní server). Doplňte je do SPF a DKIM. Pak eskalujte:

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

p=quarantine je plnohodnotná vynucující politika (RFC 9989, sekce 3.2.9) — pošta, která neprojde DMARC, skončí ve spamu místo v doručené poště.

Nepřidávejte sem pct=10. Starší návody používají pct= k postupnému náběhu politiky na část neprocházející pošty, jenže tag pct byl z DMARC odstraněn v RFC 9989 (květen 2026) a konformní příjemce ho ignoruje. U každého příjemce, který na RFC 9989 přešel, se tedy p=quarantine; pct=10 uplatní na 100 % neprocházející pošty, ne na 10 % — a pct=0 jako „bezpečný test“ je tam plné vynucení. Protože nemáte pod kontrolou, kdo z příjemců už přešel, na postupný náběh se pct spolehnout nedá vůbec.

Na testovací režim definuje RFC 9989 v sekci 4.7 tag t=. U příjemce, který na RFC 9989 přešel, žádá t=y o politiku o úroveň mírnější, než jakou publikujete, a reporty přitom chodí dál: p=quarantine; t=y se u něj vyhodnotí jako p=none, p=reject; t=y jako p=quarantine.

t= a pct ale nejsou totéž: pct ze standardu zmizel a příjemci podle RFC 9989 ho ignorují, zatímco t= je jeho platná náhrada — funguje ovšem jen u příjemců, kteří na RFC 9989 přešli. Tag je v RFC 9989 nový (příloha A.6) a sekce 4.8 nařizuje příjemci ignorovat tagy, které nezná: ten, kdo na RFC 9989 nepřešel, uplatní vaši publikovanou politiku v plném rozsahu — p=quarantine; t=y tam pošle do karantény všechno, co DMARC neprojde. Tag t= proto publikujte jen k politice, jejíž plný dopad jste ochotni přijmout; jediná fáze, která nikde nic nevynucuje, zůstává p=none. Až test dokončíte, tag odeberte (nebo nastavte t=n).

Fáze 3 (volitelná) — reject

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

Při p=reject příjemce spoofovanou zprávu rovnou odmítne. RFC 9989 sekce 7.4 k tomu váže dvě podmínky: doména, která publikuje p=reject, musí podepisovat poštu platným DKIM a nesmí se spoléhat jen na SPF (to se při přeposílání rozbije), a domény, které hostují uživatele, kteří by mohli psát do internetových mailing listů, by p=reject neměly publikovat vůbec.

Pokud na vás některá z těch podmínek sedí, zůstat na p=quarantine je legitimní cílový stav, ne nedodělaný rollout.

Ověření

Po každé fázi si záznam ověřte novým skenem na vulscan.app — kontrola DMARC (spolu se SPF) je součástí bezplatného skenu. Agregované reporty chodí na adresu z rua jako XML přílohy; na první orientaci stačí sledovat, které servery posílají poštu, jež DMARC neprochází.

Reference