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, sutvarkyti jas viename SPF įraše, rekursyviai suskaičiuoti paieškas iki dešimties ribos ir sąmoningai pasirinkti tarp ~all ir -all.

Pagrindinės sąvokos: siuntėjų inventorius, envelope sender (Return-Path), vienas SPF įrašas, include, redirect, 10 DNS paieškų riba (RFC 7208, 4.6.4 skirsnis), tuščios paieškos (void lookups, ne daugiau kaip 2), rekursyvus skaičiavimas, permerror, flattening, 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 laiškus 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 visas siunčia laiškus jo domeno vardu.

1 žingsnis: inventorius

SPF veikia tik tuomet, kai įraše yra visi siuntėjai. Jei pamiršite bent vieną, jo laiškai pateks į brukalus arba bus atmesti, kai griežtinsite DMARC taisykles. 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 surasti:

1. Perskaityti antraštes. Iš kiekvienos sistemos nusiųskite laišką sau (sąskaitą faktūrą, slaptažodžio atkūrimo laišką, testinį naujienlaiškį) ir antraštėse pažiūrėkite Return-Path ir Authentication-Results (1.5 pamoka). Ten matysite, per kurį domeną ir serverį jis 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į, siuntusį 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žniausiai suklystama. SPF tikrina envelope sender (Return-Path), o ne Nuo adresą. 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 nepakeičia, tik kainuoja vieną paiešką.

Tam, kad ta paslauga sėkmingai praeitų DMARC patikrą, jai reikia DKIM parašo su Jūsų domenu (4.3 pamoka) arba atskiro Jūsų Return-Path subdomeno (pavyzdžiui, bounce.example.com kaip CNAME į paslaugą). Todėl perskaitykite paslaugos instrukciją, ko ji reikalauja. Jei ji sako „įrašykite include: savo SPF įraše“, taip ir padarykite. Jei ji sako tik „sukurkite šiuos CNAME įrašus DKIM ir bounce domenui“, tuomet pagrindiniame įraše nieko keisti nereikia. Šis klausimas plačiau aptariamas 7 modulyje.

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

Visi siuntėjai sudedami į vieną įrašą. Tarkime, Jūsų inventorius parodo: Jūsų prieglobos įmonės pašto serverį, Microsoft 365 keliems darbuotojams, apskaitos programą ir pagalbos tarnybą. Tuomet įrašas gali atrodyti 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, ir tada taip pat suskaičiuokite viską, kas nurodyta įrašuose už kiekvieno include:

Esant 11, gavėjas grąžina permerror: visas SPF įrašas tuomet neskaičiuojamas, jokiam siuntėjui. Todėl Jūsų paties pašto serverio laiškai vertinami blogiau dėl to, kad pagalbos tarnyba kainuoja tris paieškas. Ir pati klastingiausia dalis: Jūsų įrašas šiandien gali būti 9, o rytoj 11, nors Jūs nieko nekeitėte, nes kažkuri paslauga išplėtė savo įrašą.

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

RFC 7208 mini ir void lookups: paieškas, kurios nieko negrąžina (vardo nėra, arba jis neturi SPF ar adreso įrašo). Daugiau nei dvi tokios paieškos taip pat sukelia permerror. Taip dažniausiai nutinka dėl senų include įrašų paslaugoms, kurių nebenaudojate ir kurios pašalino savo įrašą, arba dėl a:, nukreipto į serverį, kurio nebėra. Taigi, tvarkykitės.

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

Jei viršijate dešimt, yra keturi sprendimai, nuo geriausio iki prasčiausio:

1. Pašalinkite tai, kas nereikalinga. Paslaugas, kurių nebenaudojate. Paslaugas, siunčiančias su savo pačių Return-Path (žr. aukščiau) ir todėl nepriklausančias Jūsų SPF įrašui. a, jei Jūsų svetainė pati nesiunčia pašto. mx, jei Jūsų MX nukreiptas į paslaugą, kuri jau yra Jūsų įraše kaip include.
2. Naudokite subdomeną. Leiskite paslaugai siųsti iš nieuws.example.com arba factuur.example.com. Tas subdomenas turės savo SPF įrašą tik su ta paslauga ir neskaičiuojamas Jūsų pagrindinio domeno dešimtyje. DMARC suderinimas (alignment, 4.4 pamoka) pagal nutylėjimą veikia ir subdomenams.
3. Naudokite ip4: ir ip6: savo nuolatiniams serveriams. Jie nekainuoja paieškos. Darykite tai tik tiems adresams, kuriuos valdote patys ir kurie nesikeičia.
4. Flattening (visų include pakeitimas IP adresais, kurie šiuo metu už jų slypi). Tai sumažina skaičių iki 0, bet įrašas nebebus teisingas, kai paslauga pakeis savo adresus, o didelės paslaugos tai daro reguliariai. Darykite tai tik su įrankiu, kuris atnaujina tai automatiškai, o geriau visai to nedarykite.

redirect ar include?

redirect= reiškia: naudokite kito domeno SPF įrašą vietoj šio įrašo. Jis kainuoja vieną paiešką, lygiai kaip include. Tai patogu, kai turite daug domenų, kuriems reikia visiškai vienodos politikos: v=spf1 redirect=_spf.example.com kiekviename domene, o tikrasis įrašas viename vietoje. Įraše su redirect= negali būti all, nes tuomet redirect bus ignoruojamas. Pati Gmail 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škai iš serverio, kurio nėra Jūsų įraše, laikomi įtartinais, bet dažniausiai iškart neatmetami. Jei pamiršite siuntėją, žala bus ribota.
• Pereikite prie -all (fail), kai esate tikri, kad visi siuntėjai yra įraše, pavyzdžiui, peržiūrėję DMARC ataskaitas kelias savaites ir nematydami nebežinomų šaltinių.

Su DMARC skirtumas yra mažesnis, nei dažnai manoma. DMARC sprendžia pagal „SPF arba DKIM sėkmingas ir suderintas (aligned)“. Softfail DMARC požiūriu tiesiog yra „nesėkmingas“. Tikroji apsauga taigi ateina iš griežtos DMARC politikos, o ne iš -all. Kai kurie gavėjai atmeta laišką dar prieš DMARC vertinimą, jei yra -all; tai priežastis rinktis -all tik tada, kai Jūsų įrašas yra tikrai išsamus.

Domenas, kuris niekada nesiunčia pašto

Turite domenų, kurie niekada nesiunčia laiškų (sena prekės ženklo pavadinimo versija, klaidingai parašyto domeno variantas)? 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š karto teisingas pasirinkimas: niekas negali siųsti laiškų. Paskutinė eilutė yra null MX (RFC 7505): „šis domenas negauna pašto“. Pats example.com yra sukonfigūruotas lygiai taip pat.

Praktikoje: kaip tai atrodo valdymo skydelyje

WebOké prieglobos pakete pagal nutylėjimą yra v=spf1 a mx include:webawere.nl ~all. Jei pridedate paslaugą, pakoreguokite šį įrašą (DirectAdmin skydelyje: DNS Beheer (DNS valdymas), pieštuko piktograma šalia SPF įrašo, laukelis Inclusief Domein (Įtraukti domeną); Mano WebOké: SPF pagalbininkas DNS skirtuke). Palikite include:webawere.nl, kol Jūsų paštas ar svetainė veikia per tuos serverius. Kitų paslaugų teikėjų atveju numatytasis include vadinamas kitaip, bet principas tas pats: papildykite, nekurkite antro įrašo.

Santrauka

• Pirmiausia sudarykite visų siuntėjų inventorių; tam padeda DMARC ataskaitos ir antraštės.
• Paslauga su savo pačios Return-Path nepriklauso Jūsų SPF įrašui; jai reikia DKIM su Jūsų domenu.
• Skaičiuokite rekursyviai: kiekvieną include, a, mx, exists, ptr ir redirect, taip pat ir pačiuose include. Virš dešimties, arba daugiau nei dvi tuščios paieškos, reiškia permerror.
• Grįžkite žemiau dešimties, pašalindami nereikalingus dalykus ir naudodami subdomenus; flattening tik su automatine priežiūra.
• Pradėkite nuo ~all, pereikite prie -all, kai esate 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 savo domeno). Pirmiausia patys suskaičiuokite, kiek DNS paieškų kainuoja SPF įrašas, įskaitant viską, kas yra include viduje, 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ų, siunčiančių laiškus Jūsų domeno vardu, sąrašą. Prie kiekvienos nurodykite: per kurį serverį ar paslaugą, ar ji turi būti Jūsų SPF įraše (savo Return-Path ar ne) ir ar ji pasirašo DKIM su Jūsų domenu. Iš bent dviejų sistemų nusiųskite sau testinį laišką ir iš antraščių užsirašykite Return-Path domeną ir DKIM domeną (d=).

Skaitykite daugiau

Šiuose straipsniuose aprašyti žingsniai galioja WebOké valdymo skydeliams; kitiems paslaugų teikėjams veikimo principas 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 skirsnis (ribos) ir 6.1 (redirect); RFC 7505 (null MX)
• Gmail ir Outlook.com su Jūsų domenu 2.4: SPF ir DKIM, kai siunčiate per Gmail