SPF ~all vs -all: Softfail eller Hardfail — Hvad 139 millioner records valgte (2026)

Q: Er SPF ~all eller -all bedst?

Ingen af dem, universelt. ~all med en håndhævende DMARC-politik er det mønster, Googles retningslinjer anbefaler — samme beskyttelse hos DMARC-evaluerende modtagere uden at ødelægge videresendt mail. -all passer til stramt kontrollerede afsendere. ~all alene — tilstanden for alle på nær 1 ud af 11 softfail-domæner — er den svage mulighed.

Q: Hvad betyder SPF softfail?

~all fortæller modtagere, at mail fra ikke-listede servere sandsynligvis er illegitim, men stadig bør accepteres, som regel med mistanke. Det bliver først til reel beskyttelse, når en DMARC-politik handler på fejlen; se SPF uden DMARC.

Udgivet 2026-07-03

Tal pr. 2026-06-29 · metodologi v7. Aggregerede folketællingsdata på tværs af 261 millioner graderede domæner. Alle tal er aggregerede — vi offentliggør aldrig en enkelt virksomheds record. Se hvordan vi graderer.

Hver SPF-record ender på en “all”-mekanisme — dommen over mail fra ethvert sted, der ikke står på din liste — og internettet har overvældende valgt den bløde: 55.8% af de 139 millioner domæner, der publicerer SPF, ender på ~all (softfail), mod 39.3%, der ender på -all (hardfail). Ét tegn adskiller “afvis forfalskninger” fra “sandsynligvis en forfalskning — lever den alligevel”. Hvilken der er rigtig for dig, afhænger af en anden indstilling, som de fleste ejere aldrig konfigurerer.

Hvad fortæller ~all og -all egentlig en modtager?

-all (hardfail): “Afvis mail fra alle andre steder.” Et fast nej.
~all (softfail): “Mail fra andre steder er sandsynligvis ikke legitim — accepter den, markér den måske.” Et skuldertræk.
?all (neutral): “Ingen holdning.” Valgt af 3.0% af udgiverne; beskyttelse kun af navn.
+all: “Enhver må sende som mig.” Publiceret af 36,014 domæner, og værre end ingen record — velkomstmåtte-problemet har sin egen rapport.

Er ~all så forkert? Kun hvis det står alene — og det gør det næsten altid

Softfail har et forsvarligt moderne argument: Googles afsenderretningslinjer, og det meste leverbarhedspraksis med dem, konvergerer om ~all parret med en håndhævende DMARC-politik (p=reject). Parringen beskytter lige så godt som -all hos enhver DMARC-evaluerende modtager — hvilket nu omfatter alle de store postkasseudbydere — uden at hard-bounce legitim videresendt mail, det klassiske -all-offer. I den konfiguration har skuldertrækket bid: DMARC leverer den dom, SPF afstod fra at give.

Men parringen er hele pointen, og her er, hvad folketællingen tilføjer, som opsætningsguider ikke kan: af de 77,484,057 softfail-records på internettet har kun 7.1 millioner — omkring 1 ud af 11 — en håndhævende DMARC-politik bag sig. For de øvrige 70.4 millioner domæner er ~all præcis det, det lyder som. Deres record identificerer forfalskningen og vinker den videre.

Rettede 2024-kravene ikke dette?

Nej — og forskellen betyder mere, end det meste dækning antyder. Google og Yahoo begyndte at kræve autentificering fra masseafsendere i februar 2024, med Microsoft, der fulgte efter i maj 2025: bestået, alignet SPF eller DKIM, plus en DMARC-record på minimum p=none. Kravene går ikke så langt som til at kræve håndhævelse — et domæne med ~all, en p=none-record og alignet DKIM overholder kravene fuldt ud og forbliver fuldt forfalskbart. Kravene normaliserede papirarbejdet, ikke beskyttelsen. Den uhåndhævede midte — compliant, publiceret, forfalskbar — er præcis det hul, denne folketælling måler, og det er den største population i e-mailsikkerhed.

Så hvad bør din record ende på?

Du sender mail, og videresendelse betyder noget (nyhedsbreve, mailinglister, aliasser): ~all med DMARC p=reject bag — den anbefalede parring ovenfor.
Du sender mail fra en stramt kontrolleret opsætning: -all fungerer og angiver politikken i selve recorden. Kortlæg dine afsendere først — en streng slutning på en ukortlagt record ødelægger rigtig mail, eller værre.
Domænet sender aldrig: -all plus p=reject, i dag. Der findes intet legitimt at beskytte, så der er intet at ødelægge.

Uanset hvilken slutning du vælger, holder folketællingens ét-linjes lektie: kvalifikatoren betyder kun så meget, som det, der håndhæver den. Hvor du står på den stige, er målbart.

Ofte stillede spørgsmål

Er SPF ~all eller -all bedst? Ingen af dem, universelt. ~all med en håndhævende DMARC-politik er det mønster, Googles retningslinjer anbefaler — samme beskyttelse hos DMARC-evaluerende modtagere uden at ødelægge videresendt mail. -all passer til stramt kontrollerede afsendere. ~all alene — tilstanden for alle på nær 1 ud af 11 softfail-domæner — er den svage mulighed.

Hvad betyder SPF softfail? ~all fortæller modtagere, at mail fra ikke-listede servere sandsynligvis er illegitim, men stadig bør accepteres, som regel med mistanke. Det bliver først til reel beskyttelse, når en DMARC-politik handler på fejlen; se SPF uden DMARC.

Vil hardfail -all ødelægge min videresendte e-mail? Det kan den: videresendelse gensender din mail fra videresenderens server, som din SPF ikke lister, og en hardfail inviterer til afvisning, før DKIM eller DMARC vejer ind. Den risiko er grunden til, at parringen ~all + p=reject findes.

Kræver Google og Microsoft -all nu? Nej. Masseafsenderkravene kræver alignet, bestået autentificering og en DMARC-record på minimum p=none — ingen håndhævelse, ingen specifik kvalifikator. Googles afvisning af ikke-compliant massemail er live; Microsoft har junket fejl og bevæger sig mod direkte afvisning. Compliance er ikke beskyttelse.

Tjek, hvad din record ender på — og hvad der står bag den

To opslag fortæller dig begge dele, gratis, på 30 sekunder. Hvis du er ét af de 70.4 millioner uhåndhævede skuldertræk, er rettelsen en DNS-record, ikke et køb.

Tjek dit domæne → · Ret SPF → · Ret DMARC → · SPF-modenhedsmodellen → · +all-kortet → · Kun aggregerede data. Data lagret og behandlet i EU.