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žklausą daranč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 apie save nepraneša niekada.

-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 -all užklausų ribą viršijusio įrašo gale — tai griežtumas, prisegtas prie negyvo įrašo: vis tiek laimi permerror.

Ne — ir gedimas žiaurus. RFC 7208 sako, kad keli v=spf1 įrašai verčia patikrą grąžinti permerror: ne „laimi pirmas“, ne „jie susilieja“ — abu tampa negaliojantys. Paprastai tai nutinka nekaltai: svetainės papildinys, laiškų platformos vedlys arba antras administratorius „prideda SPF“, nepastebėjęs jau esančio įrašo. Pataisymas trunka minutę: sujunkite visus mechanizmus į vieną įrašą, likusius ištrinkite. Būtent dėl to šis įrankis pirmiausia suskaičiuoja jūsų įrašus.

Jis užbaigia jūsų įrašą fraze „…ir visi kiti taip pat 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, tas suklastotas laiškas praeis ir DMARC — jūsų autentikacija dabar laiduoja už užpuoliką. Tai iš tiesų blogiau, nei neskelbti SPF išvis, nes „jokio įrašo“ gavėjų serverius padaro įtarius, o „+all“ — pasitikinčius. Gyvenime jis pasitaiko kaip klaidingas pristatomumo „pataisymas“. Jei šis įrankis tokį ras, pasakys labai aiškiai.

Vienas — ne. SPF tikrina voko siuntėją (adresą, naudojamą SMTP pokalbyje), o ne From: eilutę, kurią mato skaitytojas. Klastotojas gali praeiti SPF savo domene, o rodyti jūsų. Užkišti šią spragą yra DMARC darbas: jis reikalauja, kad matomas From sutaptų su tuo, ką patikrino SPF arba DKIM. Jis taip pat nurodo gavėjams, ką daryti, kai nesutampa. Visą rinkinį sudaro SPF + DKIM + DMARC, o šis įrankis patikrina, ar tvirtai stovi SPF atrama, nes permerror čia 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.