Wat is SPF Include en hoe gebruik je het in je SPF-record?

Uw SPF-record geeft aan welke servers e-mail mogen versturen namens uw domein. Maar zodra u platforms van derden gaat gebruiken om e-mail te versturen, wordt het al snel ingewikkeld. Op dat moment kan een SPF-include-mechanisme uitkomst bieden.

In deze handleiding wordt uitgelegd wat een SPF-include is, hoe het werkt en hoe je met meerdere includes omgaat zonder je record te verstoren. Daarnaast bespreken we hoe je alles in overeenstemming houdt met DMARC, zodat je e-mails altijd in de inbox terechtkomen.

Wat is een SPF Record?

Een SPF-record, of Sender Policy Framework , is een DNS TXT-record dat alle servers en IP-adressen vermeldt die bevoegd zijn om e-mail te verzenden namens een bepaald domein.

Wanneer er een e-mail binnenkomt, controleert de ontvangende mailserver de DNS-records van de afzender om na te gaan of de e-mail afkomstig is van een geautoriseerde bron. Als het IP-adres van de afzender overeenkomt met een vermelding in het record, is de SPF-controle geslaagd. Zo niet, dan is de SPF-controle mislukt.

Wat SPF-records op zichzelf niet kunnen

SPF-mechanismen vormen de basis, maar er zijn beperkingen die het waard zijn om te begrijpen:

• Het controleert de afzender van de envelop, niet het zichtbare „Van“-adres dat ontvangers daadwerkelijk te zien krijgen
• Het gaat kapot tijdens het doorsturen van e-mail, wat betekent dat doorgestuurde e-mails vaak niet door de SPF-controle komen, zelfs als de oorspronkelijke afzender legitiem is
• Het kan op zichzelf domeinspoofing op het niveau van de From-header, waar de meeste phishingaanvallen zich op ontvangers richten

Daarom werkt SPF het beste als onderdeel van een bredere authenticatieconfiguratie die ook DKIM en DMARC. Het wordt ten zeerste aanbevolen om alle drie de protocollen samen te configureren voor de beste e-mailbeveiliging.

Wat is SPF inbegrepen?

Als SPF-records de regels zijn die bepalen wie er e-mail mag versturen vanaf uw domein, dan is het SPF Include-mechanisme de manier waarop u regels van anderen kunt overnemen.

Met het SPF-Include-mechanisme kan een domeineigenaar de bevoegdheid om e-mails te verzenden delegeren aan een ander domein door in zijn eigen SPF-record naar het SPF-record van dat domein te verwijzen. In plaats van elk IP-adres dat door een externe e-maildienst wordt gebruikt handmatig op te sommen, neemt u gewoon hun domein op, waarna de ontvangende server hun SPF-record ophaalt en evalueert als onderdeel van uw eigen record.

Waarom SPF Include bestaat

Tegenwoordig wordt e-mail zelden vanaf één enkele server verzonden.

De meeste organisaties maken gebruik van een combinatie van hun eigen mailserver en platforms van derden voor transactionele e-mails, marketingcampagnes, helpdesktools en CRM-systemen. Elk van deze diensten verstuurt namens u e-mails via hun eigen infrastructuur, waarbij ze gebruikmaken van IP-adressen die u niet rechtstreeks kunt vermelden.

Het SPF-inclusiemechanisme lost dit op door je in staat te stellen rechtstreeks naar het SPF-record van de externe dienst te verwijzen.

Wanneer de ontvangende server uw SPF-record controleert en een `include`-instructie tegenkomt, haalt hij als onderdeel van het validatieproces het SPF TXT-record van dat externe domein op en verwerkt hij dit. Als het verzendende IP-adres overeenkomt met een vermelding in het opgenomen record, is de SPF-controle geslaagd.

Hoe SPF Include er in de praktijk uitziet

Een standaard `include`-instructie voor SPF ziet er als volgt uit:

v=spf1 include:thirdpartydomain.com ~all

In dit voorbeeld zoekt de ontvangende server het SPF-record voor thirdpartydomain.com op en beoordeelt dit samen met de rest van uw records.

Als het verzendende IP-adres in dat record is geautoriseerd, voldoet de e-mail aan de SPF-vereisten voor uw domein.

Het 'include'-mechanisme is onmisbaar voor domeinen die het versturen van e-mails uitbesteden of voor verschillende e-mailbehoeften gebruikmaken van meerdere leveranciers. Zonder dit mechanisme zou je elk IP-adres dat door elke dienst wordt gebruikt handmatig moeten opsommen, wat onpraktisch en foutgevoelig is.

Hoe werkt het SPF-opnameproces?

Als je het 'include'-mechanisme van SPF op technisch niveau begrijpt, kun je configuratiefouten voorkomen die ervoor zorgen dat SPF onopgemerkt faalt. Dit is wat er gebeurt wanneer een ontvangende server een SPF-record evalueert dat 'include'-instructies bevat.

Het SPF-validatieproces

Wanneer een e-mail bij een ontvangende mailserver binnenkomt, haalt de server het domein uit het MAIL FROM-adres en voert een DNS-lookup om het SPF TXT-record van dat domein op te halen. Vervolgens leest de server het record van links naar rechts en evalueert elk mechanisme totdat er een overeenkomst wordt gevonden of het einde van het record wordt bereikt.

Wanneer het een include-instructie tegenkomt, gebeurt het volgende:

1. De ontvangende server voert een extra DNS-opzoeking uit om het SPF TXT-record van het betreffende domein op te halen
2. Het vergelijkt het SPF-record van het betreffende domein met het IP-adres van de afzender
3. Als het IP-adres overeenkomt met een geautoriseerde vermelding in het opgenomen record, geeft het opnamemechanisme een positief resultaat terug
4. Als er geen overeenkomst wordt gevonden, gaat de server verder met het beoordelen van de overige mechanismen in het oorspronkelijke record

Hoe tellen inclusies mee voor de limiet van DNS-opzoekingen

Elke `include`-vermelding in een SPF-record leidt tot ten minste één extra DNS-verzoek. Dit is belangrijk omdat de SPF-validatie beperkt is tot maximaal tien DNS-opzoekingen per controle.

Elke include, evenals mechanismen zoals mx en a, telt mee voor deze limiet. Als het SPF-record van het opgenomen domein zelf nog meer includes bevat, tellen die ook mee, waardoor een reeks opzoekacties ontstaat die snel kan oplopen.

Als de limiet van tien zoekopdrachten wordt overschreden, geeft SPF een PermError terug, wat door ontvangende servers als een SPF-fout wordt beschouwd. Dit kan ertoe leiden dat e-mails worden geweigerd of in de spamfolder terechtkomen, zelfs als de afzender volkomen legitiem is.

Syntaxis van SPF-records: hoe schrijf je een SPF-include op de juiste manier?

Een correcte syntaxis is absoluut noodzakelijk. Eén enkele fout in je syntaxis van je SPF-record kan ervoor zorgen dat het hele record mislukt, ongeacht hoe goed de rest is geconfigureerd.

De basisstructuur van een SPF-record

Alle SPF-records hebben dezelfde basisstructuur:

v=spf1 [mechanismen] [voorwaarde:alle]

• v=spf1 geeft de SPF-versie aan en moet aan het begin van elk SPF TXT-record staan
• mechanismen bepalen de geautoriseerde verzendbronnen, waaronder IP-adressen, domeinen via include, MX-records en meer
• alles is het vangnetmechanisme dat bepaalt wat er gebeurt met e-mails die niet overeenkomen met een van de vermelde bronnen

Een SPF-include-instructie schrijven

De juiste syntaxis voor een include-instructie is:

bijvoorbeeld:domain.com

Let op: er mag geen spatie staan tussen `include` en de dubbele punt. Een spatie leidt tot een syntaxfout. Hier volgt een volledig voorbeeld van een SPF-record met meerdere `include`-vermeldingen:

v=spf1 include:sendgrid.net include:mailchimp.com ip4:192.168.1.1 ~all

In dit document:

• sendgrid.net en mailchimp.com zijn via `include` geautoriseerd als externe afzenders
• 192.168.1.1 is een individueel geautoriseerd IP-adres
• ~alles is een softfail, wat betekent dat e-mails van onbevoegde afzenders worden gemarkeerd, maar niet direct geweigerd

Veelvoorkomende syntaxfouten die je moet vermijden

• Het publiceren van meer dan één SPF TXT-record voor hetzelfde domein. Meerdere SPF-records leiden tot een DNS-opzoekingslus, waardoor SPF volledig faalt. U moet alles samenvoegen tot één enkel record per domein of subdomein
• Een spatie toevoegen na de dubbele punt in een include-instructie
• Het gebruik van onjuiste kwalificaties of mechanismen die met elkaar in strijd zijn
• Vergeten om de opname af te sluiten met een 'all'-commando

Je kunt de SPF-recordgenerator om vanaf nul een correct opgemaakt record te maken. U kunt ook uw bestaande record door een SPF-record-opzoektool om te controleren op fouten voordat deze problemen met de afleverbaarheid veroorzaken.

SPF-record met meerdere includes: wat u moet weten

Het gebruik van meerdere SPF-includes is gebruikelijk en vaak noodzakelijk, maar het brengt complexiteit met zich mee die zorgvuldig moet worden beheerd. Hier vind je alles wat je moet weten over het omgaan met een SPF-record met meerdere includes.

Waarom er meerdere includes nodig zijn

De meeste organisaties versturen e-mails via meer dan één platform. Een veelvoorkomende opzet zou er als volgt uit kunnen zien:

• Een primaire e-mailserver voor interne en uitgaande e-mail
• Een e-maildienst voor transacties, zoals orderbevestigingen en meldingen
• Een marketingplatform voor nieuwsbrieven en campagnes
• Een CRM- of helpdesktool voor communicatie met klanten

Elk van deze diensten moet in uw SPF-record worden geautoriseerd, en de handigste manier om dat te doen is door middel van `include`-instructies die verwijzen naar het SPF-record van elke provider.

Het probleem met de limiet voor DNS-opzoekingen

Dit is waar het gebruik van meerdere includes risico’s met zich meebrengt.

Elke `include`-instructie leidt tot ten minste één DNS-opzoeking, en sommige SPF-records van derden bevatten zelf weer verdere `include`-instructies, waardoor er nog meer opzoekingen bijkomen. Tegen de tijd dat je vier of vijf platforms hebt geautoriseerd, ben je mogelijk al dicht bij de limiet van tien opzoekingen of heb je die zelfs al overschreden.

Hier volgt een eenvoudig voorbeeld van hoe opzoekingen bij elkaar opgeteld worden:

• omvat: sendgrid.net = 1 opzoekactie, plus eventuele opzoekacties binnen het eigen record van SendGrid
• omvat: mailchimp.com = 1 opzoekactie, plus alle vermeldingen in het bestand van Mailchimp
• omvat: salesforce.com = 1 opzoekactie, plus eventuele opzoekacties binnen het record van Salesforce
• mx = 1 opzoekactie
• Het totaal kan gemakkelijk 10 bereiken of overschrijden

Wanneer de limiet wordt overschreden, retourneert de ontvangende server een PermError en behandelt de e-mail als een SPF-authenticatiefout.

Hoe je binnen de limiet voor DNS-opzoekingen blijft

• Controleer uw huidige SPF-record en tel het totale aantal DNS-lookups dat hierdoor wordt geactiveerd, inclusief geneste lookups binnen opgenomen records
• Verwijder alle include-instructies voor services die je niet meer gebruikt
• Vervang waar mogelijk `include`-mechanismen door directe IPv4- of IPv6-vermeldingen voor diensten waarvan de IP-bereiken statisch en goed gedocumenteerd zijn
• Gebruik de SPF-afvlakkingstool die automatisch include-ketens oplost en vervangt door directe IP-adressen, waardoor het totale aantal lookups wordt verminderd
• Controleer uw gegevens regelmatig wanneer u een verzendplatform toevoegt of verwijdert

Altijd één SPF-record per domein

Een belangrijke regel die geldt ongeacht het aantal includes dat u beheert: publiceer nooit meer dan één SPF TXT-record voor hetzelfde domein of subdomein.

Meerdere SPF-records leiden tot een onmiddellijke fout en kunnen door geen enkele ontvangende server worden verwerkt. Alles moet worden samengevoegd tot één enkel record.

Als u e-mails verstuurt vanaf subdomeinen, moet elk subdomein een eigen, afzonderlijk SPF TXT-record hebben.

Veelgemaakte fouten bij het gebruik van SPF en hoe je deze kunt vermijden

SPF-records zijn krachtig, maar laten geen fouten door. Eén enkele verkeerde configuratie kan leiden tot authenticatiefouten in uw gehele e-mailverkeer, en het frustrerende is dat veel van deze fouten geen duidelijke foutmelding geven. Of u nu voor het eerst SPF instelt of een bestaand record controleert: dit zijn de fouten waar u op moet letten en hoe u ze precies kunt voorkomen.

SPF Include en naleving van DMARC

SPF-inclusies werken niet op zichzelf. Hoe u ze configureert, heeft een directe invloed op uw DMARC-conformiteit, en inzicht in de relatie tussen beide is essentieel voor het behoud van een consistente e-mailbezorgbaarheid.

Hoe SPF in DMARC past

DMARC bouwt voort op SPF en DKIM om domeineigenaren controle te geven over hoe hun e-mail wordt behandeld wanneer authenticatie mislukt. Om een e-mail DMARC te laten doorstaan, moet ten minste één van de volgende voorwaarden vervuld zijn:

• SPF-controle is geslaagd en het domein van de afzender komt overeen met het 'From'-domein
• DKIM-controle is geslaagd en het DKIM-ondertekeningsdomein komt overeen met het ‘Van’-domein

Dit betekent dat zelfs een correct geconfigureerd SPF-record met alle juiste includes op zichzelf niet voldoende is. De SPF-alignment moet ook kloppen, wat inhoudt dat het domein in het retourpad moet overeenkomen met het ‘From’-domein volgens uw DMARC-alignment-instellingen.

Hoe de SPF-parameter de uitlijning beïnvloedt

Wanneer een externe afzender zijn eigen domein in het retouradres gebruikt, kan het zijn dat dit domein in uw SPF-record is opgenomen en dat de SPF-controle voor dat domein technisch gezien slaagt, maar het komt niet overeen met uw ‘Van’-domein.

In dit scenario zal DMARC nog steeds niet slagen voor de SPF-controle. Het is van essentieel belang om de externe dienst zo te configureren dat deze een aangepast retourpad onder uw domein gebruikt, of om ervoor te zorgen dat DKIM-afstemming als back-up is ingesteld.

Waarom SPF alleen niet voldoende is

SPF, DKIM en DMARC zijn ontworpen om samen te werken. SPF valideert de afzender, maar werkt niet meer bij doorsturen.

DKIM ondertekent het bericht zelf en blijft intact bij doorsturen. DMARC koppelt beide aan elkaar en biedt u inzicht in en controle over wat er gebeurt als een van beide faalt. Alleen door deze drie te configureren kunt u een robuuste, veerkrachtige e-mailverificatieopstelling opzetten.

DMARC instellen naast SPF

Als je je SPF-inclusies correct hebt geconfigureerd maar DMARC nog niet hebt geïmplementeerd, is het instellen van DMARC de logische volgende stap.

Begin met een beleid waarbij p=none is, zodat u uw e-mailstromen kunt monitoren zonder de afleverbaarheid te beïnvloeden. Ga vervolgens over op quarantaine en weigeren naarmate uw vertrouwen in uw authenticatie-instellingen toeneemt.

Zorg voor de juiste SPF-instellingen met PowerDMARC

Het beheer van SPF Include is eenvoudig als u met één of twee verzendplatforms werkt. Maar naarmate uw e-mailinfrastructuur groeit, neemt ook de complexiteit toe.

Meer platforms betekenen meer inclusies, meer DNS-lookups en meer kansen dat er op de achtergrond stilletjes iets misgaat, zonder dat je het merkt totdat de afleverbaarheid begint af te nemen.

PowerDMARC biedt u de tools en het inzicht om hierop te anticiperen. Het helpt u bij het genereren en valideren van uw SPF-record en bij het monitoren van de afstemming en authenticatieresultaten voor elke verzendbron.

Wat een klant te zeggen heeft:

“PowerDMARC heeft ons geholpen om 15 verschillende e-maildiensten samen te voegen tot één geoptimaliseerd SPF-record. De afleverbaarheid van onze e-mails is binnen de eerste maand met 23% verbeterd.” – IT-directeur, Fortune 500 SaaS-bedrijf

Als je klaar bent om de controle over je e-mailverificatie en ervoor te zorgen dat uw SPF-records precies doen wat ze moeten doen, start dan uw gratis proefperiode.

FAQs

1. Wat gebeurt er als ik de limiet van 10 DNS-lookups in mijn SPF-record overschrijd?

Als uw SPF-record meer dan 10 DNS-opzoekingen vereist, leidt dit tot een PermError, waardoor de SPF-verificatie volledig mislukt. Dit kan ertoe leiden dat legitieme e-mails worden geweigerd of als spam worden gemarkeerd. Gebruik SPF-flattening of macro’s om binnen de limiet te blijven.

2. Mag ik hetzelfde domein meerdere keren in mijn SPF-record opnemen?

Hoewel het technisch gezien mogelijk is, is het meerdere keren opnemen van hetzelfde domein overbodig en leidt het tot onnodige DNS-zoekopdrachten. Elke `include`-instructie moet uniek zijn en een specifiek doel dienen binnen uw e-mailverificatiestrategie.

3. Hoe vaak moet ik mijn SPF-inclusies controleren?

Controleer uw SPF-record elk kwartaal of telkens wanneer u e-maildiensten toevoegt of verwijdert. Stel automatische monitoring in om ongeoorloofde wijzigingen of updates van serviceproviders op te sporen die van invloed kunnen zijn op uw authenticatie.

4. Wat is het verschil tussen ~all en -all in SPF-records?

~all (softfail) houdt in dat e-mails van onbevoegde afzenders als verdacht moeten worden gemarkeerd, maar toch moeten worden afgeleverd. -all (hardfail) geeft ontvangende servers de opdracht om e-mails van onbevoegde afzenders volledig te weigeren. De meeste organisaties beginnen met ~all en schakelen na het testen over op -all.

5. Kan SPF de afleverbaarheid van e-mails beïnvloeden?

Ja, onjuist geconfigureerde SPF-includes kunnen de afleverbaarheid aanzienlijk beïnvloeden. Ontbrekende includes voor legitieme diensten kunnen ervoor zorgen dat e-mails de authenticatie niet doorstaan, terwijl te veel includes de limieten voor DNS-lookups kunnen overschrijden en tot PermErrors kunnen leiden.

• Over
• Laatste berichten

Yunes Tarada

Expert domein- en e-mailbeveiliging bij PowerDMARC

Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen zoals CompTIA A+ en vele andere.

Laatste berichten van Yunes Tarada (Bekijk alle berichten)

• Het formaat van het SOA-serienummer is ongeldig: oorzaken en oplossingen - 13 april 2026
• Veilige e-mails versturen in Gmail: stap-voor-stap handleiding - 7 april 2026
• Veilige e-mails versturen in Outlook: stapsgewijze handleiding - 2 april 2026