Wat houdt SPF Include in? Hoe gebruik je het veilig in je SPF-record?

Kort antwoord: Met het SPF-include-mechanisme kan een domeineigenaar een externe afzender autoriseren door in zijn eigen DNS TXT-record te verwijzen naar het SPF-record van die afzender. Wanneer een ontvangende server uw SPF-record evalueert en een `include`-instructie tegenkomt, haalt deze het SPF-record van het domein waarnaar wordt verwezen op en evalueert dit als onderdeel van de controle. Omdat elke `include` ten minste één extra DNS-opzoeking activeert, moet u het totale aantal DNS-opzoekingen op maximaal 10 houden om een PermError te voorkomen.

Uw SPF-record geeft aan ontvangende mailservers door welke bronnen e-mail mogen versturen namens uw domein. Zodra uw organisatie platforms van derden gaat gebruiken voor marketing, transactionele berichten, CRM-updates of ondersteuningsmails, wordt het handmatig beheren van SPF steeds lastiger. Daar biedt het SPF-include-mechanisme uitkomst.

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

Voor wie is het belangrijk om te begrijpen wat SPF Include inhoudt?

SPF is vooral van belang voor IT-teams, systeembeheerders, cyberbeveiligingsadviseurs en MSP’s die domeinen beheren waarvoor e-mail via meerdere diensten van derden wordt verzonden. Als uw organisatie gebruikmaakt van platforms zoals een CRM-systeem, helpdesk, marketingautomatiseringstool, aanbieder van transactionele e-mail of cloudmaildienst, is uw SPF-record waarschijnlijk afhankelijk van een of meer ‘include’-mechanismen.

• IT- en beveiligingsteams binnen ondernemingen die meerdere SaaS-platforms, regionale verzenders of domeinportfolio’s beheren
• Systeembeheerders die verantwoordelijk zijn voor DNS-records en de afleverbaarheid van e-mail
• MSP’s en MSSP’s die SPF en DMARC beheren voor meerdere klantdomeinen
• Cyberbeveiligingsadviseurs in gereguleerde sectoren zoals de financiële sector, de gezondheidszorg, de detailhandel en de publieke sector

Wat is een SPF-record?

Een SPF-record, of Sender Policy Framework-record record, is een DNS TXT-record waarin alle servers en IP-adressen worden vermeld die bevoegd zijn om e-mail namens een bepaald domein te verzenden. Wanneer er een e-mail binnenkomt, controleert de ontvangende e-mailserver de DNS-records van de afzender om te verifiëren 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. Als dat niet het geval is, 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, waardoor 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. Door alle drie de protocollen samen te configureren, wordt de sterkste bescherming voor e-mail geboden.

Wat houdt SPF Include in?

Als SPF-records de regels zijn die bepalen wie e-mail vanaf je domein mag versturen, dan is het SPF-include-mechanisme de manier waarop je de regels van iemand anders kunt overnemen. Hiermee kan een domeineigenaar de bevoegdheid om e-mail te versturen delegeren aan een ander domein door in zijn eigen SPF-record te verwijzen naar het SPF-record van dat domein. In plaats van elk IP-adres dat door een externe e-maildienst wordt gebruikt handmatig op te sommen, neem je hun domein op, waarna de ontvangende server hun SPF-record ophaalt en evalueert als onderdeel van je eigen SPF-record.

Waarom er een SPF-include bestaat

Het versturen van e-mail gebeurt tegenwoordig zelden via één enkele server. Voor IT- en beveiligingsteams van bedrijven neemt de complexiteit van SPF doorgaans toe naarmate er in de loop van de tijd nieuwe SaaS-tools, regionale marketingplatforms, CRM-systemen, helpdesks en diensten voor transactionele e-mail worden toegevoegd. Elke nieuwe afzender moet correct worden geautoriseerd, continu worden gecontroleerd en binnen de limiet van 10 DNS-lookups van SPF blijven om authenticatiefouten en problemen met de afleverbaarheid te voorkomen.

Het SPF-include-mechanisme 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 evalueert en een ‘include’-instructie tegenkomt, haalt deze het SPF TXT-record van dat externe domein op en lost het op als onderdeel van het validatieproces. Als het SPF-beleid van het opgenomen domein een ‘pass’ retourneert voor het verzendende IP-adres, komt het ‘include’-mechanisme overeen en kan de SPF-evaluatie voor die afzender slagen. Zo niet, dan gaat de ontvangende server verder met het evalueren van de rest van uw SPF-record.

Hoe de SPF-inclusie er in de praktijk uitziet

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

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 verzenden van e-mail uitbesteden of gebruikmaken van meerdere leveranciers, aangezien het alternatief zou zijn om elk IP-adres dat door elke dienst wordt gebruikt handmatig op te sommen, 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

1. Wanneer een e-mail bij een ontvangende mailserver binnenkomt, haalt de server het domein uit het MAIL FROM-adres en voert een DNS-opzoeking 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 wordt bereikt. Wanneer de server een include-instructie tegenkomt:
2. De ontvangende server voert een extra DNS-opzoeking uit om het SPF TXT-record van het betreffende domein op te halen.
3. Het vergelijkt het SPF-record van het betreffende domein met het IP-adres van de afzender.
4. Als het SPF-beleid van het opgenomen domein een ‘pass’-resultaat oplevert voor het verzendende IP-adres, komt het ‘include’-mechanisme overeen en kan de SPF-beoordeling voor die afzender slagen.
5. 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`-instructie in een SPF-record leidt tot ten minste één extra DNS-query. Dit is van belang omdat de SPF-validatie beperkt is tot maximaal tien DNS-lookups 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 `include`-instructies bevat, tellen die ook mee, waardoor een keten van lookups ontstaat die snel kan oplopen.

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

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

De syntaxis moet absoluut correct zijn. Zelfs één fout in je syntaxis van je SPF-record kan ervoor zorgen dat het hele record niet werkt, ongeacht hoe goed de rest is geconfigureerd.

De basisstructuur van een SPF-record

• v=spf1 geeft de SPF-versie aan en moet aan het begin van elk SPF TXT-record staan
• mechanismen bepalen de toegestane 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

SPF-kwalificatiewedstrijden in één oogopslag

Hoe schrijf je een SPF-include-instructie op de juiste manier?

De juiste syntaxis voor een `include`-instructie is `include:domain.com`. Let erop dat er geen spatie staat tussen `include` en de dubbele punt. Een spatie leidt tot een syntaxisfout. Hier volgt een volledig voorbeeld van een SPF-record met meerdere `include`-instructies:

• 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 worden geweigerd

Checklist: hoe voeg je veilig een nieuwe SPF-include toe

1. Identificeer de nieuwe verzendservice en controleer het door de leverancier opgegeven ‘include’-domein.
2. Haal je huidige SPF TXT-record op met behulp van een SPF-zoektool.
3. Tel het totale aantal DNS-lookups, inclusief geneste lookups binnen de opgenomen records.
4. Voeg het nieuwe ‘include:’-mechanisme toe aan je enige SPF TXT-record.
5. Controleer de syntaxis met een SPF-recordgenerator of een opzoektool.
6. Publiceer het bijgewerkte record en test de authenticatieresultaten aan de hand van de e-mailheaders.
7. Controleer de DMARC-rapporten om te verifiëren of de nieuwe afzender voldoet aan de SPF-afstemming.

SPF Include versus Redirect: wat is het verschil?

Zowel het `include`-mechanisme als de `redirect`-modificator verwijzen naar het SPF-record van een ander domein, maar ze gedragen zich heel verschillend. Het gebruik van het ene terwijl je het andere nodig hebt, is een veelvoorkomende configuratiefout die de authenticatie onopgemerkt kan verstoren.

Het ‘include’-mechanisme geeft afzenders die in het SPF-record van een ander domein staan vermeld toestemming, terwijl je SPF-record toch aanvullende mechanismen kan bevatten. De ‘redirect’-modificator daarentegen geeft de ontvangende server de opdracht om het SPF-record van een ander domein te gebruiken als het volledige beleid voor jouw domein, waarbij al het andere in jouw record wordt vervangen.

Veelgemaakte fout

Het gebruik van zowel `include` als `redirect` in hetzelfde record. De `redirect`-modificator wordt genegeerd wanneer er een `all`-mechanisme in het record voorkomt, waardoor de twee niet samenwerken zoals men zou verwachten. Voor de meeste opstellingen met meerdere afzenders is `include` de juiste keuze en wordt `redirect` volledig weggelaten.

Veelvoorkomende syntaxfouten die je moet vermijden

• Het publiceren van meer dan één SPF TXT-record voor hetzelfde domein leidt tot een PermError, omdat ontvangende servers niet kunnen bepalen welk beleid ze moeten toepassen
• 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

Een SPF-recordgenerator stelt vanaf nul een correct opgemaakt record samen, of je kunt je bestaande record door een SPF-opzoektool halen om te controleren op fouten voordat deze problemen met de bezorgbaarheid veroorzaken.

Vergelijking van SPF-mechanismen: include versus a, mx, ip4, ip6 en all

Voordat u een DNS-TXT-record aanpast, is het handig om te weten welk SPF-mechanisme u wanneer moet gebruiken. Elk mechanisme dient een ander doel en heeft een andere invloed op het aantal DNS-opzoekingen.

SPF-regels voor meerdere opnames en limieten voor DNS-opzoekingen

Het gebruik van meerdere SPF-includes is gebruikelijk en vaak noodzakelijk, maar het brengt complexiteit met zich mee die zorgvuldig moet worden beheerd. Hier volgt 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-mail via meer dan één platform. Een typische opzet bestaat uit een primaire e-mailserver voor interne en uitgaande e-mail, een dienst voor transactionele e-mail voor orderbevestigingen en meldingen, een marketingplatform voor nieuwsbrieven en campagnes, en een CRM- of helpdesktool voor communicatie met klanten. Elk van deze platforms moet in je SPF-record worden geautoriseerd, en de meest praktische manier om dat te doen is via `include`-instructies die verwijzen naar het SPF-record van elke provider.

Waarom MSP’s de SPF-instellingen zorgvuldig moeten controleren

Voor MSP’s en MSSP’s kunnen SPF-gerelateerde problemen zich snel uitbreiden binnen de omgevingen van klanten. De ene klant voegt misschien een nieuwe e-mailmarketingtool toe, een andere wisselt van CRM-systeem en weer een derde publiceert onbewust meerdere SPF-records. Zonder gecentraliseerd inzicht leiden deze wijzigingen vaak pas tot supporttickets wanneer de e-mailbezorging begint te mislukken. Een gecentraliseerd platform voor SPF- en DMARC-beheer helpt MSP's om vanuit één dashboard defecte records, ongebruikte includes, risico's op opzoeklimieten en authenticatiefouten in alle klantdomeinen te identificeren, waardoor reactief probleemoplossen wordt verminderd.

Waarom meerdere SPF-inclusies de limiet van 10 opzoekingen kunnen overschrijden

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 deze zelfs al overschreden. Wanneer de limiet wordt overschreden, retourneert de ontvangende server een PermError en behandelt de e-mail als een mislukte SPF-authenticatie.

Voorbeeld: hoe het aantal zichtbare includes meer dan 10 opzoekingen in totaal bedraagt

Drie zichtbare includes kunnen al snel uitgroeien tot meer dan tien opzoekacties in totaal, als je de geneste includes binnen de records waarnaar wordt verwezen meerekent.

Hoeveel SPF-vermeldingen kan één SPF-record bevatten?

Er geldt geen strikte limiet voor het aantal `include`-instructies dat je in een SPF-record kunt opnemen. Het totaal aantal DNS-opzoekingen dat wordt veroorzaakt door alle DNS-opvraagmechanismen samen – waaronder `include`, `a`, `mx`, `exists` en `redirect` – mag tijdens de evaluatie echter niet meer dan 10 bedragen. Deze limiet geldt ook voor geneste opzoekingen binnen opgenomen records.

In de praktijk kunnen de meeste domeinen veilig tussen de drie en vijf `include`-instructies gebruiken voordat de limiet wordt bereikt, afhankelijk van het aantal geneste opzoekacties dat elk gerefereerd record activeert. Het toevoegen van een zesde of zevende `include` voor een provider wiens eigen SPF-record meerdere geneste `include`-instructies bevat, kan het totaal boven de 10 brengen en een PermError veroorzaken, ook al lijkt het zichtbare record kort. Een SPF-afvlakkingstool telt het totale aantal lookups en lost de ‘include’-ketens op voordat u een wijziging in het record publiceert.

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 SPF-afvlakking om include-ketens automatisch op te lossen en te vervangen door directe IP-adressen, waardoor het totale aantal lookups wordt verminderd
• Controleer je gegevens telkens wanneer je een verzendplatform toevoegt of verwijdert

Altijd één SPF-record per domein

Een cruciale 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 SPF PermError, omdat ontvangende servers niet kunnen bepalen welk beleid ze moeten toepassen; daarom moet alles worden samengevoegd tot één enkel record. Als u vanaf subdomeinen verstuurt, heeft elk subdomein zijn eigen afzonderlijke SPF TXT-record nodig.

Voorbeelden van SPF-opnames voor veelgebruikte instellingen voor het verzenden van e-mail

De volgende voorbeelden illustreren de juiste syntaxis voor SPF-include-records bij veelvoorkomende configuraties voor meerdere platforms. Controleer vóór publicatie altijd het exacte include-domein in de documentatie van je provider en valideer elk nieuw record met een SPF-record-opzoekprogramma voordat u het naar DNS publiceert.

Alleen één e-mailprovider

E-mailprovider plus dienst voor transactionele e-mails

E-mailprovider, marketingplatform en CRM (let op het aantal zoekopdrachten)

Onjuiste voorbeelden

Twee records die zullen mislukken, met de volgende reden:

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 opleveren. Of u nu voor het eerst SPF instelt of een bestaand record controleert, dit zijn de fouten waar u op moet letten.

Resultaten van de SPF-beoordeling: Geslaagd, Niet geslaagd, Softfail, Neutraal, TempError en PermError

Als je begrijpt wat elke SPF-uitslag betekent, kun je authenticatiefouten snel opsporen. In de onderstaande tabel staan alle uitslagen die een ontvangende server kan retourneren na het beoordelen van een SPF-record.

SPF Include en naleving van DMARC

SPF-instellingen werken niet op zichzelf. De manier waarop u ze configureert, heeft een directe invloed op uw DMARC-naleving, en inzicht in de relatie tussen beide is essentieel voor het handhaven van een consistente afleverbaarheid.

Voor gereguleerde sectoren zoals de financiële sector, de gezondheidszorg, het onderwijs, de detailhandel en de publieke sector is het opnemen van SPF-hygiëne niet alleen een kwestie van afleverbaarheid. Het ondersteunt bredere vereisten voor e-mailauthenticatie die verband houden met de afzenderregels van Google en Yahoo, de authenticatieverwachtingen van Microsoft en PCI DSS, op de AVG afgestemde beveiligingsmaatregelen en interne risicobeheerprogramma's.

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 ‘Van’-domein volgens uw DMARC-alignment-instellingen.

Hoe de SPF-parameter de uitlijning beïnvloedt

Wanneer een externe afzender zijn eigen domein in het retourpad gebruikt, kan het zijn dat hun ‘include’ in uw SPF-record voorkomt en dat de SPF-controle voor hun domein technisch gezien slaagt, maar dit komt niet overeen met uw ‘From’-domein. In dit scenario mislukt de SPF-controle in DMARC nog steeds. Configureer de externe dienst zodat deze een aangepast retourpad onder uw domein gebruikt, of zorg ervoor dat DKIM-afstemming als back-up is ingesteld, is essentieel.

Waarom SPF alleen niet voldoende is

SPF, DKIM en DMARC zijn ontworpen om samen te werken als de kern van beveiligingsmaatregelen . SPF valideert de afzender, maar faalt bij het doorsturen. DKIM ondertekent het bericht zelf en blijft ook bij het doorsturen intact. DMARC koppelt beide aan elkaar en biedt u inzicht en controle over wat er gebeurt als een van beide faalt. Het configureren van alle drie is de enige manier om een robuuste e-mailauthenticatieopstelling op te zetten.

DMARC instellen naast SPF

Als je je SPF-includes correct hebt geconfigureerd maar DMARC nog niet hebt geïmplementeerd, dan is het instellen van DMARC de logische volgende stap. Begin met een beleid van p=none om uw e-mailstromen te monitoren zonder de afleverbaarheid te beïnvloeden, en ga vervolgens over naar ‘quarantaine’ en ‘afwijzen’ naarmate uw vertrouwen in uw authenticatie-instellingen toeneemt.

Beheer SPF-includes en DMARC-afstemming met PowerDMARC

Het beheer van SPF-includes wordt lastig wanneer uw organisatie gebruikmaakt van meerdere externe afzenders verspreid over verschillende afdelingen, domeinen en regio’s. Eén enkele ongebruikte include, een geneste opzoekketen of een verkeerd ingesteld return-path-domein kan leiden tot authenticatiefouten die moeilijk handmatig te detecteren zijn.

PowerDMARC biedt IT-teams, beveiligingsverantwoordelijken en MSP’s gecentraliseerd inzicht in de SPF-, DKIM- en DMARC-resultaten voor alle verzendbronnen. Met geautomatiseerd SPF-beheer, DMARC-rapportage, SPF-analyses, gehoste authenticatiediensten en deskundige ondersteuning kunnen teams storingen als gevolg van SPF-opzoeklimieten voorkomen, ongeautoriseerde afzenders identificeren en naleving garanderen met minder DNS-overhead.

Organisaties gebruiken PowerDMARC om het SPF-beheer te centraliseren, authenticatiefouten te monitoren en ongeautoriseerde afzenders te identificeren voordat deze de afleverbaarheid beïnvloeden.

Een demo boeken

Veelgestelde Vragen

Hoeveel SPF-items mag ik hebben?

Er geldt geen vaste limiet voor `include`-instructies, maar het totale aantal DNS-opzoekingen mag niet meer dan 10 bedragen, waarbij ook geneste opzoekingen binnen de waarnaar wordt verwezen records worden meegeteld. De meeste domeinen kunnen drie tot vijf `include`-instructies veilig verwerken voordat er moet worden afgevlakt.

Wat is het verschil tussen 'include' en 'redirect'?

`include` voegt de afzenders van een ander domein toe, terwijl je eigen mechanismen actief blijven. `redirect` vervangt je volledige beleid door de gegevens van een ander domein. `redirect` wordt genegeerd als er een `all`-mechanisme aanwezig is, zodat de twee niet door elkaar worden gebruikt.

Waarom wordt mijn SPF goedgekeurd, maar faalt DMARC nog steeds?

SPF kan worden geïnterpreteerd als het eigen domein van een externe afzender, terwijl het niet overeenkomt met uw ‘Van’-domein. DMARC vereist wel overeenstemming; configureer daarom een aangepast retourpad onder uw domein of maak gebruik van DKIM-overeenstemming als alternatief.

Wat is de oorzaak van een SPF PermError?

Drie veelvoorkomende oorzaken: het overschrijden van de limiet van 10 lookups, het publiceren van meer dan één SPF-record voor een domein, of een syntaxfout zoals een spatie na `include:`. Alle drie zorgen ervoor dat de SPF-controle voor elke afzender mislukt, totdat het probleem is verholpen.

Kan ik één SPF-record gebruiken voor meerdere subdomeinen?

Nee. Elk verzendend subdomein heeft zijn eigen SPF TXT-record nodig. Het record van het bovenliggende domein geldt niet voor subdomeinen, dus e-mail afkomstig van een niet-geconfigureerd subdomein voldoet niet aan de SPF-controle.

Hoe kan ik het aantal SPF-opzoekingen verminderen?

Verwijder `include`-verwijzingen naar ongebruikte diensten, vervang afzenders met een statisch IP-adres door directe IPv4- of IPv6-vermeldingen, en gebruik SPF-flattening om `include`-ketens om te zetten in directe IP-adressen. Voer een controle uit telkens wanneer een verzendplatform wordt toegevoegd of verwijderd.

Heeft het toevoegen van een include direct invloed op de e-mail?

Pas nadat de DNS-updates zijn doorgevoerd, wat tot 48 uur kan duren. Controleer het record met een opzoektool voordat je het publiceert, en controleer vervolgens in je DMARC-rapporten of de nieuwe afzender voldoet aan de SPF-vereisten.

• Over
• Laatste berichten

Yunes Tarada

Expert op het gebied van 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)

• Handleiding voor het instellen van TinkMail DKIM, DMARC en SPF - 19 augustus 2026
• Handleiding voor het instellen van DKIM, DMARC en SPF in PandaDoc - 19 augustus 2026
• Handleiding voor het instellen van Moloni DKIM, DMARC en SPF - 18 augustus 2026