SPF v praxi: zmapovanie všetkých odosielateľov

Modul 4: Doručiteľnosť: SPF, DKIM a DMARC v praxi · Čas čítania: 12 minút

Cieľ lekcie: Po tejto lekcii dokážete vypátrať všetky služby, ktoré posielajú poštu v mene vašej domény, zaradiť ich do jedného SPF záznamu, rekurzívne spočítať vyhľadávania až po hranicu desať a vedome si vybrať medzi ~all a -all.

Kľúčové pojmy: inventár odosielateľov, envelope odosielateľ (Return-Path), jeden SPF záznam, include, redirect, limit 10 DNS vyhľadávaní (RFC 7208, odsek 4.6.4), prázdne vyhľadávania (void lookups, najviac 2), rekurzívne počítanie, permerror, flattening, SPF pre subdomény, SPF na doméne, ktorá neposiela poštu, ~all a -all

Krátke zopakovanie

SPF záznam je TXT záznam na vašej doméne, ktorý začína v=spf1 a vymenúva, ktoré servery smú posielať poštu v mene vašej domény. Stavba, znaky + - ~ ? a tri najznámejšie chyby (dva záznamy, +all, viac ako desať vyhľadávaní) sú opísané v kurze DNS, lekcia 4.3. Ak je pre vás SPF nové, prečítajte si ju najprv. Táto lekcia sa venuje tej náročnejšej časti: v praxi takmer nikto presne nevie, kto všetko posiela poštu v mene jeho domény.

Krok 1: inventár

SPF funguje len vtedy, ak sú v ňom uvedení všetci odosielatelia. Ak na niektorého zabudnete, jeho pošta skončí v spame alebo bude odmietnutá, len čo sprísnite DMARC. Prejdite si preto tento zoznam. Pri bežnej malej firme ich rýchlo nájdete päť až šesť:

Dva osvedčené spôsoby, ako ich nájsť:

1. Čítanie hlavičiek. Pošlite si z každého systému e-mail sám sebe (faktúru, obnovenie hesla, testovací newsletter) a v hlavičkách sa pozrite na Return-Path a Authentication-Results (lekcia 1.5). Tam uvidíte, cez akú doménu a aký server prišiel.
2. DMARC reporty. Nastavte DMARC na p=none s adresou na reporty (lekcia 4.4). Po pár týždňoch uvidíte v reportoch (lekcia 4.5) každý server, ktorý posielal poštu v mene vašej domény, vrátane toho, na ktorý ste zabudli. Toto je najspoľahlivejší inventár.

Nie každá služba patrí do vášho SPF

Tu sa často stáva chyba. SPF sa pozerá na envelope odosielateľa (Return-Path), nie na adresu v poli Od. Mnohé newsletterové a odosielacie služby posielajú poštu s Return-Path na vlastnej doméne, napríklad bounce-123@mail.mailer.example. Príjemca potom kontroluje SPF záznam domény mailer.example, nie váš. include tejto služby vo vašom zázname potom nič nerobí, iba stojí jedno vyhľadávanie.

Čo táto služba naozaj potrebuje, aby prešla cez DMARC, je DKIM podpis s vašou doménou (lekcia 4.3), alebo vlastná subdoména pre Return-Path od vás (napríklad bounce.example.com ako CNAME na danú službu). Prečítajte si teda v návode danej služby, čo požaduje. Ak hovorí „vložte include: do svojho SPF“, urobte to. Ak hovorí len „vytvorte tieto CNAME záznamy pre DKIM a bounce doménu“, do hlavného záznamu netreba pridávať nič. Modul 7 sa tomu venuje podrobnejšie.

Krok 2: jeden záznam a správne počítanie

Všetci odosielatelia patria do jedného záznamu. Predstavte si, že váš inventár vyzerá takto: mailový server vášho hostingového poskytovateľa, Microsoft 365 pre pár zamestnancov, váš účtovný program a helpdesk. Záznam potom bude napríklad takýto:

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"

Koľko je to vyhľadávaní? Spočítajte každé a, mx, include, exists, ptr a redirect a následne spočítajte aj všetko, čo sa nachádza v záznamoch za každým include:

Pri hodnote 11 vráti príjemca permerror: celý SPF záznam sa potom neráta, pre žiadneho odosielateľa. Pošta z vášho vlastného mailového servera tak bude hodnotená horšie len preto, že helpdesk stojí tri vyhľadávania. A zákerné je, že váš záznam môže mať dnes hodnotu 9 a zajtra 11, bez toho, aby ste čokoľvek zmenili, pretože nejaká služba rozšíri svoj vlastný záznam.

Okrem toho: najviac dve prázdne vyhľadávania

RFC 7208 spomína aj void lookups: vyhľadávania, ktoré nič nevrátia (názov neexistuje alebo nemá SPF ani adresný záznam). Viac ako dve z nich tiež vedú k permerror. Stáva sa to najmä pri starých includeoch od služieb, ktoré už nepoužívate a ktoré svoj záznam odstránili, alebo pri a: smerujúcom na server, ktorý už neexistuje. Treba teda upratať.

Krok 3: späť pod desať

Ak ste nad desať, existujú štyri riešenia, zoradené od najlepšieho po najmenej vhodné:

1. Odstráňte, čo nie je potrebné. Služby, ktoré už nepoužívate. Služby, ktoré posielajú s vlastným Return-Path (pozri vyššie), a teda nepatria do vášho SPF. a, ak vaša webová stránka sama neposiela poštu. mx, ak váš MX smeruje na službu, ktorá už je vo vašom zázname uvedená cez include.
2. Použite subdoménu. Nechajte službu posielať z nieuws.example.com alebo factuur.example.com. Táto subdoména dostane vlastný SPF záznam len s danou službou a nepočíta sa do desiatich vyhľadávaní vašej hlavnej domény. Zarovnanie (alignment) v DMARC (lekcia 4.4) štandardne funguje aj pre subdomény.
3. Použite ip4: a ip6: pre vaše vlastné pevné servery. Tie nestoja žiadne vyhľadávanie. Robte to len pri adresách, ktoré spravujete vy sami a ktoré sa nemenia.
4. Flattening (nahradenie všetkých includov IP adresami, ktoré sa za nimi momentálne nachádzajú). Tým sa počet zníži na 0, ale záznam prestane sedieť hneď, ako nejaká služba zmení svoje adresy, a veľké služby to robia pravidelne. Robte to len s nástrojom, ktorý to automaticky aktualizuje, a radšej vôbec nie.

redirect alebo include?

redirect= hovorí: použi SPF záznam tej druhej domény namiesto tohto záznamu. Stojí to jedno vyhľadávanie, rovnako ako include. Je to užitočné, ak máte veľa domén, ktoré musia mať presne rovnaké pravidlá: v=spf1 redirect=_spf.example.com na každej doméne a skutočný záznam na jednom mieste. Záznam s redirect= nesmie mať all, lebo inak sa redirect ignoruje. Gmail to sám používa: gmail.com má v=spf1 redirect=_spf.google.com.

Krok 4: ~all alebo -all?

Odporúčanie tohto kurzu, zhodné s kurzom DNS:

• Začnite s ~all (softfail). Pošta zo servera, ktorý nie je vo vašom zázname, sa považuje za podozrivú, ale väčšinou nie je rovno odmietnutá. Ak zabudnete na odosielateľa, škoda je obmedzená.
• Prejdite na -all (fail), keď máte istotu, že sú uvedení všetci odosielatelia, napríklad po tom, čo ste si pár týždňov prezerali DMARC reporty a už sa v nich nenachádzajú žiadne neznáme zdroje.

S DMARC popri tom je rozdiel menší, než sa často myslí. DMARC rozhoduje na základe „SPF alebo DKIM uspeli a sú zarovnané“. Softfail je pre DMARC jednoducho „neuspelo“. Skutočná ochrana teda pochádza z prísnej politiky DMARC, nie z -all. Niektorí príjemcovia odmietajú pri -all už pred vyhodnotením DMARC; to je dôvod, prečo -all voliť až vtedy, keď je váš záznam naozaj úplný.

Doména, ktorá nikdy neposiela poštu

Máte domény, ktoré nikdy neodosielajú poštu (staré meno značky, doména na preklepy)? Chráňte ich pred zneužitím pomocou:

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

Tu je -all hneď správne: nikto nesmie posielať poštu. Posledný riadok je null MX (RFC 7505): „táto doména neprijíma poštu“. Doména example.com sama je nastavená presne takto.

V praxi: ako to vyzerá v paneli

Pri hostingovom balíčku WebOké je štandardne nastavené v=spf1 a mx include:webawere.nl ~all. Ak pridáte službu, tento záznam upravíte (v DirectAdmine: DNS Management, ceruzka pri SPF zázname, pole Neplatná doména; v Môj WebOké: SPF pomocník na karte DNS). Ponechajte include:webawere.nl, pokiaľ vaša pošta alebo web bežia cez tieto servery. U iných poskytovateľov sa štandardný include volá inak, ale princíp je rovnaký: dopĺňajte, nevytvárajte druhý záznam.

Zhrnutie

• Najprv si urobte inventár všetkých odosielateľov; pomôžu vám pri tom DMARC reporty a hlavičky.
• Služba s vlastným Return-Path nepatrí do vášho SPF; tá potrebuje DKIM s vašou doménou.
• Počítajte rekurzívne: každé include, a, mx, exists, ptr a redirect, aj vo vnútri includov. Nad desať, alebo viac ako dve prázdne vyhľadávania, znamená permerror.
• Vráťte sa pod desať upratovaním a použitím subdomén; flattening len s automatickou údržbou.
• Začnite s ~all, prejdite na -all, keď si budete istí. Domény, ktoré nikdy neposielajú poštu: -all, DMARC reject a null MX.

Kvíz

Úloha

Úloha Z4.2: Nechať rekurzívne spočítať SPF vašej domény. Zadajte svoju vlastnú doménu (alebo sidn.nl, ak vlastnú doménu nemáte). Najprv si sami spočítajte, koľko DNS vyhľadávaní stojí SPF záznam, vrátane všetkého vo vnútri includov, a zadajte toto číslo spolu s koncom záznamu (~all, -all, ?all alebo +all). Program to naživo prepočíta, vrátane prázdnych vyhľadávaní, a zobrazí strom.

Úloha O4.2: Váš prehľad odosielateľov. Pomocou tabuľky z tejto lekcie zostavte zoznam všetkých systémov, ktoré posielajú poštu v mene vašej domény. Pri každom uveďte: cez aký server alebo službu, či musí byť vo vašom SPF (vlastný Return-Path alebo nie) a či podpisuje DKIM vašou doménou. Z aspoň dvoch systémov si pošlite testovací e-mail sám sebe a z hlavičiek si zaznamenajte doménu Return-Path a doménu DKIM (d=).

Ďalšie čítanie

Kroky v týchto článkoch platia pre panely WebOké; u iných poskytovateľov to funguje obdobne.

• Bezplatný kurz DNS 4.3: SPF: kto smie posielať poštu v mene vašej domény?
• Návod na DirectAdmin 5.7: SPF nastavenie a dopĺňanie
• Ako funguje záznam SPF v DNS?
• Pridanie alebo zmena záznamu SPF v DirectAdmine
• Príručka WebOké 5.5: DNS pomôcky: MX, SPF, DMARC, CAA a SRV
• RFC 7208 (SPF), odsek 4.6.4 (limity) a 6.1 (redirect); RFC 7505 (null MX)