Welke SPF-lookups écht meetellen (en welke niet)

Gepubliceerd op 20 oktober 2026 · 7 min. leestijd · spFlat! Blog

De limiet van 10 lookups uit RFC 7208 is het meest onbegrepen onderdeel van SPF. Bijna iedereen telt de include:-statements, ziet dat het er minder dan 10 zijn en gaat ervan uit dat het goed zit.

Waarschijnlijk zit het niet goed. De limiet telt veel meer dan alleen include:-regels, en wie dat verkeerd inschat, ziet zijn SPF-record ongemerkt veranderen in een PermError. Dat is niet hetzelfde als een SPF-fail, maar veel ontvangers gaan er zo streng mee om dat je bezorgbaarheid een klap krijgt (sommige doen in de praktijk alsof je geen bruikbaar SPF-record hebt).

Hieronder lees je precies wat meetelt voor de limiet van 10 lookups, en wat gratis is.

De regel die iedereen citeert

"An SPF implementation MUST limit the total number of DNS lookups to 10."

Dat staat in RFC 7208, sectie 4.6.4. Maar het woord waar mensen over struikelen, is total. Het gaat niet om 10 include:-statements, maar om 10 DNS-lookups, en verschillende onderdelen veroorzaken er meer dan één.

Wat meetelt voor de limiet

Elke include:, plus wat er achter zit

Elke include: telt als één van de 10, voor het SPF-record van het opgenomen domein zelf. Maar gebruikt dat record zelf weer include:-, mx-, a-, ptr- of exists-termen, dan tellen die ook mee, en die zitten meestal meerdere niveaus diep verstopt.

Wat een aanbieder kost, verandert in de loop van de tijd. include:spf.protection.outlook.com is op dit moment een vlakke ip4:/ip6:-lijst (1 lookup). SendGrid en Mailgun gebruiken nog wel geneste includes. Controleer de actuele keten en vertrouw niet blind op een tabel uit een blog.

Het mx-mechanisme (één term, niet één per MX-host)

mx telt als precies één voor de limiet van 10 termen, ook als het domein meerdere MX-hosts publiceert. De ontvanger moet de A/AAAA-records van die hosts nog wel opvragen (extra DNS-werk), maar die adresqueries vallen onder een aparte limiet uit RFC 7208: maximaal 10 adresrecords per mx-evaluatie. Ze nemen niet elk een extra plek in binnen de hoofdlimiet van 10. Dat is een hardnekkige mythe waardoor mensen hun lookupbudget verkeerd tellen.

Het a-mechanisme

a telt als één term. Eén adreslookup kan meerdere A/AAAA-records opleveren, maar meerdere adressen in dat antwoord verhogen de teller niet. Voor ptr en exists geldt hetzelfde: elke geëvalueerde term telt als één, met elk zijn eigen aanvullende verwerkingsregels in de RFC.

redirect (dezelfde limiet als include)

Een redirect=-modifier valt onder dezelfde limiet van 10 termen; je krijgt er geen nieuwe limiet bij. Een redirect die zelf includes gebruikt, verbruikt je lookupbudget net zoals een include.

Wat NIET meetelt

ip4:- en ip6:-mechanismen: altijd gratis

Directe IP-mechanismen zijn nooit DNS-lookups. Daar draait SPF-flattening om: vervang include:-ketens die veel lookups kosten door vlakke ip4:/ip6:-lijsten, en je record komt uit op 1 lookup in totaal.

Een include: van een domein zonder SPF-record

Publiceert het opgenomen domein geen SPF-record, dan kost de include: nog steeds één van je 10: de lookup die het lege resultaat opleverde. Een vrijbrief is het dus niet. Lege of NXDOMAIN-antwoorden tellen bovendien mee voor de aparte limiet voor void lookups (implementaties SHOULD stoppen na twee), dus kapotte includes kunnen je SPF-controle al laten mislukken voordat je 10 termen bereikt.

exp: de explanation-modifier

exp= verwijst naar een macrostring in een TXT-record dat pas na een fail-resultaat wordt opgevraagd. Het telt niet mee voor de limiet van 10 termen tijdens de evaluatie. Hetzelfde geldt voor all.

De verborgen valkuil: geneste includes

Het venijn zit erin dat aanbieders includes nesten. Een "eenvoudig" record zoals dit:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org ~all

lijkt 3 lookups te kosten, maar verbruikt er op dit moment ongeveer 8 zodra de ketens zijn uitgeklapt: Outlook is vlak (1), SendGrid verwijst door naar ab.sendgrid.net (2) en Mailgun waaiert uit over Amerikaanse en Europese SPF-bomen (5). Voeg een mx of nog een include van een andere aanbieder toe, en je zit tegen de limiet aan zonder dat je het ziet.

Zo controleer je het in de praktijk

Op het oog kun je dit niet betrouwbaar tellen. Het juiste getal is het aantal geëvalueerde DNS-lookups, dus je hebt een tool nodig die de volledige keten doorloopt.

Gebruik de gratis lookuptool op spflat.cloud: voer je domein in en je ziet het echte aantal lookups, of je op of over de limiet van 10 lookups zit en of er nu een PermError optreedt. Geen account nodig.

Wanneer "onder de 10" niet genoeg is

Ook bij 8 of 9 lookups zit je maar één wijziging bij een aanbieder af van een PermError. E-mailaanbieders voegen geregeld CIDR-ranges toe of halen ze weg. Zodra een geneste include er één niveau bij krijgt, slaat je record om naar permerror en behandelen ontvangers het alsof het er niet is.

Daarom is goed tellen belangrijk. En daarom is geautomatiseerde flattening (die de hele keten omzet naar directe IP's en bijwerkt zodra aanbieders hun ranges wijzigen) de enige manier om op lange termijn ruim onder de limiet te blijven, zonder er steeds bovenop te hoeven zitten.

Belangrijkste punten

• Tel de geëvalueerde lookups, niet je include:-regels.
• mx en a kosten ook lookups; ip4:/ip6: kosten niets.
• Geneste includes verbergen het echte aantal.
• Controleer het werkelijke aantal met een tool, niet met hoofdrekenen.