Doména nemá DMARC záznam

Čo to je

Vaša doména nemá DNS záznam _dmarc.example.cz typu TXT. DMARC hovorí prijímajúcim e-mailovým serverom (Gmail, Seznam, Outlook), čo majú robiť, keď dostanú správu, ktorá sa tvári ako od example.cz, ale nesplní SPF ani DKIM kontrolu.

Bez DMARC je odpoveď „rozhodnite sa sami“ — a veľkí poskytovatelia v praxi spoofovanú správu doručia.

Prečo je to problém

Ktokoľvek môže poslať e-mail v mene vašej domény. Konkrétne:

Ako to opraviť

DMARC nasadzujte po fázach. Skok rovno na vynucujúcu politiku skôr, než si prečítate reporty, ublíži legitímnemu mailingu.

Fáza 1 (1-2 týždne) — monitoring

Vytvorte DNS TXT záznam:

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

p=none nevyjadruje žiadnu preferenciu k tomu, čo má príjemca s neprechádzajúcou poštou urobiť (RFC 9989, sekcia 4.7) — každý si ju filtruje ďalej po svojom. Čo tento záznam skutočne žiada, sú reporty: rua je e-mail, kam vám poskytovatelia budú posielať agregované reporty.

Fáza 2 (po 1-2 týždňoch) — karanténa

Z reportov vidíte všetky legitímne servery, ktoré posielajú pod vaším menom (Mailchimp, Mailgun, Microsoft 365, vlastný server). Doplňte ich do SPF a DKIM. Potom eskalujte:

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

p=quarantine je plnohodnotná vynucujúca politika (RFC 9989, sekcia 3.2.9) — pošta, ktorá neprejde DMARC, skončí v spame namiesto v doručenej pošte.

Nepridávajte sem pct=10. Staršie návody používajú pct= na postupný nábeh politiky na časť neprechádzajúcej pošty, lenže tag pct bol z DMARC odstránený v RFC 9989 (máj 2026) a konformný príjemca ho ignoruje. U každého príjemcu, ktorý na RFC 9989 prešiel, sa teda p=quarantine; pct=10 uplatní na 100 % neprechádzajúcej pošty, nie na 10 % — a pct=0 ako „bezpečný test“ je tam plné vynucovanie. Pretože nemáte pod kontrolou, kto z príjemcov už prešiel, na postupný nábeh sa pct spoľahnúť nedá vôbec.

Na testovací režim definuje RFC 9989 v sekcii 4.7 tag t=. U príjemcu, ktorý na RFC 9989 prešiel, žiada t=y o politiku o úroveň miernejšiu, než akú publikujete, a reporty pritom chodia ďalej: p=quarantine; t=y sa u neho vyhodnotí ako p=none, p=reject; t=y ako p=quarantine.

t= a pct ale nie sú to isté: pct zo štandardu zmizol a príjemcovia podľa RFC 9989 ho ignorujú, zatiaľ čo t= je jeho platná náhrada — funguje však len u príjemcov, ktorí na RFC 9989 prešli. Tag je v RFC 9989 nový (príloha A.6) a sekcia 4.8 prikazuje príjemcovi ignorovať tagy, ktoré nepozná: ten, kto na RFC 9989 neprešiel, uplatní vašu publikovanú politiku v plnom rozsahu — p=quarantine; t=y tam pošle do karantény všetko, čo DMARC neprejde. Tag t= preto publikujte len k politike, ktorej plný dopad ste ochotní prijať; jedinou fázou, ktorá nikde nič nevynucuje, zostáva p=none. Keď test dokončíte, tag odoberte (alebo nastavte t=n).

Fáza 3 (voliteľná) — reject

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

Pri p=reject príjemca spoofovanú správu rovno odmietne. RFC 9989 sekcia 7.4 na to viaže dve podmienky: doména, ktorá publikuje p=reject, musí podpisovať poštu platným DKIM a nesmie sa spoliehať len na SPF (to sa pri preposielaní rozbije), a domény, ktoré hostia používateľov, ktorí by mohli písať do internetových mailing listov, by p=reject nemali publikovať vôbec.

Ak na vás niektorá z tých podmienok sedí, zostať na p=quarantine je legitímny cieľový stav, nie nedokončený rollout.

Overenie

Po každej fáze si záznam overte novým skenom na vulscan.app — kontrola DMARC (spolu s SPF) je súčasťou bezplatného skenu. Agregované reporty chodia na adresu z rua ako XML prílohy; na prvú orientáciu stačí sledovať, ktoré servery posielajú poštu, ktorá DMARC neprechádza.

Referencie