# Wat is een spf record? Syntaxis, limieten en storingen URL: https://notificationharbor.com/nl/journal/wat-is-een-spf-record-syntaxis-limieten-storingen Type: blog Locale: nl Published: 2026-10-20 Updated: 2026-10-23 --- > Een spf record somt de servers op die mail mogen versturen voor je domein. Hier staan de syntaxis, de limiet van 10 lookups, storingen bij doorsturen en hoe je de jouwe controleert. Een spf record is een enkele DNS TXT-record op je domein die vastlegt welke servers mail mogen versturen met dat domein als envelopafzender. Een ontvangende server leest die record, vergelijkt het IP-adres van de verbinding met de lijst en geeft een resultaat terug: pass, fail, softfail of neutral. Een spf record controleert het verzendpad, niet het bericht zelf, en zegt niets over het From-adres dat de ontvanger te zien krijgt. Dat onderscheid verklaart het grootste deel van de SPF-tickets die we in traces tegenkomen. ## Een spf record is een toegangslijst van verzenders, in DNS SPF staat voor Sender Policy Framework en is beschreven in [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). De record is een TXT-entry op het root van het domein die begint met `v=spf1`. Een minimale variant ziet er zo uit: `example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"`Lees hem van links naar rechts. De ontvanger controleert elke term in volgorde en stopt bij de eerste match. De laatste term `all` vangt alles op wat eerder niet paste. Het gecontroleerde domein is niet het From-veld. Het is het domein in het SMTP-commando `MAIL FROM`, ook envelopafzender of Return-Path genoemd. Is die leeg, zoals bij bounces, dan valt de ontvanger terug op de HELO-naam. ![Ontwikkelaarswerkplek met laptop, terminal en een notitieboek met een handgetekend netwerkdiagram](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/0bf38c-inline1.webp) Elke term is een mechanisme, optioneel voorafgegaan door een kwalificatie. Zes mechanismen dekken bijna elke echte record: - **`ip4:` / `ip6:`** matchen een vast adres of CIDR-bereik. Ze kosten geen lookups. - **`a`** matcht de A- of AAAA-records van een domein. Dat kost één lookup. - **`mx`** matcht de hosts in de MX-records van het domein. Dat kost één lookup plus één per host. - **`include:`** matcht wat de SPF-record van een ander domein matcht. Dat kost één lookup plus alles wat daarin genest zit. - **`exists:`** matcht een A-record voor een samengestelde naam. Dat kost één lookup. - **`ptr`** matcht op de reverse DNS van het verbonden IP. Dat kost lookups, en RFC 7208 raadt het af. Kwalificaties bepalen het resultaat bij een match. `+` is pass en is de standaard, `-` is fail, `~` is softfail en `?` is neutral. `-all` betekent dus "wijs alles af wat niet vermeld staat", en `~all` betekent "accepteer, maar markeer". Gebruik `ip4:` en `ip6:` waar je het adres zelf beheert. Ze kosten nul lookups en kunnen niet breken wanneer de DNS van een ander verandert. ## De limiet van 10 DNS-lookups breekt echte records RFC 7208 begrenst één SPF-evaluatie tot 10 termen die een DNS-query veroorzaken: `include`, `a`, `mx`, `ptr`, `exists` en de modifier `redirect`. Geneste includes tellen mee. Boven de 10 is het resultaat `permerror`, en de controle faalt definitief in plaats van terug te vallen. Er is een tweede limiet die minder aandacht krijgt. Termen die een leeg antwoord of NXDOMAIN geven, heten void lookups, en de specificatie stopt bij twee. Een verouderde `include:` naar een leverancier die je vorig jaar hebt uitgeschakeld, is een void lookup waarvoor je nog steeds betaalt. Zo raken teams het plafond in de praktijk. Google Workspace telt voor één include. Een transactionele provider telt voor één. Een marketingplatform telt voor één en nest er drie in. Een helpdesk, een CRM en een factuurtool voegen er nog vier toe. Dan zit je op 11, zonder iets bijzonders te hebben gedaan. De fout is stil. Mail wordt nog steeds verzonden, en sommige ontvangers leveren het nog af, maar SPF authenticeert dan niets meer voor je. Als je op DMARC-alignment via SPF vertrouwt, is die route weg zolang je de record niet afvlakt of verzenders verwijdert. Er zijn drie oplossingen, in volgorde van voorkeur: - Verwijder verzenders die je niet meer gebruikt. Controleer de includes tegen je DMARC-aggregaterapporten van de laatste 90 dagen. - Verplaats bulkverkeer naar een subdomein zoals `mail.example.com`, met een eigen SPF-record en een eigen budget van 10 lookups. - Vlak includes af naar vaste `ip4:`-bereiken, maar alleen met automatisering. Leveranciers roteren hun IP's, en een met de hand afgevlakte record veroudert zonder dat je een alarm krijgt. ![Whiteboardschets met pijlen van verschillende verzendende diensten naar één centrale doos](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/96537f-inline2.webp) ## Publiceer precies een spf record per domein Een domein mag niet twee SPF-records publiceren. Vindt een ontvanger twee `v=spf1`-TXT-entries, dan is het resultaat `permerror`, net als bij de lookup-limiet. Dit gebeurt wanneer iemand een record toevoegt voor een nieuw hulpmiddel terwijl er al een staat. De oplossing is mechanisch. Voeg de termen samen in één record, met één `v=spf1` aan het begin en één `all` aan het eind. Alles wat de documentatie van een leverancier je vraagt toe te voegen, komt als extra `include:` in de bestaande record, nooit als nieuwe TXT-entry. Twee kleinere valkuilen. Een TXT-string van meer dan 255 tekens moet je splitsen in meerdere quoted strings binnen dezelfde record, wat de meeste DNS-providers voor je doen. En houd het hele antwoord waar mogelijk onder ongeveer 450 bytes, want grotere antwoorden kunnen van UDP naar TCP terugvallen, en sommige resolvers verwerken dat slecht. ## Softfail of hardfail: kies op basis van wat je ziet Het `all`-mechanisme is een beleidsverklaring, en het standaardadvies ("gebruik `-all`") slaat het deel over dat ertoe doet. Een hard fail is alleen veilig als je elke legitieme verzender kent. Onze vuistregel na het lezen van traces: - `~all` zolang je verzenders nog aan het inventariseren bent, of als je mail doorstuurt en het pad niet kunt beheersen. - `-all` zodra DMARC-rapporten een paar weken laten zien dat elke legitieme bron slaagt. - Nooit `+all`, want dat autoriseert het hele internet, en nooit `?all` op een productiedomein. In de praktijk is het verschil kleiner dan veel mensen verwachten. De meeste grote ontvangers zien SPF als één signaal naast andere, en met een DMARC-beleid bepaalt het DMARC-oordeel de uitkomst. Toch is een `-all` op een onvolledige record de manier waarop je facturen kwijtraakt. ![Gelabelde ethernetkabels in een serverkast](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/3e48d3-inline3.webp) ## SPF breekt bij doorsturen, en dat is bewust zo SPF controleert het IP-adres dat verbinding maakte met de ontvangende server. Wordt een bericht doorgestuurd, via een mailinglijst verspreid of door een aliasdienst gerelayd, dan is het verbonden IP dat van de doorstuurder, niet het jouwe. De SPF-controle faalt, ook al heb je niets verkeerd gedaan. Dat los je binnen SPF niet op. Daarom bestaat DKIM naast SPF: een handtekening reist mee met de hop, een IP-lijst niet. Een domein dat alleen op SPF leunt, ziet authenticatiefouten bij elk doorgestuurd bericht. Daarom voldoet SPF alleen ook niet aan DMARC voor doorgestuurde mail. Reken erop dat DKIM die berichten draagt. Alignment is de volgende valkuil. Een bericht kan SPF passeren en toch DMARC laten falen. DMARC vereist dat het domein dat SPF passeerde, het Return-Path-domein, overeenkomt met het zichtbare From-domein. Veel gedeelde providers gebruiken standaard hun eigen bounce-domein, dus SPF slaagt voor `provider-mail.net` en zegt niets over `example.com`. Controleer dit in de ruwe headers. Kijk in de regel `Authentication-Results` naar `smtp.mailfrom=`. Staat daar niet jouw domein of een subdomein ervan, dan slaagt SPF zonder dat het je helpt. De oplossing is een eigen Return-Path op een subdomein van jezelf, wat de meeste serieuze verzenders ondersteunen. Postmark, Resend, Mailgun en SendGrid documenteren allemaal deze opzet, al staat ze niet altijd standaard aan. ## Inbox-providers verwachten authenticatie van elke verzender Sinds februari 2024 vereist Google dat alle verzenders authenticeren met SPF of DKIM, en verzenders van meer dan 5.000 berichten per dag naar Gmail moeten SPF, DKIM en DMARC hebben ingesteld. De details staan in de [richtlijnen van Google voor e-mailafzenders](https://support.google.com/mail/answer/81126). Yahoo hanteert sinds dezelfde periode vergelijkbare regels. Daarmee is SPF van "fijn om te hebben" een voorwaarde voor aflevering geworden. Een ontbrekende of kapotte record toont zich nu als afwijzingen en spamplaatsing, niet alleen als een lagere reputatiescore. Onze lezing na een paar jaar traces: de regels vangen vooral domeinen zonder enige authenticatie en verzenders met hoge klachtpercentages. Een correcte spf record alleen brengt je niet in de inbox, maar een ontbrekende houdt je erbuiten. ## Zo controleer en repareer je een spf record in vier stappen Doe dit in volgorde en controleer na elke DNS-wijziging opnieuw. - **Haal de huidige record op.** Draai `dig +short TXT example.com` en zoek de regel die begint met `v=spf1`. Staan er twee, voeg ze samen. - **Tel de lookups.** Tel `include`, `a`, `mx`, `exists`, `redirect` en alles wat in de includes genest zit. Zit je op 8 of hoger, plan dan nu de opschoning, niet pas bij de elfde. - **Maak een lijst van echte verzenders.** Gebruik DMARC-aggregaterapporten of Authentication-Results-headers van testverzendingen. Voeg alleen de bronnen toe die daar verschijnen. - **Stuur een test en lees de header.** Het resultaat moet `spf=pass` zijn, met `smtp.mailfrom` op je eigen domein. DNS-wijzigingen hebben tijd nodig om door te werken, en de TTL van je huidige record bepaalt hoe lang oude antwoorden blijven hangen. Verlaag de TTL een dag vóór een geplande wijziging naar 300 seconden. ### Een werkend voorbeeld voor een saas-bedrijf met drie verzenders Neem een product dat verstuurt via Google Workspace, een transactionele provider en een helpdesk. Een schone record ziet er zo uit: `example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"`Dat zijn drie includes, en elke include verbergt zijn eigen geneste lookups. Tel ze voordat je publiceert, want de zichtbare lengte zegt niets over het echte budget. Een record met drie includes kan al op 7 of 8 lookups zitten. Splits daarom op doel. Houd menselijke mail op het root-domein. Zet productnotificaties op `notify.example.com`, met een record die alleen de transactionele provider noemt. De root-record blijft kort, het subdomein krijgt een eigen budget van 10 lookups, en een reputatieprobleem op de ene stroom sleept de andere niet mee. Die splitsing maakt de DMARC-rapporten ook leesbaar. Elke stroom heeft een eigen Return-Path-domein, dus een fout wijst naar één verzender in plaats van naar een stapel. ## Wat SPF niet doet SPF voorkomt niet dat iemand je From-adres vervalst, want het kijkt nooit naar die header. Het versleutelt niets. Het vertelt je ook niet waarom een bericht in de spam belandde. En het schaalt niet voorbij het budget van 10 lookups zonder doorlopend onderhoud. Behandel het als een van de drie records die je samen publiceert: SPF voor het verzendpad, DKIM voor de integriteit van het bericht, DMARC voor het beleid dat ze koppelt aan je From-domein. Heb je alleen SPF en niets anders, dan is de volgende concrete stap een DMARC-record op `p=none` en twee weken lang de rapporten lezen. ## FAQ ### Wat is een spf record in eenvoudige woorden? Het is een DNS TXT-record met de servers die mail mogen versturen voor je domein. Ontvangende servers vergelijken het IP-adres van de verzender met die lijst en bepalen of het bericht voor SPF slaagt. ### Hoeveel spf records mag een domein hebben? Eén. Twee records die allebei met v=spf1 beginnen, veroorzaken een permerror. Voeg alle toegestane verzenders samen in één record met één all-term aan het eind. ### Wat is de limiet van 10 DNS-lookups bij SPF? RFC 7208 begrenst de evaluatie tot 10 termen die DNS-queries doen: include, a, mx, ptr, exists en redirect. Geneste includes tellen mee. Bij overschrijding geeft SPF een permerror en authenticeert het je mail niet meer. ### Moet ik -all of ~all gebruiken in mijn spf record? Gebruik ~all zolang je verzenders inventariseert, en schakel over naar -all zodra DMARC-rapporten weken lang laten zien dat elke legitieme bron slaagt. Gebruik nooit +all, want dat autoriseert iedere server. ### Waarom faalt SPF bij doorgestuurde mail? SPF controleert het IP-adres dat met de ontvanger verbindt. Een doorstuurder verbindt vanaf zijn eigen IP, dat niet in jouw record staat. DKIM blijft werken omdat de handtekening met het bericht meereist. ### Beschermt SPF alleen tegen vervalsing? Nee. SPF valideert de envelopafzender, niet het zichtbare From-adres. Om het From-domein te beschermen heb je DMARC nodig, dat vereist dat SPF of DKIM slaagt en overeenkomt met het From-domein.