SPF tikrintuvas:
ar jūsų įrašas telpa į 10 užklausų ribą?

Įveskite savo domeną viršuje. Nuskaitome jo TXT įrašus, patikriname, ar lygiai vienas prasideda v=spf1 (du — iškart klaida: jie nesusilieja, o žūva abu), tada išnagrinėjame kiekvieną mechanizmą pagal RFC 7208: kiekvienas include rekursyviai išskleidžiamas į medį, kiekviena DNS užklausa įskaičiuojama į 10, įvertinama galutinė all politika, o visi jūsų įrašo leidžiami IP diapazonai sudedami į vieną sąrašą. Nemokamai, be registracijos.

Tikrindamas SPF gavėjo serveris įvertins daugiausia 10 DNS užklausas atliekančių mechanizmų (RFC 7208 §4.6.4). Skaičiuojami include, a, mx, ptr, exists ir redirect, taip pat ir tie, kurie slepiasi jūsų tiekėjų include viduje. Ties 11-ąja užklausa vertinimas nutrūksta su permerror. Jūsų pusėje nė vienas laiškas negrįžta atgal; DMARC tiesiog laiko, kad jūsų domenas SPF neskelbia. Lūžis ateina pamažu, po vieną naują įrankį, ir niekada apie save nepraneša.

-all yra tikslas: atmesti tai, kas ne jūsų. ~all yra kelias į jį: „pažymėkite, bet neatmeskite“. Tai teisingas nustatymas, kol vis dar atrandate siuntėjus — tą sąskaitų programą, apie kurią niekas neužsiminė. Jis saugesnis ir tada, kai prarastas tikras laiškas kainuoja daugiau nei praleistas suklastotas. Dvi išlygos: įdiegus DMARC praktinis skirtumas sumažėja, nes DMARC neleisto laiško nepraleidžia abiem atvejais. O jei -all patenka į įrašo, viršijusio ribą, galą — tai griežtumas, prisegtas prie lavono: vis tiek laimi permerror.

Ne — ir šis gedimas ypač negailestingas. RFC 7208 nurodo, kad keli v=spf1 įrašai priverčia patikrą grąžinti permerror: ne „laimi pirmasis“, ne „jie susilieja“ — abu tampa negaliojantys. Dažniausiai taip nutinka netyčia: svetainės papildinys, laiškų platformos vedlys ar antras administratorius „prideda SPF“, nepastebėjęs jau esančio įrašo. Pataisyti užtenka minutės: sujunkite visus mechanizmus į vieną įrašą, o likusius ištrinkite. Būtent todėl šis įrankis pirmiausia suskaičiuoja jūsų įrašus.

Jis baigia jūsų įrašą žodžiais „…ir visi kiti irgi praeina“. Kiekvienas interneto IP tampa leistinu jūsų domeno siuntėju: jūsų adresą klastojantis šlamštininkas gauna SPF pass, o jei jūsų DMARC politika remiasi SPF suderinimu, toks suklastotas laiškas gali praeiti ir DMARC — jūsų autentikacija dabar laiduoja už užpuoliką. Tai iš tikrųjų blogiau, nei visai neskelbti SPF, nes „jokio įrašo“ atveju gavėjų serveriai budrūs, o „+all“ atveju — visiškai pasitiki. Praktikoje jis atsiranda kaip klaidingai suprastas pristatomumo „pataisymas“. Jei šis įrankis jį ras, apie tai praneš labai aiškiai.

Pati viena — ne. SPF tikrina voko siuntėją (adresą, naudojamą SMTP pokalbyje), o ne From: eilutę, kurią mato skaitytojas. Klastotojas gali praeiti SPF patikrą savo domene, o laiške rodyti jūsų. Šią spragą uždaro DMARC: jis reikalauja, kad matomas From sutaptų su tuo, ką patvirtino SPF ar DKIM, ir nurodo gavėjams, ką daryti, kai nesutampa. Visą sistemą sudaro SPF + DKIM + DMARC, o šis įrankis patikrina, ar tvirtai stovi SPF dalis, nes čia kilęs permerror tyliai pakerta ir kitas dvi.

Nuo lengviausio iki skausmingiausio: išmeskite tai, kas nieko nesiunčia — a ir mx išmetami be jokios rizikos, jei jūsų žiniatinklio serveris ir MX niekada nesiunčia laiškų. ptr pašalinamas visada. Atsisakykite negyvų tiekėjų — kiekvienas include turi atitikti paslaugą, už kurią vis dar mokate. Išskirstykite pagal subdomenus — leiskite naujienlaiškiams siųsti kaip news.yourdomain.com su savo įrašu ir sava riba. Kraštutinė priemonė — suplokštinimas: pakeitus include tiesioginiais ip4/ip6 diapazonais, tai nekainuoja nė vienos užklausos. Bet taip užšaldote tiekėjų tinklų kopiją — jiems persinumeravus jūsų įrašas tyliai pasensta. Plokštinkite tik turėdami įrankį ar stebėjimą, kuris tai reguliariai pertikrina.