SPF ~all of -all: softfail of hardfail in 2026?

Gepubliceerd op 2 november 2026 · 6 min. leestijd · spFlat! Blog

Elk SPF-record eindigt met een all-mechanisme, en het teken daarvoor is waarschijnlijk het meest besproken teken in de hele e-mailauthenticatie. Moet je record eindigen op ~all (softfail) of op -all (hardfail)?

Het korte antwoord voor 2026: verstuurt je domein e-mail en gebruik je DMARC, kies dan ~all. Verstuurt je domein nooit e-mail, kies dan -all. Het lange antwoord legt uit waarom de strenger ogende optie niet automatisch de veiligere is, en waarom geen van beide uitmaakt als je SPF-record kapot is.

De vier qualifiers op een rij

De qualifier geldt alleen voor e-mail van servers die nergens eerder in het record matchen. E-mail vanaf je vermelde ip4:-, ip6:- en include:-bronnen krijgt pass, hoe het record ook eindigt.

Wat softfail en hardfail volgens de standaard betekenen

RFC 7208 definieert fail als een expliciete uitspraak dat de verzendende host het domein niet mag gebruiken. softfail is zwakker: de host is waarschijnlijk niet gemachtigd, maar de domeineigenaar wil zich niet vastleggen. Geen van beide resultaten schrijft de ontvanger voor wat hij moet doen. Dat bepaalt het lokale beleid, en ontvangers verschillen daarin.

Zonder DMARC is dat verschil belangrijk, want dan is de qualifier je enige beleidssignaal. Met DMARC verandert het beeld volledig.

Waarom DMARC de qualifier minder belangrijk maakt

Het maakt DMARC niet uit hoe SPF faalde. DMARC stelt over SPF maar één vraag: is SPF geslaagd, met een domein dat aligned is met de From:-header? Softfail, fail en neutral zijn allemaal gewoon "niet geslaagd".

Met DMARC op p=reject geldt dus:

• ~all met DMARC p=reject: vervalste e-mail wordt geweigerd.
• -all met DMARC p=reject: vervalste e-mail wordt geweigerd.

De bescherming tegen spoofing is gelijk. De handhaving zit in je DMARC-beleid, niet in de laatste vier tekens van je SPF-record. (Is alignment nieuw voor je? Lees dan eerst SPF vs DKIM vs DMARC.)

Het echte risico van -all: weigering voordat DMARC draait

Sommige ontvangers controleren SPF zodra de verzendende server MAIL FROM doorgeeft, dus nog voordat het bericht zelf binnen is. Staat er -all in je record en staat het verzendende IP-adres er niet in, dan kan de ontvanger direct weigeren. DKIM wordt nooit gecontroleerd en DMARC draait nooit.

De DMARC-specificatie waarschuwt hier zelf voor. RFC 7489 (paragraaf 10.1) wijst erop dat -all kan leiden tot een vroege weigering, nog voordat er enige DMARC-verwerking plaatsvindt.

Dat doet pijn in precies de situaties waarin DMARC het bericht had gered:

• Doorsturen. Een ontvanger stuurt je e-mail door vanaf een oud adres, of een mailinglijst verspreidt hem. De doorstuurserver staat niet in je SPF-record, dus SPF faalt. DKIM was nog steeds geldig en aligned geweest, maar het bericht is al gebounced.
• Een afzender waar niemand van wist. Marketing gaat een nieuw platform gebruiken dat met DKIM ondertekent, maar nog niet in je SPF-record staat. Met ~all slaagt DMARC via DKIM. Met -all weigeren sommige ontvangers het bericht.
• Verouderde IP-lijsten. Een provider voegt adresbereiken toe en je handmatig geflattende record bevat ze nog niet.

Daarom raadt M3AAWG (de Messaging, Malware and Mobile Anti-Abuse Working Group) in de Email Authentication Recommended Best Practices ~all aan voor domeinen die e-mail versturen.

Wat moet je kiezen?

Een domein dat nooit e-mail verstuurt, sluit je volledig af:

example.com.         TXT  "v=spf1 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject"
example.com.         MX   0 .

De laatste regel is een null MX (RFC 7505): het domein neemt ook geen e-mail aan. Hier heeft -all geen nadeel, want er is geen legitieme e-mail die verloren kan gaan.

Geen van beide helpt als SPF stuk is

Dit alles gaat ervan uit dat SPF daadwerkelijk wordt geëvalueerd. Heeft je record meer dan 10 DNS-lookups nodig, dan stopt de controle met een PermError voordat all ooit wordt bereikt. Je zorgvuldig gekozen qualifier wordt nooit gelezen, en voor DMARC is SPF gewoon niet geslaagd.

Hetzelfde geldt voor twee SPF-records op één domein, een syntaxfout of te veel void lookups. Zorg dus eerst dat het record werkt, voordat je over ~all of -all discussieert:

• Welke SPF-lookups echt tellen
• SPF PermError oplossen
• SPF-flattening uitgelegd

Met spFlat! bestaat je record uit één korte spFlat!-include. spFlat! stelt daarbij ~all voor, in lijn met het advies hierboven, en houdt de IP-lijst achter die include actueel. Het record zelf staat in je eigen DNS, dus wil je voor een domein bewust -all, dan kun je het einde zelf aanpassen. Omdat de IP-lijst actueel blijft, verdwijnt ook het probleem van verouderde lijsten dat -all riskant maakt bij handmatig geflattende records.

Voordat je de qualifier aanpast

1. Controleer of je SPF-record zonder fouten wordt geëvalueerd en onder de 10 lookups blijft.
2. Zorg dat elke verzendende dienst met DKIM ondertekent, aligned met je domein.
3. Lees een paar weken je DMARC-aggregaatrapporten en zoek naar legitieme bronnen waarbij SPF faalt.
4. Zet DMARC op p=quarantine en daarna op p=reject.
5. Kies pas dan je qualifier. Voor de meeste verzendende domeinen blijft het ~all.

Samenvatting

• ~all voor domeinen die e-mail versturen, -all voor domeinen die dat nooit doen.
• Met afgedwongen DMARC bieden softfail en hardfail dezelfde bescherming tegen spoofing.
• -all kan tot weigering leiden voordat DKIM en DMARC draaien, en breekt zo doorgestuurde e-mail.
• Een PermError maakt de hele vraag zinloos. Repareer eerst het record.