DMARC bez výpadku pošty: k odmítání zpráv přejděte až po kontrole

Pro doménu používající Google Workspace a DNS v Cloudflare ponechte jediný SPF záznam, zapněte DKIM a DMARC spusťte s politikou p=none. Postup Cloudflare pro Google Workspace doporučuje přejít na p=quarantine nebo p=reject teprve po kontrole reportů a ověření legitimní odchozí pošty. Předčasné odmítání může zasáhnout i zprávy ze služeb, na které správce při nastavení zapomněl.

Než politiku zpřísníte, zmapujte všechny služby odesílající jménem vaší domény a připravte adresu pro agregované reporty. Pokyny Google k DMARC doporučují vyhrazenou schránku nebo skupinu a kontrolu pošty od dalších poskytovatelů. Pro úspěšné ověření DMARC stačí SPF nebo DKIM, avšak úspěšná metoda musí zároveň odpovídat doméně ve viditelné adrese From.

Jeden SPF záznam pro všechny relevantní odesílatele

V Cloudflare otevřete DNS → Records a na kořeni domény, označeném @, vyhledejte TXT záznam začínající v=spf1. Pokud už existuje, upravte jej místo přidání dalšího: více SPF záznamů na stejném názvu vede k chybě ověření. Ostatní TXT záznamy na kořeni domény, například záznam pro ověření vlastnictví, tím nejsou dotčeny.

Jestli poštu z domény odesílá pouze Google Workspace, nastavte TXT záznam s názvem @ a obsahem v=spf1 include:_spf.google.com ~all. Před použitím tohoto příkladu projděte také webové formuláře, fakturační systémy, rezervační služby a nástroje pro hromadné rozesílání. Přítomnost Gmailu ve firmě sama o sobě neznamená, že přes Google odchází každá zpráva s její doménou ve From.

U další služby zjistěte její skutečnou odesílací konfiguraci a případný mechanismus include doplňte do téhož SPF záznamu před závěrečné ~all. Hodnotu poskytovatele neodhadujte: musí odpovídat jeho pokynům. Pokud služba používá vlastní doménu v obálkové adrese Return-Path, může její SPF projít, ale s doménou ve From se pro DMARC neshodovat. Pak pomůže správně nastavený podpis DKIM s vaší doménou nebo konfigurace obálkové domény, kterou daná služba podporuje.

DKIM zveřejněte v Cloudflare a spusťte v Google

V administraci Google přejděte do Apps → Google Workspace → Gmail → Authenticate email, vyberte doménu a vygenerujte záznam DKIM. V Cloudflare vytvořte TXT záznam s názvem selektoru zobrazeným administrací, obvykle google._domainkey. Jako obsah vložte celý vygenerovaný veřejný klíč; hodnota začíná v=DKIM1; k=rsa; p= a pokračuje samotným klíčem. Uvedený začátek je jen pomůcka k rozpoznání záznamu, nikoli použitelná hodnota k vložení.

Po uložení záznamu se vraťte do administrace Google a zvolte Start authentication. Samotné zveřejnění klíče ještě neznamená, že Google zprávy podepisuje. Spravujete-li více odesílacích domén, vytvořte pro každou vlastní DKIM klíč. Při tomto nastavení autentizace neměňte MX záznamy: ty určují, kam přichází pošta, zatímco SPF, DKIM a DMARC řeší ověřování odesílaných zpráv.

DMARC nejprve sbírá reporty

Pro agregované reporty zřiďte funkční schránku nebo skupinu ve stejné doméně, například [email protected]. V Cloudflare přidejte TXT záznam s názvem _dmarc a obsahem v=DMARC1; p=none; rua=mailto:[email protected]. Doména example.com je ukázková; v adrese ji nahraďte vlastní doménou. Pokud už záznam _dmarc existuje, upravte jej místo vytváření druhého.

Politika p=none nežádá příjemce, aby zprávy kvůli neúspěšnému DMARC přesouvali do spamu či odmítali. Stále se však mohou uplatnit jejich ostatní filtry, takže sama tato politika doručení nezaručuje. Agregované reporty ukazují odesílající zdroje a výsledky autentizace; neprokazují doručení každé jednotlivé zprávy. U kontrolních zpráv z Gmailu i dalších používaných služeb proto prohlédněte hlavičky a ověřte výsledek DMARC.

Rozhodující je shoda s doménou ve From. SPF ověřuje odesílající server pro obálkovou doménu, kdežto DKIM podpis pro doménu uvedenou u podpisu. DMARC uspěje, když projde alespoň jedna z těchto metod a její doména je správně sladěná s From. Právě proto není přidání další služby do SPF automatickou opravou jejího neúspěšného DMARC.

Podle čeho přejít na quarantine a reject

Doporučený postup Google počítá s nastavením SPF a DKIM nejméně 48 hodin před DMARC, následným sledováním p=none alespoň týden a teprve potom s omezeným zavedením přísnější politiky. Týden obvykle poskytne reprezentativní reporty, ale služba rozesílající jen občas se v nich ještě nemusí objevit. U politik quarantine a reject lze podíl neověřených zpráv, na které se politika vztahuje, řídit parametrem pct.

• Ponechte p=none, pokud v reportech selhává známý odesílatel, chybí kontrolní odeslání z některého systému nebo nedokážete určit významný zdroj pošty. Nejprve opravte jeho SPF, DKIM nebo shodu domén.
• Přejděte na p=quarantine, jakmile běžná pošta i zmapované služby procházejí DMARC a neúspěšné zprávy umíte vyhodnotit. Pro omezený začátek může záznam znít v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]. Hodnota pct=10 je příklad k přizpůsobení, nikoli univerzální volba.
• Přejděte na p=reject, až když také během karantény reporty a kontrolní zprávy ukazují úspěšné ověření legitimních zdrojů. Existující záznam pak může mít podobu v=DMARC1; p=reject; rua=mailto:[email protected]. Bez pct se přísná politika uplatní na všechny zprávy, které nesplní DMARC.

Po zpřísnění dál sledujte reporty a doručování z jednotlivých služeb. Nový odesílatel nebo změna jeho nastavení může začít selhávat, přestože dosavadní provoz procházel. Pokud se to projeví na legitimní poště, opravte jeho autentizaci; při bezprostředním dopadu lze dočasně vrátit mírnější politiku.

Přečtěte si také:

• AI přidává skrytou práci: kontrolu výstupů nese zaměstnanec
• IPID získal 16 milionů dolarů, kontrola příjemce míří přes 50 zemí
• CVC bere 30 % CDN77, zakladatel si ponechá kontrolu