# DMARC z p=none na p=reject za 30 dní Kanonická URL: https://brew.new/cs/blog/dmarc-p-none-to-reject-in-30-days Autor: Thomas Park Publikováno: 2026-10-04 Aktualizováno: 2026-10-04 DMARC je TXT záznam na `_dmarc.`, 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](https://redsift.com/blog/email-authentication-bespinlabs-redsift), zjistila, že nějakou politiku DMARC má 14,9 % z nich a `p=reject` vynucuje 2,5 %. Podle [zprávy z roku 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) 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](https://www.rfc-editor.org/rfc/rfc9989.html), navrhovaným standardem (Proposed Standard), který zároveň nahrazuje i RFC 9091, a k tomu [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) 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](https://www.rfc-editor.org/rfc/rfc7208.html#section-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. ```dns 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 ` 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) 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 `._domainkey.`. Nástroj, který podepisuje s `d=vendor-mail.example`, projde kontrolou DKIM, ale DMARC neprojde. Podle [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) 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](https://support.google.com/mail/answer/81126) 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. ```dns 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íčů](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) 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: | Režim | Tag | Doména, která prošla SPF/DKIM | Doména ve From | Zarovnáno? | |---|---|---|---|---| | Volné (relaxed, výchozí) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Ano, stejná organizační doména | | Striktní (strict) | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Ne, názvy se musí shodovat | | Kterýkoli | | `vendor.example.net` | `example.com` | Ne | 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 ![Časová osa 30denního plánu DMARC ve čtyřech fázích: 1. až 7. den p=none s reporty rua, 8. až 14. den oprava odesílatelů, 15. den p=quarantine, 22. den p=reject a od 30. dne BIMI, u každé fáze s přesným TXT záznamem.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *Záznam pro každou fázi. Do další fáze přejdi až po týdnu čistých reportů.* | Dny | Politika | Co udělat | Podmínka pro další fázi | |---|---|---|---| | 1 až 7 | `p=none` | Zveřejni záznam s `rua`, sepiš všechny zdroje | 7 dní reportů: Google, Yahoo a Microsoft | | 8 až 14 | `p=none` | Oprav DKIM a SPF, vyřaď nepoužívané odesílatele | Každý legitimní zdroj projde zarovnaným SPF nebo DKIM | | 15 až 21 | `p=quarantine` | Hlídej legitimní poštu, která skončila v karanténě | 7 dní, kdy neselže žádný legitimní zdroj | | 22 až 30 | `p=reject` | Dál čti reporty, přidej `np=reject` | Týden stabilního provozu | | 30 a dál | `p=reject` | Začni s BIMI | Vydaný certifikát | 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 ```dns _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.`. 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ů](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) 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: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` 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ď: | Co vidíš v reportu | Pravděpodobná příčina | Co dělat | |---|---|---| | Zarovnané DKIM nebo SPF projde | Správné nastavení | Nic | | DKIM a SPF projdou pro domény dodavatele | SaaS nástroj používá vlastní identitu | Zapni vlastní DKIM | | Zarovnané DKIM projde, SPF selže, IP adresa poskytovatele schránek nebo e-mailové konference | Přeposílání nebo e-mailová konference | Obvykle nic. Zarovnané DKIM přeposlání přežije | | Žádné DKIM, SPF selže, IP adresy, které nejde přiřadit | Spoofing | Nic. Právě tohle `p=reject` zastaví | 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](https://support.google.com/mail/answer/14229414) 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 ```dns _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 ```dns _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í: | Požadavek | Podrobnosti | Zdroj | |---|---|---| | Politika DMARC | `p=quarantine` nebo `p=reject` na organizační doméně i na doméně ve From | Návrh BIMI | | Politika pro subdomény | Pokud je `sp` zveřejněné, nesmí být `none` | Návrh BIMI | | Procento | Quarantine nesmí mít `pct` pod 100 | Návrh BIMI | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, element ``, žádné skripty ani externí odkazy, žádné `x=` ani `y=` na kořenovém elementu | BIMI Group | | Certifikát | Gmail potřebuje VMC (registrovaná ochranná známka, s fajfkou) nebo CMC (bez ochranné známky, bez fajfky) | Google | [Návrh BIMI](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) 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](https://bimigroup.org/creating-bimi-svg-logo-files/) 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](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). Záznam podle [implementačního průvodce BIMI Group](https://bimigroup.org/implementation-guide/): ```dns 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í. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Hranice | Zhruba 5 000 denně na osobní účty Gmail, za každou primární doménu, po dosažení natrvalo | Hromadní odesílatelé, bez konkrétního čísla | Víc než 5 000 denně na outlook.com, hotmail.com a live.com, za každou doménu ve From | | SPF a DKIM | Obojí | Obojí | Obojí musí projít | | DMARC | Záznam je povinný, `p=none` stačí | Alespoň `p=none`, `rua` důrazně doporučeno | Alespoň `p=none` | | Zarovnání | SPF nebo DKIM | SPF nebo DKIM, volné stačí | SPF nebo DKIM | | Při nesplnění | Dočasné i trvalé odmítání zpráv od listopadu 2025 | Neuvedeno | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Zdroje: Google – [pokyny pro odesílatele](https://support.google.com/mail/answer/81126) a [časté dotazy](https://support.google.com/mail/answer/14229414), Yahoo – [doporučené postupy pro odesílatele](https://senders.yahooinc.com/best-practices/), Microsoft – [oznámení z dubna 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) a [stránka podpory k chybě 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com). 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](/cs/blog/agent-email-deliverability), a náš [průvodce doručitelností](/cs/blog/email-deliverability). ## DMARC na odesílací doméně v Brew [Nastavení domény](https://docs.brew.new/get-started/verify-your-sending-domain) 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: ```dns ; 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](/cs/blog/transactional-emails), 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](https://bimigroup.org/understanding-bimi-certificate-types/) několik poskytovatelů, mezi nimi Yahoo a Fastmail, zobrazuje i loga, která odesílatel deklaruje sám, bez certifikátu.