Defaults.Exposed › Jelentések

SPF ~all vs -all: Softfail vagy Hardfail — Mit választott 139 millió rekord (2026)

Közzétéve 2026-07-03

Adatok: 2026-06-29 · módszertan v7. Összesített cenzusadatok 261 millió osztályozott domainre. Minden szám összesített — soha nem közöljük egyetlen vállalkozás konkrét rekordját sem. Lásd: hogyan osztályozunk.

Minden SPF-rekord egy „all” mechanizmussal zárul — ez a verdikt a listádon nem szereplő bárhonnan érkező levelekre —, és az internet elsöprő többségben a lágy változatot választotta: az SPF-et közzétevő 139 millió domain 55.8%-a ~all-lal (softfail) zárul, szemben a -all-lal (hardfail) záruló 39.3%-kal. Egyetlen karakter választja el a „hamisítványok elutasítását” a „valószínűleg hamisítvány — kézbesítsd mégis” állítástól. Hogy melyik a jó neked, az egy második beállításon múlik, amelyet a legtöbb tulajdonos soha nem konfigurál.

Mit mond valójában a ~all és a -all egy fogadó félnek?

• -all (hardfail): „Utasítsd el a máshonnan érkező leveleket.” Határozott nem.
• ~all (softfail): „A máshonnan érkező levél valószínűleg nem legitim — fogadd el, esetleg jelöld meg.” Egy vállrándítás.
• ?all (neutral): „Nincs véleményem.” A közzétevők 3.0%-a választotta; védelem csak névleg.
• +all: „Bárki küldhet a nevemben.” 36,014 domain teszi közzé, és rosszabb, mint ha nem lenne rekord — az üdvözlőszőnyeg-problémának saját jelentése van.

Rossz akkor a ~all? Csak ha egyedül áll — és szinte mindig egyedül áll

A softfailnek van védhető, modern érve: a Google feladói irányelvei, és velük a legtöbb kézbesíthetőségi gyakorlat, a ~all és egy kikényszerítő DMARC-házirend (p=reject) párosításához konvergálnak. A párosítás minden DMARC-t kiértékelő fogadónál — amelybe ma már minden nagy postafiók-szolgáltató beletartozik — ugyanolyan jól véd, mint a -all, anélkül, hogy keményen visszapattintaná a legitim továbbított levelet, a -all klasszikus áldozatát. Ebben a konfigurációban a vállrándításnak foga van: a DMARC szolgáltatja azt a verdiktet, amelyet az SPF megtagadott.

De a párosítás a lényeg, és íme, amit a cenzus hozzátesz, amit a beállítási útmutatók nem tudnak: az interneten lévő 77,484,057 softfail rekord közül csak 7.1 millió — nagyjából minden 11. — rendelkezik mögötte kikényszerítő DMARC-házirenddel. A másik 70.4 millió domain esetében a ~all pontosan az, aminek hangzik. A rekordjuk azonosítja a hamisítványt, és átengedi.

Nem oldották meg ezt a 2024-es rendelkezések?

Nem — és a különbség fontosabb, mint azt a legtöbb híradás sugallja. A Google és a Yahoo 2024 februárjában kezdte megkövetelni a hitelesítést a tömeges feladóktól, a Microsoft 2025 májusában követte őket: átmenő, igazított SPF vagy DKIM, plusz egy DMARC-rekord legalább p=none szinten. A rendelkezések nem mennek el a kikényszerítés megköveteléséig — egy ~all-lal, p=none rekorddal és igazított DKIM-mel rendelkező domain teljes mértékben megfelel, és teljes mértékben hamisítható marad. A rendelkezések a papírmunkát normalizálták, nem a védelmet. Ez a ki nem kényszerített középmező — megfelelő, közzétett, hamisítható — pontosan az a rés, amelyet ez a cenzus mér, és ez a legnagyobb populáció az e-mail-biztonságban.

Akkor mivel zárjon a rekordod?

1. Küldesz levelet, és a továbbítás számít (hírlevelek, levelezőlisták, aliasok): ~all mögötte DMARC p=reject-tel — a fent ajánlott párosítás.
2. Szigorúan ellenőrzött rendszerből küldesz levelet: a -all működik, és magában a rekordban kimondja a házirendet. Előbb térképezd fel a feladóidat — egy szigorú zárás egy fel nem térképezett rekordon tönkreteszi a valós levelezést, vagy rosszabb.
3. A domain soha nem küld: -all plusz p=reject, még ma. Nincs védendő legitim forgalom, így nincs mit tönkretenni.

Bármelyik zárást választod, a cenzus egysoros tanulsága érvényes: a minősítő csak annyit számít, amennyit a mögötte álló kényszerítő elem. Hogy hol állsz ezen a ranglétrán, az mérhető.

Gyakran ismételt kérdések

Az SPF ~all vagy -all a jobb? Egyik sem egyetemesen. A ~all egy kikényszerítő DMARC-házirenddel az a minta, amelyet a Google irányelvei ajánlanak — egyenértékű védelem a DMARC-t kiértékelő fogadóknál a továbbított levelek tönkretétele nélkül. A -all a szigorúan ellenőrzött feladókhoz illik. A ~all önmagában — a softfail domainek minden 11. domainje kivételével ez a helyzet — a gyenge lehetőség.

Mit jelent az SPF softfail? A ~all azt mondja a fogadóknak, hogy a nem listázott szerverekről érkező levél valószínűleg nem legitim, de mégis el kell fogadni, általában gyanakvással. Csak akkor válik valódi védelemmé, ha egy DMARC-házirend cselekszik a hibára; lásd: SPF DMARC nélkül.

Tönkreteszi a hardfail -all a továbbított e-mailjeimet? Előfordulhat: a továbbítás a leveledet a továbbító szerveréről küldi újra, amelyet az SPF-ed nem listáz, és egy hardfail elutasításra hív, mielőtt a DKIM vagy a DMARC latba esne. Ez a kockázat az oka annak, hogy létezik a ~all + p=reject párosítás.

Megköveteli most a Google és a Microsoft a -all-t? Nem. A tömeges feladókra vonatkozó rendelkezések igazított, átmenő hitelesítést és egy DMARC-rekordot követelnek meg legalább p=none szinten — kikényszerítés nélkül, konkrét minősítő nélkül. A Google elutasítása a nem megfelelő tömeges levelekre él; a Microsoft levélszemétbe teszi a hibákat, és a teljes elutasítás felé halad. A megfelelés nem védelem.

Ellenőrizd, mivel zárul a rekordod — és mi áll mögötte

Két lekérdezés mindkettőt megmondja, ingyen, 30 másodperc alatt. Ha te vagy a 70.4 millió ki nem kényszerített vállrándítás egyike, a javítás egy DNS-rekord, nem egy vásárlás.

Ellenőrizd a domained → · Javítsd az SPF-et → · Javítsd a DMARC-ot → · Az SPF-érettségi modell → · A +all térkép → · Kizárólag összesített adatok. Az adatok tárolása és feldolgozása az EU-ban történik.