SPF ~all vs -all: Softfail eller Hardfail — vad 139 miljoner poster valde (2026)

Q: Är SPF ~all eller -all bättre?

Inget av dem, generellt sett. ~all med en tvingande DMARC-policy är mönstret som Googles riktlinjer rekommenderar — likvärdigt skydd hos DMARC-utvärderande mottagare utan att bryta vidarebefordrad post. -all passar strikt kontrollerade avsändare. ~all ensamt — tillståndet för alla utom 1 av 11 softfail-domäner — är det svaga alternativet.

Q: Vad betyder SPF softfail?

~all talar om för mottagare att post från olistade servrar förmodligen är illegitim men ändå bör tas emot, oftast med misstänksamhet. Det blir verkligt skydd först när en DMARC-policy agerar på felet; se SPF utan DMARC.

Publicerad 2026-07-03

Siffror per 2026-06-29 · metodik v7. Aggregerad folkräkningsdata över 261 miljoner betygsatta domäner. Alla siffror är aggregerade — vi publicerar aldrig en enskild verksamhets post. Se hur vi betygsätter.

Varje SPF-post slutar med en “all”-mekanism — utslaget för post från alla platser som inte finns på din lista — och internet har med överväldigande majoritet valt den mjuka: 55.8% av de 139 miljoner domäner som publicerar SPF slutar på ~all (softfail), mot 39.3% som slutar på -all (hardfail). Ett enda tecken skiljer “avvisa förfalskningar” från “förmodligen en förfalskning — leverera den ändå”. Vilket som är rätt för dig beror på en andra inställning som de flesta ägare aldrig konfigurerar.

Vad säger ~all och -all egentligen till en mottagare?

-all (hardfail): “Avvisa post från alla andra platser.” Ett bestämt nej.
~all (softfail): “Post från annat håll är förmodligen inte legitim — ta emot den, kanske flagga den.” En axelryckning.
?all (neutral): “Ingen åsikt.” Vald av 3.0% av publicerarna; skydd endast till namnet.
+all: “Vem som helst får skicka som mig.” Publicerad av 36,014 domäner, och sämre än ingen post alls — välkomstmatteproblemet har sin egen rapport.

Är ~all fel, då? Bara om det står ensamt — och det gör det nästan alltid

Softfail har ett försvarbart modernt argument: Googles avsändarriktlinjer, och den mesta leveransbarhetspraxisen med dem, konvergerar mot ~all i kombination med en tvingande DMARC-policy (p=reject). Kombinationen skyddar lika väl som -all hos varje DMARC-utvärderande mottagare — vilket nu inkluderar alla de stora e-postleverantörerna — utan att hårdstudsa legitim vidarebefordrad post, det klassiska -all-offret. I den konfigurationen har axelryckningen tänder: DMARC levererar utslaget som SPF avstod från att ge.

Men kombinationen är hela poängen, och här är vad folkräkningen tillför som installationsguider inte kan: av de 77,484,057 softfail-posterna på internet har bara 7.1 miljoner — ungefär 1 av 11 — en tvingande DMARC-policy bakom sig. För de andra 70.4 miljoner domänerna är ~all precis vad det låter som. Deras post identifierar förfalskningen och vinkar igenom den.

Löste inte 2024 års krav detta?

Nej — och skillnaden spelar större roll än den mesta bevakningen antyder. Google och Yahoo började kräva autentisering från massutskickare i februari 2024, och Microsoft följde efter i maj 2025: godkänd, justerad SPF eller DKIM, plus en DMARC-post på minst p=none. Kraven går inte så långt som att kräva tvingande efterlevnad — en domän med ~all, en p=none-post och justerad DKIM uppfyller kraven fullt ut, och förblir fullt förfalskningsbar. Kraven normaliserade pappersarbetet, inte skyddet. Den där icke-tvingande mellanzonen — regelefterlevande, publicerad, förfalskningsbar — är exakt det gap denna folkräkning mäter, och det är den största populationen inom e-postsäkerhet.

Så vad ska din post sluta med?

Du skickar post och vidarebefordran är viktig (nyhetsbrev, e-postlistor, alias): ~all med DMARC p=reject bakom sig — den rekommenderade kombinationen ovan.
Du skickar post från en strikt kontrollerad uppsättning: -all fungerar och anger policyn i själva posten. Kartlägg dina avsändare först — ett strikt slut på en okartlagd post bryter riktig post, eller värre.
Domänen skickar aldrig: -all plus p=reject, redan idag. Inget legitimt existerar att skydda, så det finns inget att bryta.

Vilket slut du än väljer håller folkräkningens enradslektion: kvalificeraren spelar bara roll i den mån något upprätthåller den. Var du står på den stegen är mätbart.

Vanliga frågor

Är SPF ~all eller -all bättre? Inget av dem, generellt sett. ~all med en tvingande DMARC-policy är mönstret som Googles riktlinjer rekommenderar — likvärdigt skydd hos DMARC-utvärderande mottagare utan att bryta vidarebefordrad post. -all passar strikt kontrollerade avsändare. ~all ensamt — tillståndet för alla utom 1 av 11 softfail-domäner — är det svaga alternativet.

Vad betyder SPF softfail? ~all talar om för mottagare att post från olistade servrar förmodligen är illegitim men ändå bör tas emot, oftast med misstänksamhet. Det blir verkligt skydd först när en DMARC-policy agerar på felet; se SPF utan DMARC.

Kommer hardfail -all att bryta min vidarebefordrade e-post? Det kan det: vidarebefordran skickar om din post från vidarebefordrarens server, som din SPF inte listar, och en hardfail bjuder in till avvisning innan DKIM eller DMARC vägs in. Den risken är anledningen till att kombinationen ~all + p=reject finns.

Kräver Google och Microsoft -all nu? Nej. Kraven på massutskickare kräver justerad, godkänd autentisering och en DMARC-post på minst p=none — ingen tvingande efterlevnad, ingen specifik kvalificerare. Googles avvisning av icke-regelefterlevande massutskick är aktiv; Microsoft har skräppostmarkerat fel och rör sig mot direkt avvisning. Regelefterlevnad är inte skydd.

Kontrollera vad din post slutar med — och vad som står bakom den

Två uppslagningar berättar båda för dig, gratis, på 30 sekunder. Om du är en av de 70.4 miljoner icke-tvingande axelryckningarna är åtgärden en DNS-post, inte ett köp.

Kontrollera din domän → · Åtgärda SPF → · Åtgärda DMARC → · SPF-mognadsmodellen → · +all-kartan → · Endast aggregerad data. Data lagras och behandlas inom EU.