Defaults.Exposed › Taisymai › SPF (Sender Policy Framework)

Kaip ištaisyti SPF (Sender Policy Framework)

SPF yra eilutė jūsų domeno nustatymuose, kurioje išvardyta, kuriems pašto tiekėjams leidžiama siųsti el. laiškus jūsų verslo vardu. Be jos bet kas pasaulyje gali siųsti laišką, kuris atrodo tarsi atkeliavo iš jūsų – o jūsų tikri laiškai dažniau patenka į nepageidaujamo pašto aplanką.

Praktinė reikšmė jūsų verslui: Bet kas gali siųsti el. laiškus apsimesdamas jūsų verslu – jūsų klientams, darbuotojams ir tiekėjams – sąskaitas faktūras, mokėjimo duomenų pakeitimo prašymus ir pan. Tuo pačiu metu jūsų tikros pasiūlos ir sąskaitos faktūros dažniau patenka į šiukšlių dėžę, todėl sandoriai tyliai stringa.

Ką tai gali kainuoti

Sukčius jūsų klientui siunčia sąskaitą faktūrą „nuo jūsų” su savo banko duomenimis ir gauna apmokėjimą. Apie tai sužinote po kelių savaičių, kai klientas klausia, kur jo prekės – ir dabar nukenčia jūsų reputacija, o gal ir atsakomybė.
Jūsų pasiūlos, sąskaitos ir atsakymai tyliai patenka į klientų šiukšlių aplankus, nes didieji pašto tiekėjai negali patikrinti, ar laiškai iš tikrųjų siunčiami jūsų. Sandoriai atvėsta, o jūs niekada nesužinote kodėl.
Sukčius apsimeta jūsų vadovu ar finansų darbuotoju ir siunčia el. laišką personalui prašydamas skubaus mokėjimo ar dovanų kortelių – laiškas tikrai atrodo atkeliavęs iš jūsų domeno, todėl kažkas sumoka.
Didesnio kliento IT ar saugumo peržiūra patikrina jūsų domeną, pamato, kad nėra siuntėjo apsaugos, ir arba atsisako jūsų, arba reikalauja tai ištaisyti prieš pasirašant – tai kainuoja sandorį arba savaičių delsimą.
Manote, kad esate apsaugoti, nes SPF įrašas egzistuoja – bet jis nustatytas kaip „minkštas nepavykimas” be jokio vykdymo arba tyliai sugedęs, todėl suklastoti laiškai vis tiek praeina.

Kodėl tai svarbu. Suklastoti el. laiško siuntėjo adresą yra trivialiai paprasta ir užpuolikui nieko nekainuoja. SPF yra pigiausias ir greičiausias būdas apsunkinti jūsų domeno apsimetimą ir išlaikyti teisėtą paštą už šiukšlių ribų. „Google” ir „Yahoo” dabar aktyviai šiukšlina arba atmeta laiškus iš domenų be autentifikavimo, todėl tai nebėra pasirinkimas – tai būtina sąlyga, kad jūsų el. paštas apskritai būtų pristatytas.

Trumpai

Šiuo metu, jei neturite teisingai sukonfigūruoto SPF, bet kas pasaulyje gali siųsti el. laišką, kuris atrodo atkeliavęs iš jūsų verslo. Jie gali siųsti jūsų klientams netikras sąskaitas faktūras, darbuotojams netikrus mokėjimo prašymus ir tiekėjams laiškus tarsi jūsų vardu – ir laiškai atrodys tikri, nes jūsų domenas nieko kito nesako.

SPF (Sender Policy Framework) yra sprendimas. Tai viena eilutė teksto jūsų domeno DNS nustatymuose, kurioje išvardytos pašto paslaugos, kurioms faktiškai leidžiama siųsti el. paštą jūsų vardu. Gaunamo pašto tiekėjai – „Gmail”, „Outlook” ir visi kiti – tikrina tą sąrašą prieš nuspręsdami, ar laiškas tikras. Jokio sąrašo arba silpnas sąrašas – ir jie neturi pagrindo priimti sprendimą.

Šis puslapis apima du dalykus, kurie abu turi būti teisingi: ar SPF įrašas egzistuoja, ir ar jis nustatytas pakankamai griežtai, kad iš tikrųjų atliktų savo darbą.

Kiek tai gali jus kainuoti

Tai yra kasdieniai, realūs būdai, kaip trūkstamas arba silpnas SPF įrašas tampa pinigų ir pasitikėjimo praradimu. Mes niekada nevardijame realių įmonių – tai yra modeliai, kuriuos matome duomenyse.

Sąskaitos peradresavimas. Nusikaltėlis vienam iš jūsų klientų siunčia el. laišką, kuris atrodo lygiai taip pat, kaip atkeliavęs iš jūsų, prie jo pridėdamas realistišką sąskaitą faktūrą su savo banko sąskaita. Jūsų klientas sumoka. Pirmą kartą apie tai išgirdote, kai jis klausia, kur užsakymas, kurį jau sumokėjo. Dabar yra piktas klientas, mokėjimas nusikaltėlio rankose ir sunkus pokalbis apie tai, kas padengs nuostolius.
Generalinio direktoriaus / finansų sukčiavimas. Kažkas siunčia jūsų buhalteriui laišką „nuo” savininko: „Greitas prašymas – ar galite perkeltį šį mokėjimą iki dienos pabaigos?” Kadangi žinutė iš tikrųjų atrodo atkeliavusi iš jūsų domeno, tai nesuaktyvina niekieno intuicijos. Pinigai išeina.
Tylus pristatymo mokestis. Jūsų pasiūlos ir sąskaitos faktūros pradeda patekti į klientų šiukšlių aplankus, nes „Gmail” ir „Yahoo” negali patikrinti, ar jie iš tikrųjų nuo jūsų. Negaunate atmetimo, negaunate klaidos – sandoriai tiesiog nutyla. Prarandate verslą ir nematote, kaip tai vyksta.
Prarastas sandoris. Didesnio kliento pirkimų ar saugumo komanda atlieka pagrindinę jūsų domeno patikrą. Jie nemato siuntėjo autentifikavimo ir pažymi jus kaip riziką. Geriausiu atveju skubotai taisote pagal terminą; blogiausiu – jie renkasi konkurentą, kuris praėjo.
Prekės ženklo apnuodijimo banga. Jūsų domenas naudojamas sukčiavimo kampanijoje, nukreiptoje prieš visuomenę. Žmonės, kurie nukentėjo, dabar nepasitiki jokiu el. laišku su jūsų vardu – todėl net jūsų tikri pasiūlymai ir atnaujinimai ignoruojami arba pranešami.

Visų šių situacijų sąsaja: užpuolikas nieko neišleidžia, o jūsų verslas neša išlaidas ir kaltę.

Kas tai iš tikrųjų yra

Kai ateina el. laiškas, gaunančiojo pašto serveris nori žinoti vieną dalyką: ar tai iš tikrųjų nuo to, kuo apsimeta? SPF atsako į dalį to klausimo.

Jūs paskelbiate trumpą teksto eilutę savo domeno DNS nustatymuose – „TXT įrašą” – kuriame įvardijate pašto paslaugas, kurioms leidžiama siųsti jūsų vardu. Panašiai į:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Paprastais žodžiais tai reiškia: „Tikras mūsų paštas ateina iš „Google” ir „SendGrid” serverių – atmeskite viską kitą, kas apsimeta mūsų.”

Du dalykai, kurie svarbūs jūsų vertinimui:

Ar įrašas egzistuoja? Tai svarbiausia (jis turi didžiausią svorį tarp visų el. pašto patikrinimų). Joks įrašas reiškia, kad gavėjai neturi sąrašo, su kuriuo galėtų palyginti, todėl apsimetimas yra plačiai atviras. Čia taip pat yra subtili gedimo galimybė: jei jūsų domenas turi du ar daugiau SPF įrašų, taisyklės sako, kad visi jie negalioja – todėl veiksmingai neturite SPF, nors atrodo, kad turite.
Ar politika pakankamai griežta? Įrašas gali egzistuoti, bet vis tiek būti neveikiantis. Galas – „all” mechanizmas – yra nurodymas gavėjams:
- -all (kietas nepavykimas) – atmesti viską, kas nėra sąraše. Stipriausias. Pilni taškai.
- ~all (minkštas nepavykimas) + DMARC nustatytas kaip „reject” – šiuolaikinis rekomenduojamas nustatymas. Lygiavertė apsauga kaip kietam nepavykimui, be rizikos, kad persiunčiami laiškai atšoks. Pilni taškai.
- ~all + DMARC nustatytas kaip „quarantine” – priimtinas, šiek tiek silpnesnis; perkelkite DMARC į „reject” pilnai apsaugai.
- ~all vienas (be DMARC vykdymo) – silpnas. Tai sako „tikriausiai netikra, bet vis tiek pristatykite.” Suklastoti laiškai vis tiek praeina. Tai spąstai, į kuriuos patenka daugelis įmonių manydamos, kad yra apsaugotos.
- ?all (neutralus) – nesuteikia jokios apsaugos.
- +all – aktyviai pavojingas: tai sako pasauliui, kad bet kas gali siųsti jūsų vardu. Niekada to nenaudokite.

Yra dar vienas nematomasis gedimas: SPF leidžiama suaktyvinti tik iki 10 DNS peržvalgų, kai jis vertinamas. Susikaupdami per daug include: įrašų, viršijate tą ribą, todėl gavėjai laiko visą dalyką sugedusiu – ir jūs grįžtate prie jokios apsaugos. Tai dažna, tylioji problema įmonėms, naudojančioms daug rinkodaros ir SaaS įrankių.

Kaip atrodo „gerai”: tik vienas SPF įrašas, išvardijantis kiekvieną paslaugą, kuri teisėtai siunčia paštą jūsų vardu, baigiantis -all (arba ~all kartu su DMARC p=reject) ir komfortabiliai nesiekiantis 10 peržvalgų ribos.

Kaip tai ištaisyti (nemokama, ~10 minučių)

Perduokite šį skyrių tam, kas tvarko jūsų domeną arba svetainę – ir atkreipkite dėmesį, kad pataisymas yra nemokamas. Tai pakeitimas DNS nuostatoje, ne produktas, kurį perkate. Mes imame mokestį tik už stebėseną, kad tai išliktų teisinga, o ne už pakeitimą.

1 žingsnis – išvardykite kiekvieną paslaugą, kuri siunčia el. paštą jūsų vardu. Tai dalis, kurią žmonės daro neteisingai. Užrašykite visas: jūsų pašto dėžutės tiekėją („Google Workspace”, „Microsoft 365” ir kt.), taip pat naujienlaiškinius įrankius, CRM, pagalbos tarnybą, el. prekybos platformą, sąskaitų faktūrų / apskaitos programą ir rezervavimo sistemą. Jei paslauga siunčia paštą su jūsų vardu ir pamiršite ją, jūsų SPF blokuos jos paštą, kai sugriežtinsite politiką.

2 žingsnis – paskelbkite vieną TXT įrašą savo šakniniame domene. Sujunkite visų siuntėjų „include” eilutes į vieną įrašą. Dažnoms platformoms:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (arba regionui tinkamas domenas)

Kombinuotas įrašas atrodo taip:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Kur jį pridėti, pagal tiekėją:

Cloudflare: DNS → Records → Add record → Type TXT, Name @, Content = aukščiau pateikta reikšmė.
Microsoft 365 / Google admin: jie skelbia tikslią „include” eilutę, kurią naudoti sąrankos vedlyje; nukopijuokite ją į DNS tiekėjo TXT įrašą.
GoDaddy / dauguma prieglobų: DNS valdymas → Add → TXT, Host/Name @, Value = įrašas.

3 žingsnis – pradėkite saugiai, tada vykdykite. Kol patvirtinate, kad siuntėjų sąrašas yra pilnas, skelbkite su ~all (minkštas nepavykimas), kad niekas teisėtas nebūtų blokuojamas atsitiktinai. Kai patvirtinsite, kad visi jūsų tikri laiškai tebekyla, sugriežtinkite iki -all (kietas nepavykimas) – arba, geriau, palikite ~all ir pridėkite DMARC politiką p=reject, kas yra rekomenduojama šiuolaikinė pora.

4 žingsnis – įsitikinkite, kad turite tiksliai VIENĄ įrašą. Jei senas SPF įrašas jau egzistuoja, redaguokite tą, o ne pridėkite antrą. Du v=spf1 įrašai panaikina vienas kitą ir palieka jus neapsaugotus.

5 žingsnis – stebėkite peržvalgų skaičių. Jei turite daug siuntėjų, galite viršyti 10 peržvalgų ribą. Jei taip atsitiks, konsoliduokite – kai kurie tiekėjai siūlo „SPF išlyginimą” arba pašalinkite siuntėjus, kurių nebeneaudojate.

6 žingsnis – vėl patikrinkite savo domeną, kad patvirtintumėte, jog dabar jis pereina, su esamu įrašu ir griežta politika.

Dažnos klaidos

Du SPF įrašai. Dažniausia tyli gedimo forma. Pridedant naują įrašą vietoj esamo redagavimo, abu netenka galios. Turi būti tiksliai vienas.
Sustojimas ties ~all ir manant, kad baigta. Minkštas nepavykimas be DMARC yra silpna vidurinioji zona – atrodo sukonfigūruota, bet beveik neapsaugo. Arba eikite į -all, arba poruokite ~all su DMARC p=reject.
Siuntėjo pamiršimas. Sugriežtinus iki -all prieš išvardijant sąskaitų faktūrų programą, CRM ar naujienlaiškinį įrankį, pradėsite blokuoti savo teisėtą paštą. Pirmiausia išvardykite viską.
10 peržvalgų ribos viršijimas. Kiekvienas include: gali grandinuoti daugiau peržvalgų. Per daug – ir įrašas laikomas sugedusiu. Laikykite jį glaustą.
+all naudojimas. Tai aiškiai įgalioja visą internetą siųsti jūsų vardu. Tai blogiau nei neturėti jokio įrašo. Niekada to neskelbkite.

Kur tai dera

SPF yra pagrindas, bet tai yra vienas iš trijų sluoksnių. DKIM prideda kriptografinį parašą, įrodantį, kad žinutė nebuvo sugadinta, o DMARC yra nurodymas, kuris sujungia SPF ir DKIM ir sako gavėjams, ką daryti su laišku, kuris nepavyksta – įskaitant apsimetimo blokavimą matomo „nuo” vardo, kurį mato jūsų klientai. Pirmiausia teisingai nustatykite SPF (tai greičiausias laimėjimas ir turi didžiausią svorį), tada pridėkite DKIM ir DMARC, kad visiškai uždarytumėte duris. Visi trys pataisymai yra nemokami.

Nustatymas pas savo tiekėją

Žingsnis po žingsnio populiariems tiekėjams:

DUK

Aš nesu technikas – ar galiu tai sutvarkyti pats?

Jums nereikia suprasti detalių. Pakeitimas – tai viena ar dvi eilutės jūsų domeno nustatymuose, kurias atlieka tas, kas tvarko jūsų svetainę arba IT tiekėjas. Perduokite jiems toliau pateiktą skyrių „Kaip tai ištaisyti” – tai paprastai užtrunka kelias minutes ir yra nemokama. Mes imame mokestį tik už nuolatinę stebėseną, kad tai išliktų teisinga.

Mes jau turime SPF įrašą – ar tai reiškia, kad esame apsaugoti?

Nebūtinai. Turėti įrašą yra pirmoji pusė; turėti jį griežtai nustatytą yra antroji. Įrašas, kuris baigiasi '~all' (minkštas nepavykimas) be DMARC, sako gavimo serveriams 'tai gali būti netikra, bet vis tiek pristatykite' – tai teikia minimalią apsaugą. Du SPF įrašai arba vienas, turintis per daug peržvalgų, laikomas sugedusiu ir nesuteikia jokios apsaugos, nors atrodo, kad egzistuoja. Abi pusės turi būti teisingos.

Ar tai ištaisęs netyčia nesugadinsiu savo el. pašto?

Gali, jei įrašas praleis teisėtą siuntėją – pavyzdžiui, sąskaitų faktūrų programą ar naujienlaiškinį įrankį, kuris siunčia laiškus jūsų vardu. Štai kodėl saugus metodas yra pirmiausia išvardyti kiekvieną paslaugą, kuri siunčia paštą jūsų vardu, paskelbti su minkštu '~all', kol patvirtinate, kad nieko nepraleidžiama, tada sustiprinti iki kieto nepavykimo. Atlikta tokia tvarka, nieko nesugadins.

Koks skirtumas tarp '~all' ir '-all', ir kurį turėtume naudoti?

'-all' (kietas nepavykimas) sako gavėjams atmesti viską, kas nėra jūsų sąraše – stipriausia nuostata. '~all' (minkštas nepavykimas) sako 'tikriausiai neteisėta, bet vis tiek priimkite.' Šiuolaikinė geroji praktika rekomenduoja '~all' kartu su DMARC politika 'reject' – ši pora suteikia tokią pačią apsaugą kaip '-all' be rizikos, kad persiunčiami laiškai gali atšokti. '~all' vienas, be DMARC, yra silpna konfigūracija, kurios reikia vengti.

Ar SPF vienas sustabdys visą el. pašto klastojimą?

Ne – tai svarbus pirmasis sluoksnis, bet ne visas atsakymas. SPF nurodo, kurie serveriai gali siųsti jūsų vardu, bet nepasakoja gavėjams, ką daryti, kai laiškas nepavyksta, ir neapima matomo 'nuo' vardo, kurį mato naudotojas. Norint visiškai užrakinti apsimetimą, taip pat reikia DKIM ir DMARC. SPF yra greičiausias, aukščiausio poveikio pirmasis žingsnis, todėl pradėkite čia, tada pridėkite kitus du.

Kiek laiko tai įsigalios ir ar tai kainuos?

DNS pakeitimai paprastai įsigalioja per kelias minutes iki kelių valandų. Pats pataisymas visada yra nemokamas – tai tik nuostatos redagavimas jūsų DNS tiekėjui. Bet kas, kas sako, kad norint pridėti SPF įrašą reikia mokamos paslaugos, klysta.