SPF, DKIM a DMARC: aby pošta nekončila ve spamu

Pošta z tvé domény končí ve spamu, protože přijímající server nedokáže ověřit, že opravdu pochází od tebe. Tohle opraví tři DNS záznamy: SPF vypisuje servery, které smějí odesílat za tvou doménu, DKIM přidává kryptografický podpis, který příjemce ověří veřejným klíčem ve tvé zóně, a DMARC říká příjemci, co udělat, když se ani jedno z toho neshoduje s adresou, kterou čtenář skutečně vidí. Všechny tři jsou záznamy TXT. Žádný z nich není těžký. Těžký je pojem uprostřed - alignment - a skoro každý příběh typu „nastavil jsem SPF a pořád to selhává“ je o tom, že tenhle pojem někdo přehlédl.

Jedna věc předem, protože mění to, co bys měl číst: RE:NODE nehostuje e-mail. Žádné schránky, žádné MX, žádný SMTP relay a ani DNS zóny - záznamy níže se vytvářejí tam, kam ukazují nameservery tvé domény, což je obvykle registrátor. Hostujeme aplikaci nebo web, který poštu odesílá, a té části se věnuje konec článku.

Dvě adresy From a proč je právě v tom celý problém#

SMTP zpráva má dva odesílatele a nemusejí se shodovat.

Obálkový odesílatel (envelope sender) je to, co odesílající server uvede v příkazu MAIL FROM během SMTP konverzace. Tam jdou bounce zprávy, zapisuje se do hlavičky Return-Path a v poštovním klientovi ho nikdy nikdo neuvidí. U formulářových mailerů je to často něco jako bounces@sendgrid.net nebo www-data@server42.hostingco.net.

Hlavičkové From je řádek uvnitř zprávy, který říká From: Anna <anna@example.com>. Je to jediný, který člověk čte, a je to ten, který chce phisher ovládnout.

SPF kontroluje obálkového odesílatele. DKIM zprávu podepisuje a pojmenovává podepisující doménu. Ani jedno samo o sobě neříká nic o adrese na řádku From: - a právě ta se zneužívá. DMARC existuje, aby tuhle mezeru zavřel: vyžaduje, aby jedna ze dvou úspěšných kontrol odkazovala na stejnou doménu jako viditelné From:, a umožňuje ti zveřejnit, co se má stát, když to nesplní ani jedna.

SPF: které servery smějí odesílat#

SPF je jeden záznam TXT na kořeni domény, který vypisuje každý zdroj, jenž smí uvést tvou doménu v obálkovém odesílateli.

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

Čti zleva doprava. Příjemce porovnává každý mechanismus s IP adresou připojujícího se serveru a zastaví se u první shody.

Kvalifikátor před all je verdikt pro všechno, co neodpovídalo: -all je tvrdé selhání, ~all měkké selhání, ?all neutrální a +all znamená „kdokoli smí odesílat za mě“, což je horší než žádný záznam.

O tom, jestli SPF záznam funguje, rozhodují čtyři pravidla:

1. Jeden záznam na doménu. Dva záznamy TXT začínající v=spf1 vyvolají trvalou chybu a všechno selže. Když přidáváš poskytovatele, uprav existující záznam; nevytvářej druhý.
2. Celkem deset DNS dotazů. include, a, mx, exists, ptr a redirect stojí po jednom a každý include jich uvnitř spotřebuje další. Nad deset je výsledek permerror, který většina příjemců bere jako selhání. Záznam se čtyřmi poštovními poskytovateli už bývá přes limit. Nahraď, co jde, rozsahy ip4:, nebo použij službu na zploštění (flattening), pokud musíš.
3. Mechanismus `ptr` je zastaralý. Odstraň ho. Je pomalý, nespolehlivý a RFC 7208 říká příjemcům, že ho smějí přeskočit.
4. SPF nepřežije přeposílání. Když univerzitní alias přepošle tvou poštu dál, server přeposílatele se připojí k cílovému serveru s tvou doménou stále v obálce, ale z adresy, kterou jsi nikdy nevypsal. SPF selže a nemůžeš s tím nic dělat. Není to chyba v tvém nastavení - je to důvod, proč DKIM existuje.

Začni s ~all, dokud ještě zjišťuješ, kdo všechno za tebe odesílá, a na -all přejdi, až když ti zprávy DMARC ukážou, že jsi našel všechny.

DKIM: podpis, který putuje se zprávou#

Odesílající server zahašuje tělo a vybranou sadu hlaviček, hash podepíše soukromým klíčem a přidá hlavičku DKIM-Signature, která jmenuje podepisující doménu (d=) a selector klíče (s=).

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;  s=s1; h=from:to:subject:date:message-id; bh=47DEQpj8HBSa...;  b=Xk9pLm2Qv8...

Příjemce vezme d= a s=, vyhledá s1._domainkey.example.com a najde veřejný klíč:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Body, na kterých v praxi záleží:

• Ve většině případů si to negeneruješ sám. Tvůj poštovní poskytovatel vygeneruje pár klíčů, soukromou půlku si ponechá a ty dostaneš záznam TXT k publikaci. Google Workspace, Microsoft 365, Postmark, Mailgun i ostatní fungují takhle a každý má vlastní selector.
• Každý odesílatel potřebuje vlastní selector. Transakční pošta z tvé aplikace, marketingová pošta z kampaňového nástroje a běžná pošta ze schránek jsou tři různé podpisové klíče na třech různých selectorech, všechny ve stejné zóně. Nekolidují.
• 2048bitový klíč se nevejde do jednoho DNS řetězce. Záznam TXT se skládá z kusů o nejvýš 255 znacích, takže klíč musí být rozdělen. Skoro každý DNS editor to dělá nenápadně sám; pár jich vyžaduje, abys ho rozdělil sám pomocí uvozovek. Pokud se publikace tváří úspěšně, ale ověření selhává, zkontroluj nejdřív tohle.
• DKIM přežije přeposílání, dokud něco zprávu neupraví. Mailing list, který připojí patičku nebo předsadí předmět, změní bajty, které byly podepsány, a podpis se rozbije. Na to byly vymyšleny hlavičky ARC a jako odesílatel to nemáš ve své moci.
• Klíče občas rotuj. Publikuj nový selector, přepni na něj odesílatele, počkej týden na poštu na cestě a starý záznam odstraň.

DMARC: politika, která oboje propojuje#

DMARC je jediný záznam TXT na _dmarc pod tvou doménou.

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

p=none na doručování nic nemění. Jen žádá příjemce, aby ti posílali zprávy, což je přesně to, co na začátku chceš: proud důkazů o tom, kdo odesílá jako tvá doména, než komukoli řekneš, aby poštu zahazoval. p=quarantine znamená složku spam. p=reject znamená, že přijímající server zprávu odmítne už během SMTP konverzace, takže odesílatel dostane bounce.

Souhrnné zprávy na rua jsou gzipované XML, jedna od každého příjemce za den, a nejsou určené ke čtení očima. Pusť je do jakéhokoli parseru zpráv DMARC - existují i zdarma - a dostaneš tabulku odesílajících IP adres, jejich výsledků SPF a DKIM a toho, zda byly aligned. Ta tabulka je smyslem celého cvičení.

Alignment je část, na které lidé narazí#

Tohle je pojem, který dává smysl každému zmatenému výsledku.

DMARC projde, když projde alespoň jedno z SPF nebo DKIM a doména, pro kterou prošlo, se shoduje s doménou ve viditelné hlavičce From:. Potřeba jsou obě poloviny. Zpráva může projít SPF čistě a přesto neprojít DMARC a právě tahle kombinace je nejčastější ticket podpory v celém tomto tématu.

Takhle to vzniká. Tvůj kontaktní formulář odesílá přes transakčního poskytovatele. Poskytovatel nastaví obálkového odesílatele na bounce@mail.provider.net, protože bounce zprávy se mají vracet k němu. SPF se kontroluje proti provider.net a projde - jejich záznam je v pořádku. Ale hlavička From: říká hello@example.com. provider.net není example.com, takže tenhle průchod není aligned a do DMARC nepřispívá ničím. Pokud DKIM podepisuje také s d=provider.net, DMARC selže úplně a tvoje p=reject zahodí tvůj vlastní kontaktní formulář.

Oprava je jedna ze dvou věcí a každý seriózní poskytovatel nabízí obě:

• Vlastní return path. Publikuješ CNAME, například bounces.example.com, který ukazuje do infrastruktury poskytovatele, ten ho použije jako obálkovou doménu a SPF teď projde pro subdoménu example.com. Při relaxed alignmentu - výchozím - subdoména odpovídá nadřazené doméně, takže DMARC je splněn.
• DKIM podepsaný tvou doménou. Publikuješ selector poskytovatele pod example.com a on podepisuje s d=example.com. Z obou je to robustnější varianta, protože přežije i přeposílání.

Relaxed alignment (r) přijímá jakoukoli subdoménu organizační domény: mail.example.com odpovídá example.com. Strict (s) vyžaduje přesnou shodu. Nech obojí relaxed, pokud k tomu nemáš konkrétní důvod, protože strict alignment rozbíjí vlastní return path bez bezpečnostního přínosu, na kterém na této úrovni záleží.

Nasazení bez ztráty pošty#

Na pořadí záleží. Publikovat p=reject první den na doméně, jejíž odesílatele jsi nezmapoval, znamená, že ti přestanou chodit faktury a nikdo ti to neřekne.

1. Vypiš všechny odesílatele. Schránky, kontaktní formulář na webu, obnovy hesel v aplikaci, fakturační nástroj, CRM, newsletter, helpdesk, monitorovací upozornění a cokoli, co před třemi lety nastavil někdo v účtárně. Tenhle krok trvá déle než všechny ostatní.
2. Nastav SPF a DKIM správně pro každého z nich. Jeden SPF záznam, který pokryje všechny v rámci limitu deseti dotazů; jeden selector DKIM na odesílatele, podepisující tvou doménou všude, kde to poskytovatel dovolí.
3. Publikuj `p=none` s adresou `rua`. Nech to dva až čtyři týdny a čti zprávy.
4. Oprav, co zprávy ukážou. Bude tam odesílatel, na kterého jsi zapomněl. Vždycky je.
5. Přejdi na `p=quarantine`. Pokud chceš mírnější náběh, použij pct=25 a pak pct=100. Sleduj zprávy dalších čtrnáct dní.
6. Přejdi na `p=reject`. Čti zprávy dál. Tohle není věc, kterou dokončíš.

Dvě doplňky, o kterých stojí za to vědět: přijímající stranu lze zpevnit pomocí MTA-STS, který odesílatelům říká, že tvá doména vyžaduje TLS, a záznam BIMI - ten, který dává logo vedle tvé pošty v některých klientech - se respektuje jen u domén, které už jsou na p=quarantine nebo p=reject. Ani jedno není začátek.

Ověření zvenčí#

Všechno tady je veřejné, takže si to celé můžeš ověřit sám přes dig - žádné nástroje nejsou potřeba.

$ dig TXT example.com +short$ dig TXT s1._domainkey.example.com +short$ dig TXT _dmarc.example.com +short$ dig MX example.com +short

Na Windows odvede stejnou práci Resolve-DnsName example.com -Type TXT. Pokud se právě publikovaný záznam neobjeví, je to cache - odpověď, kterou dostaneš, je tak stará, jak dovolilo TTL. Abys to obešel, dotazuj se přímo autoritativního nameserveru, jak popisuje nameservery vs DNS záznamy, a v DNS záznamy vysvětlené najdeš, proč je cache vždycky ta matoucí část.

Druhá polovina kontroly je poslat zprávu na účet, který ovládáš, a přečíst si hlavičky. V Gmailu vypíše verdikty nahoře Show original; ve většině klientů hledej hlavičku Authentication-Results:

Authentication-Results: mx.google.com;  spf=pass (google.com: domain of bounces.example.com designates  203.0.113.10 as permitted sender) smtp.mailfrom=bounces.example.com;  dkim=pass header.i=@example.com header.s=s1;  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Tři průchody a header.from odpovídající tvé doméně je hotový stav. Cokoli jiného ti přesně říká, ke které ze tří věcí se vrátit.

Co dalšího rozhoduje o složce spam#

Autentizace zajistí, že tě vezmou v úvahu. Doručení nezaručí. Když SPF, DKIM a DMARC projdou, pořád ve spamu končí pošta kvůli těmto věcem:

• Reputace odesílající IP a domény. Nové odesílající domény začínají s ničím a zachází se s nimi opatrně. Posílej pár týdnů pomalý, stálý objem a ne deset tisíc zpráv první den.
• Reverzní DNS. Odesílající IP by měla mít záznam PTR, který se přeloží zpět na jméno, jež server používá v HELO. Sdílené relaye to řeší; server, který jsi nastavoval sám, často ne.
• Míra stížností. Zveřejněný práh Gmailu pro hromadné odesílatele je míra stížností na spam pod 0,3 %, cílová hodnota 0,1 %. Jeden špatný nákup seznamu zničí doménu na měsíce.
• Odhlašování. Od roku 2024 musí odesílatelé více než 5 000 zpráv denně na Gmail nebo Yahoo podporovat u propagační pošty odhlášení jedním kliknutím a vyřídit ho do dvou dnů, a to navíc k SPF, DKIM a záznamu DMARC.
• Zpracování bounců. Když dál posíláš na adresy, které tvrdě odmítají, říkáš každému příjemci, že svůj seznam neudržuješ.
• Obsah a odkazy. Zkrácené odkazy, jeden velký obrázek bez textu a domény odkazů se špatnou reputací se ti počítají k tíži.

Odesílání pošty z aplikace, kterou hostuješ#

Pokud tvoje aplikace v Node, Pythonu, PHP nebo Laravelu potřebuje posílat obnovy hesel a potvrzení objednávek, nesnaž se ze samotného serveru udělat mailový server. Odchozí port 25 blokuje většina sítí, nová IP nemá žádnou reputaci a převzal bys filtrování spamu, frontování a zpracování bounců jako vedlejší projekt.

Použij transakčního poskytovatele přes SMTP submission - port 587 se STARTTLS nebo 465 s implicitním TLS - nebo jeho HTTP API. Nastav u něj vlastní return path a vlastní selector DKIM podle sekce o alignmentu výše, aby DMARC prošel. Přihlašovací údaje drž mimo repozitář a v proměnných prostředí v panelu, jako v proměnné prostředí a tajemství; heslo k SMTP commitnuté do Gitu je jeden z nejrychlejších způsobů, jak přimět někoho zneužít tvou doménu k rozesílání spamu.

Na RE:NODE je tohle hranice, kterou stojí za to říct jasně: hostujeme aplikaci nebo web, který poštu odesílá, na tarifech pro aplikace a web se slotem reverzní proxy, proměnnými prostředí na záložce Startup a sloty pro databáze v panelu. Nehostujeme schránky, neprovozujeme MX, nerelayujeme SMTP a nehostujeme DNS zóny. Tvůj záznam MX ukazuje na tvého poštovního poskytovatele, tvůj záznam A ukazuje na nás a ty dvě věci jsou nezávislé - což je také odpověď na otázku „rozbije přesun mého webu můj e-mail“. Nerozbije, pokud měníš jen záznamy, které se týkají webu. Nameservery vs DNS záznamy popisují, které to jsou, a pokud je web instalace WordPressu, zabezpečení WordPressu se věnuje pluginu, který poštu obvykle odesílá.

FAQ#

Potřebuju všechny tři záznamy?

DMARC potřebuje, aby alespoň jedno z SPF nebo DKIM prošlo aligned, takže přísně vzato by ses obešel se dvěma. V praxi publikuj všechny tři: SPF selhává při přeposílání, DKIM u mailing listů, a když máš obojí, jedno z nich obvykle přežije. DMARC bez kteréhokoli z nich je bezvýznamný.

Zastaví záznam DMARC lidi v podvrhování mé domény?

Zastaví poštu, která se hlásí k tvé doméně, u příjemců, kteří DMARC dodržují, což dnes zahrnuje všechny velké poskytovatele schránek. Nedělá nic proti podobným doménám, podvrhování zobrazovaného jména ani napadenému účtu, který odesílá skutečně ověřenou poštu. Zavírá jedny dveře, a to ty, které se používají nejčastěji.

Proč moje pošta projde SPF, ale neprojde DMARC?

Alignment. SPF prošlo pro obálkovou doménu, která patří tvému odesílajícímu poskytovateli, ne pro doménu ve viditelné hlavičce From:. Nastav vlastní return path na subdoméně své domény, nebo nech poskytovatele podepisovat DKIM tvou doménou, a průchod bude aligned.

Za jak dlouho se změna projeví?

Tak dlouho, jak dlouhé je TTL záznamu, plus doba, po kterou ho příjemci cachují. Den před jakoukoli změnou sniž TTL na 300 sekund a po ní počítej s tím, že původní TTL musíš vyčkat. Na ověřování pošty není nic okamžité.

Můžu hostovat e-mail na stejném tarifu jako web?

Tady ne. RE:NODE hostuje web nebo aplikaci; schránky, MX a SMTP relaying jsou služba někoho jiného. Takové oddělení je normální a je i pohodlné: web můžeš přesouvat mezi hostingy, aniž bys sáhl na jediný poštovní záznam.

Co vlastně dělá p=none?

Tvému doručování nic. Žádá příjemce, aby hlásili, co viděli, a u selhání nic nepodnikali. Je to správný první krok a nechat doménu na p=none roky je pořád lepší než skočit na p=reject a objevovat své odesílatele ve stejnou chvíli jako tvoji zákazníci.