DMARC je TXT záznam na _dmarc.<your domain>, který přijímajícím serverům říká, co mají dělat s poštou, jež používá tvou doménu v hlavičce From a neprojde kontrolou SPF ani DKIM se zarovnáním (alignment), a kam mají posílat reporty. p=none jen žádá o reporty, p=quarantine žádá přijímající servery, aby s poštou, která kontrolou neprošla, zacházely jako s podezřelou, a p=reject je žádá, aby ji odmítly.

Gmail, Yahoo i Microsoft od hromadných odesílatelů p=none přijmou, a tak u něj spousta domén zůstane: o spoofingu dostávají reporty, ale nic neblokují. Analýza 73,3 milionu domén od firmy Red Sift, citovaná v dubnu 2026, zjistila, že nějakou politiku DMARC má 14,9 % z nich a p=reject vynucuje 2,5 %. Podle zprávy z roku 2025 od EasyDMARC, další firmy zaměřené na DMARC, používá p=reject 62,7 % firem ze žebříčku Fortune 500, které DMARC mají, oproti 15,2 % firem ze žebříčku Inc. 5000.

Tady je 30denní plán, jak se záznam po záznamu dostat na p=reject. Je pro doménu, ze které posílá firemní pošta, jedna nebo dvě ESP, helpdesk a fakturační nástroj. Třicet dní stačí pro odesílací subdoménu. Doména, kterou zaměstnanci používají pro běžnou poštu, potřebuje víc času.

Hlavní body

• První den zveřejni v=DMARC1; p=none; rua=mailto:.... Bez rua přijímající servery souhrnné reporty posílat nesmějí.
• Každý legitimní odesílatel musí projít SPF nebo DKIM se zarovnáním na tvou doménu ve From. U většiny nástrojů to znamená podepisovat DKIM tvou doménou.
• Drž v SPF nejvýše 10 položek, které se dotazují DNS, včetně vnořených include, jinak veškerá tvoje pošta skončí s permerror.
• 15. den přejdi na p=quarantine a 22. den na p=reject, pokaždé až po týdnu čistých reportů. U domény, kterou zaměstnanci používají pro běžnou poštu, žádá RFC 9989 na každou z prvních dvou fází měsíc.
• RFC 9989 (květen 2026) označuje pct jako historický. Postupné navyšování přes pct=10 a pct=50 vynech.
• BIMI potřebuje p=quarantine nebo p=reject na organizační doméně, žádné sp=none, logo ve formátu SVG Tiny PS a pro Gmail certifikát VMC nebo CMC.

Co se v DMARC změnilo v roce 2026

V květnu 2026 nahradila organizace IETF dokument RFC 7489, informativní RFC z roku 2015, specifikací DMARCbis: RFC 9989, navrhovaným standardem (Proposed Standard), který zároveň nahrazuje i RFC 9091, a k tomu RFC 9990 pro souhrnné reporty. Pro tento plán jsou důležité tři změny:

• pct je historický. Podle přílohy A.6 se „obvykle neuplatňoval přesně, ledaže byla zadaná hodnota 0 nebo 100“.
• t=y nahrazuje pct=0. Přijímající servery uplatní o stupeň mírnější politiku, než je ta tvoje, takže p=reject; t=y funguje jako quarantine. Je to přepínač pro testování.
• np je nový. Vztahuje se na subdomény, které v DNS neexistují, a starší přijímající servery ho musí ignorovat.

Organizační doménu navíc už neurčuje Public Suffix List, ale procházení stromu DNS (DNS tree walk).

Tři záznamy, na kterých DMARC stojí

DMARC projde, když projde SPF nebo DKIM a doména, která kontrolou prošla, je zarovnaná s doménou ve From. Stačí jeden úspěšný výsledek se zarovnáním.

SPF a limit 10 dotazů

SPF autorizuje servery pro doménu obálky (MAIL FROM neboli return-path), což je jediná identita, kterou DMARC používá; HELO to není. RFC 7208, oddíl 4.6.4 omezuje položky, které se dotazují DNS, na 10: include, a, mx, ptr, exists a redirect, a to včetně všech vnořených include. ip4, ip6 a all se nepočítají. Při překročení limitu je výsledkem permerror. Stejný oddíl povoluje nejvýš dva „void lookups“, tedy dotazy bez výsledku, obvykle include pro název hostitele, který už neexistuje.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

Tenhle záznam spotřebuje 4 dotazy, ještě než započítáš, co do svých záznamů vnořuje každý dodavatel, takže každý include rozklíčuj příkazem dig +short TXT <name> až na konec řetězce. Pokud se potřebuješ vejít do limitu 10 dotazů, odstraň nástroje, které už nepoužíváš, nebo dej každé ESP vlastní subdoménu pro return-path, například bounce.example.com, s vlastním rozpočtem 10 dotazů. Microsoft ve svém návodu k nastavení SPF doporučuje na doménách, které používají i DKIM a DMARC, zakončit záznam pomocí -all.

Mnoho ESP ve výchozím nastavení používá vlastní doménu pro return-path, která s tvou doménou zarovnaná není. Nastav vlastní return-path, nebo se spolehni na DKIM.

DKIM: 2048bitové klíče, selektory a rotace

DKIM podepisuje každou zprávu doménou d= a selektorem s=; přijímající server si klíč stáhne z <selector>._domainkey.<d domain>. Nástroj, který podepisuje s d=vendor-mail.example, projde kontrolou DKIM, ale DMARC neprojde.

Podle RFC 8301 musí podepisující strana používat klíče RSA o délce alespoň 1024 bitů a měla by používat 2048 bitů. Google ve svých pokynech pro odesílatele uvádí totéž pro poštu na osobní účty Gmail. Klíč o délce 2048 bitů překračuje limit 255 znaků na jeden řetězec TXT, takže se do záznamu vkládá jako několik řetězců v uvozovkách, které většina poskytovatelů DNS rozdělí za tebe.

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

Každému odesílajícímu systému dej vlastní selektor a žádný název nepoužívej dvakrát. Datum v názvu, třeba s202610, udrží historii přehlednou. Doporučené postupy M3AAWG pro rotaci klíčů radí klíče obměňovat alespoň jednou za šest měsíců:

1. Zveřejni nový selektor a počkej, až se záznam rozšíří.
2. Přepni podepisování na nový klíč.
3. Starý veřejný klíč nech v DNS ještě 7 až 30 dní, aby se daly ověřit zprávy, které jsou zrovna na cestě.
4. Starý selektor vyřaď prázdným p=. Nemaž ho.

Zarovnání: volné, nebo striktní

RFC 9989 definuje dva režimy:

RFC 9989 poznamenává, že „téměř všichni vlastníci domén shledali volné zarovnání dostačujícím“. aspf ani adkim proto neuváděj. Striktní zarovnání SPF rozbije obvyklý return-path na subdoméně.

30denní plán

Záznam pro každou fázi. Do další fáze přejdi až po týdnu čistých reportů.

Pokud ve druhém týdnu narazíš na zdroj, který nikdo neumí opravit, zůstaň na p=none. Odmítat vlastní faktury je horší než zavést vynucení později.

1. až 7. den: zveřejni p=none s reporty

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Reporty jsou XML soubory komprimované gzipem a od každého přijímajícího serveru chodí alespoň jednou denně, takže rua nasměruj na nástroj pro zpracování reportů, ne na člověka. Pokud je adresa na jiné organizační doméně, přijímající servery ji podle RFC 9990 ignorují, ledaže ji autorizuje záznam example.com._report._dmarc.<report domain>. Služby pro zpracování reportů tento záznam zveřejňují samy; u vlastních domén si ho přidej.

Zveřejni právě jeden záznam DMARC. Pokud po průvodcích nastavením zůstanou na _dmarc.example.com dva záznamy v=DMARC1, přijímající servery zahodí oba.

ruf vynech. RFC 9989 upozorňuje, že přijímající servery, které dbají na soukromí, z reportů o selhání hodně údajů odstraňují, nebo je vůbec neposílají, a Microsoft v častých dotazech ke svému oznámení pro odesílatele velkých objemů uvádí, že posílá reporty rua a reporty ruf posílat neplánuje.

Jak číst souhrnný report

RFC 9990 popisuje XML reporty, které chodí „denně (nebo častěji)“, jeden za každou doménu s politikou. Jeden záznam, upravený podle ukázky z RFC:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

V policy_evaluated jsou dkim a spf výsledky zarovnání a disposition říká, co přijímající server se zprávou udělal. auth_results obsahuje surové výsledky a jejich domény. Tady obě kontroly projdou pro vendor.example, takže obě neprojdou zarovnáním: dodavatel posílá tvým jménem, ale nepodepisuje se jako ty. Zapni u něj vlastní DKIM nebo ověření domény.

1. až 7. den: najdi neznámé odesílatele

Seskup záznamy podle source_ip, envelope_from a DKIM domain spolu se selector, seřaď je podle count a roztřiď:

IP adresu přiřadíš tak, že spustíš dig -x 192.0.2.123 +short a podíváš se na selektor, který často nese název dodavatele. Pak se zeptej finančního oddělení, podpory a obchodu, co všechno posílá jménem firmy: fakturace, helpdesk, pozvánky do kalendáře, kancelářské skenery.

Přeposlaná pošta a pošta z konferencí bude selhávat způsobem, který opravit nejde, a Google ve svých častých dotazech pro odesílatele pro ni zarovnání nevyžaduje, takže na ni nečekej.

8. až 14. den: oprav všechny legitimní zdroje

Postupuj od nejvyššího count dolů:

1. Firemní pošta (Google Workspace, Microsoft 365). Zapni DKIM v administrátorské konzoli, kde je to možné, s 2048bitovým klíčem, a ověř, že je include poskytovatele v SPF.
2. ESP a marketingové nástroje. Nastav ověření domény, aby podepisovaly s tvým d=, a pokud to nabízejí, i vlastní return-path.
3. Helpdesk, fakturace, CRM. Stejně jako u ESP. Pokud některý nástroj neumí podepisovat tvou doménou, použij subdoménu, za kterou podepisovat umí, nebo jeho vlastní doménu.
4. Nepoužívané nástroje. Odstraň jejich include i selektory.

Pak znovu spočítej dotazy SPF.

15. den: p=quarantine

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Karanténa obvykle znamená složku se spamem. Hlídej legitimní zdroje s dispozicí quarantine. Na zkoušku můžeš nastavit p=quarantine; t=y, které přijímající servery řídící se RFC 9989 žádá, aby uplatnily none. RFC je ale staré jen pár měsíců a t zatím nerespektují všechny přijímající servery.

22. den: p=reject

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"

Přijímající servery, které p=reject respektují, odmítnou nevyhovující poštu už během relace SMTP. RFC 9989 jim ale ukládá zprávu dát do karantény, pokud je politika jejich jediným důkazem, takže část pošty skončí ve spamu.

Stejné RFC uvádí, že doména s p=reject „SE NESMÍ spoléhat pouze na SPF“ a musí podepisovat pomocí DKIM, protože přeposílání rozbije SPF, ale DKIM ne. Nejdřív proto ověř zarovnané DKIM u všech zdrojů.

rua si nech napořád. Nový nástroj z příštího čtvrtletí se ti v reportech objeví dřív než ve frontě podpory.

Kdy plán natáhnout

RFC 9989 v oddílu 7.4 uvádí, že domény, jejichž uživatelé přispívají do e-mailových konferencí, by p=reject zveřejňovat „NEMĚLY“, a pokud to udělají, měly by nejdřív strávit „alespoň měsíc“ na p=none a „stejně dlouhou dobu“ na p=quarantine. To se týká většiny hlavních firemních domén, takže tam dej každé z prvních dvou fází měsíc. Subdoména, kterou používá jen tvoje ESP, provoz z konferencí nemá a může zůstat u 30denního tempa.

Politika pro subdomény: sp= a np=

p platí pro doménu i její subdomény. sp ho přepisuje pro existující subdomény, np pro neexistující. Subdoména s vlastním záznamem se řídí tímto záznamem a RFC 9989 tam sp ignoruje.

Vyhrazená odesílací subdoména jako mail.example.com, kterou používá jedna ESP s ověřeným SPF a DKIM, může zveřejnit p=reject hned od prvního dne. p=none; sp=reject na hlavní doméně chrání subdomény, zatímco dotahuješ hlavní doménu, ale zablokuje BIMI.

Zaparkované domény by měly zveřejnit v=spf1 -all, jak doporučuje Microsoft ve svém návodu k SPF, a k tomu v=DMARC1; p=reject; na _dmarc.

Od 30. dne: BIMI

BIMI zobrazuje tvoje logo vedle ověřené pošty ve schránkách, které ho podporují:

Návrh BIMI je v revizi 14 (květen 2026) a pořád jde o Internet-Draft psaný podle RFC 7489, odtud pct. pct vynech a nenastavuj t=y.

Pravidlo organizační domény zaskočí odesílatele ze subdomén: když má mail.example.com nastavené p=reject a example.com p=none, přijímající servery logo zobrazit nesmějí, takže plán musí dokončit i hlavní doména.

Pokyny BIMI Group k SVG doporučují čtvercové logo umístěné na střed, na jednobarevném pozadí a menší než 32 kB. Google přidal podporu CMC v září 2024. Záznam podle implementačního průvodce BIMI Group:

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

Registrace ochranné známky trvá měsíce, takže pokud chceš VMC, začni hned.

Co vyžadují Gmail, Yahoo a Microsoft

Ani jeden z nich nevyžaduje vynucení, jen záznam DMARC a zarovnání.

Zdroje: Google – pokyny pro odesílatele a časté dotazy, Yahoo – doporučené postupy pro odesílatele, Microsoft – oznámení z dubna 2025 a stránka podpory k chybě 5.7.515. Microsoft začal pravidla vynucovat 5. května 2025 poté, co aktualizace z 29. dubna změnila postup z přesouvání do složky nevyžádané pošty na odmítání.

Google ve svých častých dotazech uvádí, že zarovnání SPF i DKIM „se časem stane požadavkem na odesílatele“, takže ve druhém týdnu zarovnej obojí. K odhlašování a míře spamu si přečti, co platí dál, když tvoje e-maily posílá agent, a náš průvodce doručitelností.

DMARC na odesílací doméně v Brew

Nastavení domény v Brew vyžaduje:

• DKIM, TXT záznam se selektorem ._domainkey pod tvou odesílací doménou. Povinné.
• SPF, MX a TXT záznam na send.<your sending domain>, což je return-path Brew. Povinné.
• DMARC, TXT záznam na _dmarc.<your sending domain>. Volitelné, ale doporučené.
• CNAME pro sledování prokliků, jen pokud používáš vlastní sledovací subdoménu.

Jakmile se SPF a DKIM ověří, doména může odesílat a Brew k ní navrhne odpovídající hodnotu DMARC:

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Vyhrazená subdoména dostane p=reject, protože z ní před ověřením SPF a DKIM pro Brew nic neodchází. Hlavní doména dostane p=none, protože z ní nejspíš posílají i tvoje další nástroje, takže na ni použij plán popsaný výše. Zarovnání zůstává volné, protože return-path send.<domain> je zarovnaný jen ve volném režimu.

Brew načte aktuální záznam _dmarc.<sending domain> při přidání domény, při ověření i při každé opakované kontrole. Výsledek uvidíš v sekci Domény, přes MCP v get_domain_health a v GET /v1/domains/{domainId}/health:

• dmarc_missing: varování s přesným záznamem, který máš přidat.
• dmarc_invalid: na daném názvu jsou dva záznamy DMARC nebo má záznam chybnou verzi, politiku či zdvojené tagy. Uvede, který záznam smazat.
• Ověřeno: Brew našel právě jeden platný záznam.

Automatické nastavení DNS zapíše DMARC, jen když žádný záznam neexistuje, takže ho nikdy nezdvojí. Kontrola probíhá na odesílací doméně, ne na nadřazené doméně, takže každé odesílací subdoméně dej vlastní záznam, včetně té pro transakční poštu, pokud obojí oddělíš, jak doporučuje dokumentace. Reporty čteš v nástroji, kam míří rua, a tam se taky rozhoduješ, kdy přejít na reject.

Časté dotazy

Jak dlouho zůstat na p=none, než přejdu na quarantine?

Dokud celý týden reportů neukáže, že všechny legitimní zdroje procházejí zarovnaným SPF nebo DKIM. U odesílací subdomény to obvykle trvá jeden až dva týdny. U domény, kterou zaměstnanci používají pro běžnou poštu, žádá RFC 9989 alespoň měsíc. Dva roky na p=none, aniž by kdokoli četl reporty, nemají žádnou cenu.

Je tag pct v DMARC zastaralý?

Ano. RFC 9989 vede pct jako „historický“ a jeho jediné spolehlivé hodnoty nahrazuje tagem t: t=y se chová jako pct=0, t=n jako pct=100. Starší přijímající servery pct možná ještě čtou, ale prostřední hodnoty nikdy neuplatňovaly konzistentně, takže postupuj po celých krocích.

Zablokuje p=reject moji přeposílanou poštu?

Prosté přeposlání obvykle rozbije SPF, ale DKIM ne, takže zarovnané DKIM dál projde. E-mailové konference, které upravují předmět nebo patičku, DKIM rozbijí a některé to vyrovnávají přepsáním hlavičky From. Nejlepší ochranou je zarovnané DKIM všude.

Vyžadují Gmail a Yahoo p=reject?

Ne. Oba chtějí po hromadných odesílatelích zveřejněný DMARC a přijmou p=none, stejně jako Microsoft nad 5 000 zpráv denně na Outlook.com. Vynucení zastaví spoofing a BIMI ho vyžaduje, ale žádný z těch tří poskytovatelů ho nepožaduje.

Potřebuju pro BIMI certifikát VMC?

Pro Gmail potřebuješ VMC, který vyžaduje registrovanou ochrannou známku a zobrazí fajfku, nebo CMC, který zobrazí logo bez ní. Podle BIMI Group několik poskytovatelů, mezi nimi Yahoo a Fastmail, zobrazuje i loga, která odesílatel deklaruje sám, bez certifikátu.