SPF praktikoje: visų siuntėjų nustatymas

4 modulis: Pristatomumas: SPF, DKIM ir DMARC praktikoje · Skaitymo trukmė: 12 min.

Mokymosi tikslas: Po šios pamokos galėsite surasti visas paslaugas, kurios siunčia laiškus Jūsų domeno vardu, sutalpinti jas viename SPF įraše, rekursyviai suskaičiuoti paieškas iki dešimties ribos ir sąmoningai rinktis tarp ~all ir -all.

Pagrindinės sąvokos: siuntėjų inventorius, voko siuntėjas (Return-Path), vienas SPF įrašas, include, redirect, 10 DNS paieškų riba (RFC 7208, 4.6.4 punktas), tuščios paieškos (void lookups, ne daugiau kaip 2), rekursyvus skaičiavimas, permerror, flattening (suplokštinimas), SPF subdomenams, SPF domene, kuris nesiunčia pašto, ~all ir -all

Trumpas priminimas

SPF įrašas tai TXT įrašas Jūsų domene, kuris prasideda v=spf1 ir išvardija, kurie serveriai gali siųsti paštą Jūsų domeno vardu. Struktūra, simboliai + - ~ ? ir trys dažniausios klaidos (du įrašai, +all, daugiau nei dešimt paieškų) aprašyti DNS kurso 4.3 pamokoje. Jei SPF Jums naujiena, pirmiausia perskaitykite ją. Ši pamoka skirta sudėtingesnei daliai: praktikoje beveik niekas tiksliai nežino, kas visi siunčia paštą jo domeno vardu.

1 žingsnis: inventorius

SPF veikia tik tada, kai jame nurodyti visi siuntėjai. Jei vieną pamiršite, jo laiškai pateks į šlamštą arba bus atmesti, kai tik sugriežtinsite DMARC. Todėl peržiūrėkite šį sąrašą. Vidutinėje mažoje įmonėje jų greitai susidaro penki ar šeši:

Du geri būdai juos rasti:

1. Skaityti kopregeles. Iš kiekvienos sistemos nusiųskite sau laišką (sąskaitą faktūrą, slaptažodžio atkūrimo laišką, bandomąjį naujienlaiškį) ir kopregelėse peržiūrėkite Return-Path bei Authentication-Results (1.5 pamoka). Ten matysite, per kurį domeną ir serverį laiškas atkeliavo.
2. DMARC ataskaitos. Nustatykite DMARC į p=none su ataskaitų adresu (4.4 pamoka). Po kelių savaičių ataskaitose (4.5 pamoka) pamatysite kiekvieną serverį, kuris siuntė laiškus Jūsų domeno vardu, taip pat tuos, kuriuos buvote pamiršę. Tai patikimiausias inventorius.

Ne kiekviena paslauga priklauso Jūsų SPF įrašui

Čia dažnai suklystama. SPF tikrina voko siuntėją (Return-Path), o ne Nuo lauką (From). Daugelis naujienlaiškių ir siuntimo paslaugų siunčia su Return-Path savo pačių domene, pavyzdžiui, bounce-123@mail.mailer.example. Gavėjas tuomet tikrina mailer.example SPF įrašą, o ne Jūsų. Tos paslaugos include Jūsų įraše tokiu atveju nieko nepadeda, tik kainuoja vieną paiešką.

Ką tai paslaugai iš tikrųjų reikia, kad praeitų DMARC, tai DKIM parašas su Jūsų domenu (4.3 pamoka) arba Jūsų paties Return-Path subdomenas (pavyzdžiui, bounce.example.com kaip CNAME į paslaugą). Todėl pasiskaitykite paslaugos instrukcijoje, ko ji prašo. Jei ji sako "įdėkite include: į savo SPF", padarykite tai. Jei ji sako tik "sukurkite šiuos CNAME įrašus DKIM ir grąžinamojo pašto (bounce) domenui", tuomet pagrindiniame įraše nieko keisti nereikia. Modulis 7 šį klausimą nagrinėja plačiau.

2 žingsnis: vienas įrašas ir teisingas skaičiavimas

Visi siuntėjai sudedami į vieną įrašą. Tarkime, Jūsų inventorius parodo tai: Jūsų prieglobos įmonės pašto serveris, Microsoft 365 keliems darbuotojams, Jūsų buhalterinė programa ir pagalbos tarnyba. Tuomet įrašas atrodytų taip:

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"

Kiek tai paieškų? Suskaičiuokite kiekvieną a, mx, include, exists, ptr ir redirect, o paskui taip pat suskaičiuokite viską, kas nurodyta įrašuose už kiekvieno include:

Esant 11, gavėjas grąžina permerror klaidą: tuomet visas SPF įrašas negalioja jokiam siuntėjui. Taigi Jūsų laiškai iš nuosavo pašto serverio vertinami blogiau dėl to, kad pagalbos tarnyba kainuoja tris paieškas. Ir dar klastingesnis dalykas: Jūsų įrašas šiandien gali būti 9, o rytoj 11, net ir Jums nieko nekeičiant, nes kokia nors paslauga išplečia savo paties įrašą.

Be to: ne daugiau kaip dvi tuščios paieškos

RFC 7208 mini ir tuščias paieškas (void lookups): paieškas, kurios nieko neduoda (vardas neegzistuoja arba neturi SPF ar adreso įrašo). Daugiau nei dvi tokios paieškos taip pat sukelia permerror klaidą. Tai dažniausiai nutinka dėl senų include nuorodų į paslaugas, kurių nebenaudojate ir kurios pašalino savo įrašą, arba dėl a: į serverį, kurio nebėra. Taigi reikia susitvarkyti.

3 žingsnis: grįžti žemiau dešimties

Jei viršijate dešimtį, yra keturi sprendimai, nuo geriausio iki mažiausiai tinkamo:

1. Pašalinkite tai, kas nereikalinga. Paslaugas, kurių nebenaudojate. Paslaugas, kurios siunčia su savo pačių Return-Path (žr. aukščiau) ir todėl neturėtų būti Jūsų SPF įraše. a, jei Jūsų svetainė pati nesiunčia pašto. mx, jei Jūsų MX nukreiptas į paslaugą, kuri jau nurodyta Jūsų įraše per include.
2. Naudokite subdomeną. Leiskite paslaugai siųsti iš nieuws.example.com arba factuur.example.com. Tas subdomenas gaus atskirą SPF įrašą tik su ta paslauga ir nebus įskaičiuotas į pagrindinio domeno dešimtį. DMARC suderinimas (4.4 pamoka) pagal numatytuosius nustatymus veikia ir subdomenams.
3. Naudokite ip4: ir ip6: savo nuolatiniams serveriams. Tai nekainuoja jokios paieškos. Darykite tai tik adresams, kuriuos valdote patys ir kurie nesikeičia.
4. Flattening (suplokštinimas) (visi include'ai pakeičiami IP adresais, kurie šiuo metu už jų slypi). Tai sumažina skaičių iki 0, bet įrašas nebebus teisingas, kai tik paslauga pakeis savo adresus, o didelės paslaugos tai daro reguliariai. Darykite tai tik su įrankiu, kuris tai automatiškai atnaujina, geriau iš viso to nedarykite.

redirect ar include?

redirect= reiškia: naudoti kito domeno SPF įrašą vietoj šio. Tai kainuoja vieną paiešką, lygiai kaip include. Tai patogu, kai turite daug domenų, kuriems reikia tiksliai tos pačios politikos: v=spf1 redirect=_spf.example.com kiekviename domene, o tikrasis įrašas yra vienoje vietoje. Įrašas su redirect= negali turėti all, nes tuomet redirect bus ignoruojamas. Gmail pats tai naudoja: gmail.com turi v=spf1 redirect=_spf.google.com.

4 žingsnis: ~all ar -all?

Šio kurso rekomendacija, tokia pati kaip DNS kurse:

• Pradėkite nuo ~all (softfail). Laiškas iš serverio, kurio nėra Jūsų įraše, laikomas įtartinu, bet dažniausiai iš karto neatmetamas. Jei pamiršite siuntėją, žala bus ribota.
• Pereikite prie -all (fail), kai esate tikri, kad visi siuntėjai yra įraše, pavyzdžiui, po to, kai kelias savaites peržiūrėjote DMARC ataskaitas ir nebelieka nežinomų šaltinių.

Su DMARC skirtumas yra mažesnis, nei dažnai manoma. DMARC sprendžia pagal principą "SPF arba DKIM sėkmingas ir suderintas". Softfail DMARC požiūriu paprasčiausiai yra "nesėkmingas". Tikroji apsauga taigi kyla iš griežtos DMARC politikos, o ne iš -all. Kai kurie gavėjai atmeta laiškus jau esant -all, dar prieš DMARC vertinimą; tai priežastis rinktis -all tik tada, kai Jūsų įrašas tikrai pilnas.

Domenas, kuris niekada nesiunčia pašto

Ar turite domenų, kurie niekada nesiunčia pašto (sena prekės ženklo versija, rašybos klaidos domenas)? Apsaugokite juos nuo piktnaudžiavimo tokiu būdu:

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

Čia -all yra iškart teisingas pasirinkimas: niekas negali siųsti pašto. Paskutinė eilutė tai null MX (RFC 7505): "šis domenas negauna pašto". example.com pats taip ir nustatytas.

Praktikoje: taip tai atrodo valdymo skydelyje

WebOké prieglobos pakete pagal numatytuosius nustatymus yra v=spf1 a mx include:webawere.nl ~all. Pridėjus paslaugą, reikia pakoreguoti šį įrašą (DirectAdmin: DNS Management, pieštuko piktograma šalia SPF įrašo, laukelis Įtraukti domeną; Mano WebOké: SPF pagalbininkas DNS skirtuke). Palikite include:webawere.nl tol, kol Jūsų paštas ar svetainė veikia per tuos serverius. Kitų tiekėjų atveju numatytasis include vadinasi kitaip, bet principas tas pats: papildykite, nekurkite antro įrašo.

Santrauka

• Pirmiausia sudarykite visų siuntėjų inventorių; DMARC ataskaitos ir kopregelės tam padeda.
• Paslauga su savo pačios Return-Path neturėtų būti Jūsų SPF įraše; jai reikia DKIM su Jūsų domenu.
• Skaičiuokite rekursyviai: kiekvieną include, a, mx, exists, ptr ir redirect, taip pat ir viduje esančius include'us. Daugiau nei dešimt, arba daugiau nei dvi tuščios paieškos, reiškia permerror.
• Grįžkite žemiau dešimties susitvarkydami ir naudodami subdomenus; flattening tik su automatine priežiūra.
• Pradėkite nuo ~all, pereikite prie -all, kai būsite tikri. Domenams, kurie niekada nesiunčia pašto: -all, DMARC reject ir null MX.

Testas

Užduotis

Užduotis Z4.2: Rekursyvus Jūsų domeno SPF skaičiavimas. Įveskite savo domeną (arba sidn.nl, jei neturite nuosavo domeno). Pirmiausia patys suskaičiuokite, kiek DNS paieškų kainuoja SPF įrašas, įskaitant viską, kas yra include'uose, ir įveskite skaičių kartu su įrašo pabaiga (~all, -all, ?all arba +all). Programa gyvai perskaičiuoja, įskaitant tuščias paieškas, ir parodo medį.

Užduotis O4.2: Jūsų siuntėjų inventorius. Naudodami šios pamokos lentelę, sudarykite visų sistemų, kurios siunčia paštą Jūsų domeno vardu, sąrašą. Prie kiekvienos nurodykite: per kurį serverį ar paslaugą, ar ji turi būti Jūsų SPF įraše (savas Return-Path ar ne), ir ar ji pasirašo DKIM su Jūsų domenu. Iš bent dviejų sistemų nusiųskite sau bandomąjį laišką ir iš kopregelių užsirašykite Return-Path domeną bei DKIM domeną (d=).

Skaitykite daugiau

Šiuose straipsniuose aprašyti žingsniai taikomi WebOké valdymo skydeliams; kitų tiekėjų atveju veikimas panašus.

• Nemokamas DNS kursas 4.3: SPF: kas gali siųsti laiškus Jūsų domeno vardu?
• DirectAdmin vadovas 5.7: SPF nustatymas ir papildymas
• Kaip veikia SPF įrašas DNS sistemoje?
• SPF įrašo pridėjimas arba keitimas DirectAdmin
• WebOké vadovas 5.5: DNS pagalbininkai: MX, SPF, DMARC, CAA ir SRV
• RFC 7208 (SPF), 4.6.4 punktas (ribos) ir 6.1 punktas (redirect); RFC 7505 (null MX)