Defaults.Exposed › Oplossingen › Guides
SPF faalt voor uw SaaS-tools? Waarom het gebeurt en de reparatievolgorde — Europa-editie (2026)
Gepubliceerd 2026-07-08
Cijfers per 2026-06-29 · methodologie v7. Geaggregeerde censusgegevens over 261 miljoen beoordeelde domeinen. Zie hoe wij beoordelen.
Als een SaaS-tool “op SPF faalt”, is uw record meestal niet het probleem: de mail faalt op DMARC-alignment, of uw include-keten heeft de limiet van 10 DNS-lookups van SPF opgeblazen. 2.119.539 van de 138.927.207 SPF-publicerende domeinen zitten op 9–10 lookups — één SaaS-include van het klif — volgens de Defaults.Exposed-census van 261.086.232 domeinen.
Hieronder: hoe u vaststelt welk van de twee problemen u hebt, daarna de reparatievolgorde — eerst scannen, het domein vinden waarvandaan de tool echt verzendt, de leverancier omzetten naar custom-domain-DKIM, en alleen een SPF-include toevoegen waar die echt helpt — plus de details voor HubSpot, Salesforce, Mailchimp en SendGrid.
Waarom faalt mail van een SaaS-tool op SPF?
Drie patronen dekken vrijwel elk geval:
| Wat het rapport of de bounce zegt | Wat er werkelijk mis is | De oplossing |
|---|---|---|
| SPF slaagt, DMARC faalt toch | Alignment: de tool slaagde voor SPF op zijn bounce-domein, niet het uwe | Zet de custom-domain-DKIM van de leverancier aan (CNAME’s) |
SPF permerror | Uw include-keten overschrijdt de limiet van 10 DNS-lookups van SPF | Snoei de includes; zie de too-many-lookups-oplossing |
SPF fail / softfail | De tool verzendt echt met uw return-path en staat niet in uw record | Voeg de include van de leverancier toe of activeer zijn eigen bounce-domein |
Gegevens per 2026-06-29.
De vetgedrukte rij is waar de meeste mensen staan. include:-regels toevoegen voor elke tool verandert daar niets aan — en elke regel brengt u dichter bij de tweede rij: minstens 797.263 domeinen zijn de 10-lookuplimiet al gepasseerd, en hun SPF geeft nu een PermError terug die niets beschermt. De volledige cijfers staan in het SPF-PermError-rapport.
Welk domein controleert SPF eigenlijk?
Niet het domein in uw From-header. Ontvangende mailservers evalueren SPF tegen het Return-Path-domein (het RFC5321.MailFrom, ook wel het bounce- of envelope-from-adres) — de From-header die uw ontvanger ziet, speelt in de SPF-controle zelf geen rol.
Dit ene feit verklaart de meeste “SaaS-SPF-fouten”. Uw marketingplatform verzendt met een Return-Path als [email protected]; SPF wordt gecontroleerd tegen vendor.com en slaagt netjes. Vervolgens vraagt DMARC of dat SPF-gecontroleerde domein overeenkomt met uw From-domein. Dat doet het niet, dus de SPF-poot van DMARC faalt en uw dashboard meldt “SPF failing”. Uw eigen SPF-record bewerken kan dat niet oplossen — uw record is nooit geraadpleegd.
Wat is de reparatievolgorde?
- Voer eerst de gratis scan uit. Die vertelt u in één keer of uw SPF ontbreekt, dubbel staat, over de lookuplimiet zit of in orde is, en hoe DMARC ervoor staat — voordat u DNS aanraakt.
- Vind het Return-Path dat de tool daadwerkelijk gebruikt. Stuur uzelf een testmail vanuit de tool en lees de Return-Path-header (en Authentication-Results) in het ruwe bericht. Dat vertelt u in welke rij van de tabel hierboven u zit.
- Zet de custom-domain-DKIM van de leverancier aan. Elke serieuze SaaS-tool biedt “domain authentication”: een paar CNAME-records waarmee hij DKIM-ondertekent als uw domein. Die handtekening aligneert met uw From-domein, dus DMARC slaagt via DKIM — duurzaam, en zelfs wanneer mail wordt doorgestuurd. Dit is de oplossing die blijft werken.
- Voeg de SPF-include van de leverancier alleen toe als hij uw return-path gebruikt — u hebt zijn eigen bounce-domein geactiveerd, of hij verzendt echt met uw domein in de envelop. Een include voor een leverancier die bouncet via zijn eigen domein levert niets op en verbruikt uw lookupbudget.
- Tel uw DNS-lookups voordat u opslaat. De limiet is 10 opgeloste lookups, includes tellen recursief, en 2.119.539 domeinen zitten al op 9–10 — de census-p99 is 9. Zit u tegen de rand? Verwijder eerst includes voor tools die u niet meer gebruikt. Net van e-mailprovider gewisseld? Controleer op een achtergebleven tweede record — twee SPF-records staat gelijk aan een PermError.
- Scan opnieuw en bevestig. SPF slaagt op het juiste domein, DKIM gealigneerd, DMARC slaagt. De volledige referentie staat op hoe u SPF repareert; providerhandleidingen zoals SPF op GoDaddy en DMARC op IONOS behandelen de klikken in het DNS-paneel.
Wat moet u doen voor HubSpot, Salesforce, Mailchimp en SendGrid?
HubSpot. Koppel uw verzenddomein in de instellingen van HubSpot en publiceer de twee DKIM-CNAME’s die het uitgeeft (hs1-… / hs2-…). Dat aligneert DKIM met uw From-domein. U hebt geen HubSpot-SPF-include nodig, tenzij u HubSpot hebt geconfigureerd om uw eigen bounce-domein te gebruiken.
Salesforce. Maak een DKIM-sleutel aan in Salesforce Setup en publiceer het CNAME-paar dat wordt gegenereerd. Als Salesforce verzendt met het return-path van uw organisatie, voeg dan include:_spf.salesforce.com toe en configureer het bounce-domein — dit is het ene grote CRM waar de SPF-include vaak echt nodig is.
Mailchimp. Authenticeer uw domein en publiceer de k2- / k3-DKIM-CNAME’s. Mailchimp-alignment is uitsluitend DKIM — er is geen SPF-include meer om toe te voegen, en er een uit een oude tutorial toevoegen verspilt alleen lookups.
SendGrid. Voltooi domain authentication (“automated security”): drie CNAME’s die zowel DKIM als het return-path op uw eigen subdomein afhandelen. Geen SPF-include nodig. Van de 740.321 domeinen waarvan de SPF sendgrid.net autoriseert, heeft slechts 18,0% een afdwingende DMARC (gegevens per 2026-06-29) — de meeste SendGrid-verzenders stoppen één stap te vroeg.
Zendesk en al het andere: hetzelfde patroon. Zoek de “domain authentication”-pagina van de tool, publiceer zijn DKIM-CNAME’s, en raak SPF alleen aan als de tool documenteert dat hij uw return-path gebruikt.
Is SPF anders voor Europese bedrijven?
Nee — SPF, DKIM en DMARC werken overal identiek. Wat in Europa verschilt is de context: wie het vraagt, en wat uw buren al hebben gedaan.
Uw ccTLD bepaalt de lokale lat. Europese ccTLD’s publiceren SPF ruim boven de .com-percentages, maar de domeinen die het karwei afmaken — met daarbovenop een afdwingend DMARC-beleid — zijn overal de minderheid:
| TLD | SPF-adoptie (van beoordeelde domeinen) | Afdwingende DMARC (van beoordeelde domeinen) |
|---|---|---|
| .nl | 75,91% | 29,43% |
| .ie | 70,89% | 8,79% |
| .de | 64,67% | 21,38% |
| .dk | 50,42% | 19,88% |
| .com | 54,14% | 9,50% |
Gegevens per 2026-06-29. Frankrijk: 13,65% afdwingende DMARC; Italië: 5,24%.
De standaardinstelling van uw Europese host doet ertoe. 4.346.526 domeinen autoriseren de EU-mailservers van IONOS (_spf-eu.ionos.com) in hun SPF — en slechts 0,3% eindigt op strikte -all, met 1,0% DMARC-afgedwongen. De 2.132.049 van OVH doen het beter op striktheid (43,7%), maar slechts 2,2% dwingt DMARC af (gegevens per 2026-06-29). Als u uw record nooit hebt aangeraakt, staat u op die standaardinstellingen.
Toezichthouders benoemen dit nu. NIS2 artikel 21(2)(j) verplicht entiteiten binnen de reikwijdte om hun communicatie te beveiligen, en Uitvoeringsverordening (EU) 2024/2690 van de Commissie werkt de e-mail- en DNS-beveiligingsmaatregelen uit. E-mailauthenticatie is het concrete, controleerbare onderdeel — en, ongebruikelijk voor compliance, gratis op te lossen.
Over datalocatie: de Defaults.Exposed-scanner en -census draaien in AWS eu-west-1, wij publiceren uitsluitend geaggregeerde cijfers, en een scan controleert alleen het domein waar u om vraagt.
Veelgestelde vragen
Mijn SPF-checker zegt “pass”, maar het dashboard van de tool zegt dat SPF faalt — hoe kan dat? De checker testte uw record; de ontvangende server testte het Return-Path-domein dat de tool daadwerkelijk gebruikte, en DMARC vergeleek dat vervolgens met uw From-domein. Dat is een alignmentfout, geen recordfout — op te lossen met de custom-domain-DKIM van de leverancier, niet met SPF-aanpassingen.
Zal ik gewoon de SPF-include toevoegen voor elke tool die we gebruiken? Nee. Elke include verbruikt een deel van het 10-lookupbudget van SPF, recursief: 2.119.539 van de 138.927.207 SPF-publicerende domeinen zitten op 9–10 lookups, en minstens 797.263 zitten erover — hun SPF geeft PermError terug en beschermt niets (gegevens per 2026-06-29).
Lost de include DMARC ook op? Alleen als de tool verzendt met uw return-path, zodat SPF slaagt én aligneert. Voor de meeste SaaS-tools is dat niet zo — en daarom is gealigneerde DKIM, niet SPF, de poot die DMARC laat slagen voor SaaS-mail.
Is dit een wettelijke verplichting in de EU? Voor entiteiten binnen de reikwijdte van NIS2 maken artikel 21(2)(j) en Uitvoeringsverordening (EU) 2024/2690 e-mailbeveiliging een verplichting. Ook daarbuiten vragen verzekeraars en klantvragenlijsten er steeds vaker naar — en per 2026-06-29 krijgt geen enkel EU-ccTLD zelfs maar een derde van zijn domeinen naar een afdwingend DMARC-beleid (29,43% in .nl op zijn best; 5,24% in .it).
Stuur de eigenaar het rapport
Zodra de CNAME’s live zijn, voert u de scan opnieuw uit en stuurt u het beoordeelde rapport door naar de bedrijfseigenaar of klant. Het laat in gewone taal zien wat er faalde, wat u hebt gerepareerd en waar het domein nu staat — precies het bewijs dat zij nodig hebben voor de verzekeringsverlenging of de beveiligingsvragenlijst van de klant, zwart op wit in plaats van op uw woord.
Controleer uw domein gratis
Zie precies welke poot van SPF, DKIM en DMARC faalt — privé en alleen voor de eigenaar.
Controleer uw domein → · Repareer SPF → · SPF PermError: “too many DNS lookups” → · Hoe wij beoordelen → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.