SPF v praxi: zmapujte všechny odesílatele

Modul 4: Doručitelnost: SPF, DKIM a DMARC v praxi · Doba čtení: 12 minut

Cíl lekce: Po této lekci dokážete vypátrat všechny služby, které odesílají poštu jménem vaší domény, zahrnout je do jednoho SPF záznamu, rekurzivně spočítat vyhledávání až k hranici deseti a vědomě si vybrat mezi ~all a -all.

Klíčové pojmy: inventura odesílatelů, envelope odesílatel (Return-Path), jeden SPF záznam, include, redirect, limit 10 DNS vyhledávání (RFC 7208 oddíl 4.6.4), prázdná vyhledávání (void lookups, maximálně 2), rekurzivní počítání, permerror, flattening, SPF pro subdomény, SPF na doméně, která neodesílá poštu, ~all a -all

Krátké opakování

SPF záznam je TXT záznam na vaší doméně, který začíná v=spf1 a vyjmenovává, které servery smí odesílat poštu jménem vaší domény. Stavba záznamu, znaky + - ~ ? a tři nejznámější chyby (dva záznamy, +all, více než deset vyhledávání) jsou popsány v DNS kurzu, lekce 4.3. Pokud je pro Vás SPF nové, přečtěte si ji nejdřív. Tato lekce se věnuje té obtížnější části: v praxi téměř nikdo přesně neví, kdo všechno odesílá poštu jménem jeho domény.

Krok 1: inventura

SPF funguje pouze tehdy, pokud jsou v záznamu uvedeni všichni odesílatelé. Pokud na nějakého zapomenete, jeho pošta skončí ve spamu nebo bude odmítnuta ve chvíli, kdy zpřísníte DMARC. Projděte si proto tento seznam. U průměrné malé firmy jich rychle najdete pět až šest:

Dva dobré způsoby, jak je najít:

1. Čtení hlaviček. Pošlete si z každého systému e-mail (fakturu, obnovu hesla, testovací newsletter) a podívejte se v hlavičkách na Return-Path a Authentication-Results (lekce 1.5). Tam uvidíte, přes jakou doménu a jaký server zpráva přišla.
2. DMARC reporty. Nastavte DMARC na p=none s adresou pro reporty (lekce 4.4). Po pár týdnech uvidíte v reportech (lekce 4.5) každý server, který odesílal poštu jménem Vaší domény, včetně toho, na který jste zapomněli. To je nejspolehlivější inventura.

Ne každá služba patří do Vašeho SPF

Tady se často chybuje. SPF se dívá na envelope odesílatele (Return-Path), ne na adresu v poli Od. Mnoho newsletterových a odesílacích služeb posílá poštu s Return-Path na vlastní doméně, například bounce-123@mail.mailer.example. Příjemce pak kontroluje SPF záznam domény mailer.example, ne Váš. Zahrnutí (include) té služby do Vašeho záznamu pak nic nedělá, jen stojí jedno vyhledávání.

Co taková služba skutečně potřebuje, aby prošla přes DMARC, je DKIM podpis s Vaší doménou (lekce 4.3), nebo vlastní subdoménu Return-Path od Vás (například bounce.example.com jako CNAME na danou službu). Přečtěte si tedy v návodu dané služby, co vyžaduje. Pokud říká „vložte include: do svého SPF“, udělejte to. Pokud říká jen „vytvořte tyto CNAME záznamy pro DKIM a bounce doménu“, pak do hlavního záznamu není třeba přidávat nic. Modul 7 se tomuto tématu věnuje podrobněji.

Krok 2: jeden záznam, a správně počítat

Všichni odesílatelé patří do jednoho záznamu. Řekněme, že Vaše inventura ukáže toto: mailový server Vašeho hostingu, Microsoft 365 pro několik zaměstnanců, Váš účetní program a helpdesk. Pak bude záznam vypadat například takto:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Kolik je to vyhledávání? Spočítejte každé a, mx, include, exists, ptr a redirect, a poté také vše, co je uvedeno v záznamech za každým include:

Při 11 vrátí příjemce permerror: celý SPF záznam se pak nepočítá pro žádného odesílatele. Pošta z Vašeho vlastního mailového serveru tak bude hodnocena hůř jen proto, že helpdesk stojí tři vyhledávání. A záludné na tom je, že Váš záznam může mít dnes 9 a zítra 11, aniž byste cokoliv změnili, protože nějaká služba rozšíří svůj vlastní záznam.

Mimo to: maximálně dvě prázdná vyhledávání

RFC 7208 zmiňuje také void lookups: vyhledávání, která nic nevrátí (název neexistuje, nebo nemá SPF ani adresní záznam). Více než dvě taková vyhledávání rovněž vedou k permerror. Nejčastěji se to stává u starých include na služby, které už nepoužíváte a které svůj záznam smazaly, nebo u a: na server, který už neexistuje. Je tedy třeba dělat pořádek.

Krok 3: zpátky pod deset

Pokud jste nad deseti, existují čtyři řešení, od nejlepšího po nejméně vhodné:

1. Odstraňte, co není potřeba. Služby, které už nepoužíváte. Služby, které odesílají s vlastním Return-Path (viz výše) a proto do Vašeho SPF nepatří. a, pokud Váš web sám o sobě neodesílá poštu. mx, pokud Váš MX ukazuje na službu, která už ve Vašem záznamu je uvedena přes include.
2. Použijte subdoménu. Nechte danou službu odesílat z nieuws.example.com nebo factuur.example.com. Tato subdoména dostane vlastní SPF záznam pouze s danou službou a nepočítá se do deseti u Vaší hlavní domény. Zarovnání (alignment) v DMARC (lekce 4.4) funguje standardně i pro subdomény.
3. Použijte ip4: a ip6: pro vlastní pevné servery. Ty nestojí žádné vyhledávání. Dělejte to jen pro adresy, které spravujete sami a které se nemění.
4. Flattening (nahrazení všech includů IP adresami, které jsou za nimi aktuálně uvedeny). Tím se počet sníží na 0, ale záznam přestane odpovídat skutečnosti, jakmile daná služba změní své adresy, a velké služby to dělají pravidelně. Dělejte to pouze s nástrojem, který to automaticky udržuje aktuální, a raději vůbec ne.

redirect nebo include?

redirect= říká: použij SPF záznam té druhé domény místo tohoto záznamu. Stojí to jedno vyhledávání, stejně jako include. Je to užitečné, pokud máte mnoho domén, které musí mít přesně stejná pravidla: v=spf1 redirect=_spf.example.com na každé doméně a skutečný záznam na jednom místě. Záznam s redirect= nesmí obsahovat all, protože pak se redirect ignoruje. Gmail to sám využívá: gmail.com má v=spf1 redirect=_spf.google.com.

Krok 4: ~all nebo -all?

Doporučení tohoto kurzu, shodné s DNS kurzem:

• Začněte s ~all (softfail). Pošta ze serveru, který není uveden ve Vašem záznamu, je považována za podezřelou, ale většinou není okamžitě odmítnuta. Pokud zapomenete na nějakého odesílatele, škoda zůstane omezená.
• Přejděte na -all (fail), jakmile máte jistotu, že jsou uvedeni všichni odesílatelé, například poté, co jste si několik týdnů prohlíželi DMARC reporty a už se v nich neobjevují žádné neznámé zdroje.

S DMARC po boku je rozdíl menší, než se často myslí. DMARC rozhoduje na základě toho, zda „SPF nebo DKIM uspělo a je zarovnané“. Softfail je pro DMARC jednoduše „neuspělo“. Skutečná ochrana tedy plyne z přísné DMARC politiky, ne z -all. Někteří příjemci odmítají poštu při -all ještě před vyhodnocením DMARC; to je důvod, proč volit -all až ve chvíli, kdy je Váš záznam opravdu kompletní.

Doména, která nikdy neodesílá poštu

Máte domény, které nikdy neodesílají poštu (starou značku, doménu na překlepy)? Chraňte je proti zneužití pomocí:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Zde je -all rovnou správně: nikdo nesmí jménem domény odesílat poštu. Poslední řádek je null MX (RFC 7505): „tato doména nepřijímá poštu“. Doména example.com sama je nastavena přesně stejně.

V praxi: jak to vypadá v panelu

U hostingového balíčku WebOké je standardně nastaveno v=spf1 a mx include:webawere.nl ~all. Když přidáte nějakou službu, upravíte tento záznam (v DirectAdminu: DNS Management, tužka za SPF záznamem, pole Zahrnout doménu; v Můj WebOké: SPF pomocník na záložce DNS). Ponechejte include:webawere.nl, dokud Vaše pošta nebo web běží přes tyto servery. U jiných poskytovatelů se standardní include jmenuje jinak, ale princip je stejný: doplňovat, ne vytvářet druhý záznam.

Shrnutí

• Nejdřív sestavte inventuru všech odesílatelů; pomohou Vám DMARC reporty a hlavičky zpráv.
• Služba s vlastním Return-Path nepatří do Vašeho SPF; potřebuje DKIM s Vaší doménou.
• Počítejte rekurzivně: každé include, a, mx, exists, ptr a redirect, i uvnitř includů. Nad deset, nebo více než dvě prázdná vyhledávání, znamená permerror.
• Vraťte se pod deset úklidem a použitím subdomén; flattening jen s automatickou údržbou.
• Začněte s ~all, přejděte na -all, jakmile máte jistotu. Domény, které nikdy neodesílají poštu: -all, DMARC reject a null MX.

Kvíz

Úkol

Úkol Z4.2: Nechat rekurzivně spočítat SPF Vaší domény. Zadejte vlastní doménu (nebo sidn.nl, pokud vlastní doménu nemáte). Nejdřív si sami spočítejte, kolik DNS vyhledávání stojí SPF záznam, včetně všeho uvnitř includů, a zadejte toto číslo spolu s koncem záznamu (~all, -all, ?all nebo +all). Program to následně spočítá naživo, včetně prázdných vyhledávání, a zobrazí stromovou strukturu.

Úkol O4.2: Vaše inventura odesílatelů. Pomocí tabulky z této lekce sestavte seznam všech systémů, které odesílají poštu jménem Vaší domény. U každého uveďte: přes jaký server nebo službu, zda musí být ve Vašem SPF (vlastní Return-Path, nebo ne) a zda podepisuje DKIM Vaší doménou. Pošlete si z alespoň dvou systémů testovací e-mail a z hlaviček si poznamenejte doménu Return-Path a doménu DKIM (d=).

Doporučená literatura

Kroky v těchto článcích platí pro panely WebOké; u jiných poskytovatelů to funguje obdobně.

• Bezplatný kurz DNS 4.3: SPF: kdo smí odesílat poštu jménem Vaší domény?
• Příručka k DirectAdmin 5.7: Nastavení a doplnění SPF
• Jak funguje záznam SPF v DNS?
• Přidání nebo změna záznamu SPF v DirectAdmin
• Příručka WebOké 5.5: DNS pomocníci: MX, SPF, DMARC, CAA a SRV
• RFC 7208 (SPF), oddíl 4.6.4 (limity) a 6.1 (redirect); RFC 7505 (null MX)