SPF-opzoeklimiet: de grens van 10 DNS-lookups

De SPF-opzoeklimiet werkt als volgt: als uw SPF-beleid meer dan 10 DNS-lookups nodig heeft om te worden beoordeeld, kunnen ontvangende servers de verwerking stoppen en een permanente fout teruggeven. Mail die in uw DNS-paneel in orde leek, kan daardoor toch niet door de authenticatie komen. Bent u uw domeinmail al aan het opruimen? Begin dan bij zakelijke e-mail voor kleine bedrijven en pak daarna hier het onderdeel aan dat vaak pas later problemen geeft.

Dit overkomt teams geregeld. Eerst komt Google Workspace erbij, dan Microsoft 365, Mailchimp, een CRM en een helpdesk. Elke leverancier zegt: “Voeg gewoon onze include toe.” Een paar maanden later is het SPF-record syntactisch geldig, maar werkt het niet meer zoals bedoeld. Mail belandt in spam en sommige berichten worden geweigerd. De oorzaak blijft onduidelijk, omdat het record er op het eerste gezicht normaal uitziet.

Het goede nieuws: de oplossing is meestal weinig spectaculair. Verwijder ongebruikte vermeldingen. Gebruik `mx` alleen als dat echt nodig is. Verplaats marketingverkeer naar een subdomein. Houd uw hoofddomein overzichtelijk.

Wat is de SPF-opzoeklimiet?

De SPF-opzoeklimiet is de in de RFC vastgelegde grens voor SPF-termen die tijdens de beoordeling DNS-lookups veroorzaken. Ontvangende servers mogen niet meer dan 10 van zulke termen verwerken in de volledige SPF-boom, inclusief geneste `include`-ketens. Overschrijdt uw beleid die grens, dan kan SPF `permerror` opleveren en verliest uw bericht een belangrijk authenticatiesignaal.

RFC 7208 legt de regel vast. De grens moet voorkomen dat SPF tot buitensporig DNS-verkeer leidt. Het is geen vrijblijvende aanbeveling of best practice, maar een protocollimiet.

Wat vaak wordt vergeten: de SPF-opzoeklimiet geldt voor het totaal. U krijgt niet 10 lookups in uw hoofdrecord en nog eens 10 binnen elke include. Het hele beoordelingspad deelt één budget.

SPF-mechanisme	Lookupkosten	Praktische betekenis
`include:`	1	Veelgebruikt, maar geneste includes tellen snel op
`a`	1	Bruikbaar bij kleine configuraties, vaak overbodig
`mx`	1+	Meestal ongeschikt voor het autoriseren van uitgaande mail
`ptr`	1+	Vermijd dit; RFC 7208 raadt het sterk af
`exists`	1	Zeldzaam en gevoelig voor verkeerd gebruik
`redirect=`	1	Nuttig in bepaalde ontwerpen, maar telt wel mee
`ip4` / `ip6`	0	Geen DNS-lookup tijdens de SPF-beoordeling
`all`	0	Alleen beleid, zonder lookupkosten

Waarom de SPF-opzoeklimiet “werkende” records kan breken

De SPF-opzoeklimiet kan records treffen die er prima uitzien. Voor SPF telt niet hoe netjes het TXT-record van uw hoofddomein is, maar hoeveel DNS-activerende termen de ontvanger moet verwerken nadat alle includes, redirects, `a`- en `mx`-termen in de keten zijn gevolgd.

Een voorbeeld:

U publiceert `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` en denkt dat u drie lookups gebruikt. Dat klopt niet. Achter zowel Google als Microsoft zitten verdere lookups. Het zichtbare record is kort, maar de volledige beoordeling niet.

Daarom duikt de SPF-opzoeklimiet vaak pas later op. Als leveranciers hun eigen SPF-boom wijzigen, kan uw aantal stijgen zonder dat u uw DNS nog aanpast.

Er is nog een valkuil: lege lookups, ook wel void lookups. RFC 7208 beveelt aan die tot twee te beperken. Een lege lookup is een DNS-query zonder antwoord of met `NXDOMAIN`. Eén typefout in een include hoeft niet meteen fataal te zijn; twee ongeldige verwijzingen kunnen wel problemen geven. Zo kan uw probleem met de SPF-opzoeklimiet een `permerror` worden, ook als u nog onder 10 zit.

De verzendrichtlijnen van Google laten eveneens zien wat er op het spel staat: ontbrekende of gebrekkige authenticatie kan bij bulkverzenders tot spamplaatsing of weigering leiden. Google beschrijft dat bulkverzenders SPF, DKIM en DMARC nodig hebben en dat berichten die niet aan de eisen voldoen, kunnen worden geweigerd of naar spam gestuurd. Zie de veelgestelde vragen over Googles verzendvereisten.

Het gebruik van de SPF-opzoeklimiet berekenen

Om het gebruik van de SPF-opzoeklimiet te berekenen, begint u bij uw hoofdrecord en telt u alle DNS-activerende mechanismen in de volledige recursieboom. Dus uw eigen termen én de verwijzingen van uw leveranciers. Komt het totaal boven 10, dan kan de beoordeling niet volgens de limiet worden afgerond.

Begin met het hoofdrecord:

dig +short txt example.com

Voorbeelduitvoer:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Bekijk daarna elk domein waarnaar wordt verwezen:

dig +short txt _spf.google.com

dig +short txt spf.protection.outlook.com

Volg de verwijzingen totdat u alleen nog `ip4`, `ip6` of afsluitende beleidstermen tegenkomt.

Gebruik deze telmethode:

Tel elke include, a, mx, ptr, exists en redirect die u tegenkomt.
Tel ook de geneste termen in opgenomen records.
Tel ip4, ip6 en all niet mee.
Markeer elk include-doel dat geen gegevens teruggeeft. Dat kan een probleem met lege lookups worden.

Wilt u bij het instellen van een domein in TrekMail snel controleren of DNS logisch is ingericht? Begin met de documentatie over DNS-status controleren en vereiste DNS-records.

Veelgemaakte fouten rond de SPF-opzoeklimiet

De meeste problemen met de SPF-opzoeklimiet komen door dezelfde fouten: leveranciers opstapelen op één hoofddomein, oude providers laten staan, `mx` als snelle oplossing gebruiken en handmatig flattenen zonder onderhoudsproces. Het zijn geen exotische oorzaken, maar gevolgen van onvoldoende DNS-beheer naarmate de inrichting groeit.

De belangrijkste boosdoeners:

Fout	Waarom dit schadelijk is	Betere aanpak
Oude leveranciers laten staan	Verspilt lookupbudget en vergroot het risico	Verwijder alles waarlangs u niet meer verzendt
`mx` gebruiken voor uitgaande authenticatie	Inkomende MX-hosts zijn vaak niet uw verzenders	Autoriseer de werkelijke verzender expliciet
`ptr` gebruiken	Traag, afgeraden en kwetsbaar	Verwijder het
Alles vanuit één domein verzenden	Marketing- en transactionele mail delen één SPF-budget	Verdeel mailstromen over subdomeinen
Handmatig flattenen	Kan misgaan als leveranciers hun IP-adressen wijzigen	Automatiseer updates of vermijd flattening

Hier verwarren teams ook zichtbare met werkelijke complexiteit. Eén include van een leverancier kan na uitwerking meerdere lookups kosten. Daarom is “nog één verzender erbij” geen veilige aanpak voor de SPF-opzoeklimiet.

Twijfelt u voor een toepassing nog tussen doorsturen, een alias of een echte mailbox? Die keuze hangt vaker samen met de verzendconfiguratie dan u denkt. Lees ook domeinmailalias versus mailbox en e-mailalias doorsturen.

De SPF-opzoeklimiet oplossen met minder risico voor mail

De verstandigste aanpak van de SPF-opzoeklimiet is het beleid vereenvoudigen, niet steeds meer noodgrepen toevoegen. Verwijder eerst ongebruikte verzenders. Verplaats daarna drukke systemen naar subdomeinen. Flatten alleen als u de gegevens automatisch actueel kunt houden.

1. Verwijder overbodige onderdelen.

Schrap leveranciers die u niet gebruikt. Verwijder `ptr`. Vervang `mx` door de autorisatie die uw echte verzender nodig heeft. Veel SPF-beleidsregels komen na zo'n opschoonronde weer onder de SPF-opzoeklimiet.

2. Verdeel verkeer over subdomeinen.

Voor groeiende teams is dit vaak een goede oplossing.

; Primary company mail
example.com.              TXT  "v=spf1 include:spf.trekmail.net -all"

; Marketing mail
marketing.example.com.    TXT  "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"

; Transactional app mail
notify.example.com.       TXT  "v=spf1 include:amazonses.com -all"

Elk subdomein krijgt zijn eigen SPF-budget. Dat kan het hoofddomein overzichtelijker houden en maakt de SPF-opzoeklimiet eenvoudiger te beheren.

3. Flatten alleen als laatste redmiddel.

Flattening vervangt includes door expliciete IP-bereiken:

; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all

; After
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

Dit kan het lookupgebruik tot bijna nul terugbrengen, maar brengt onderhoudswerk mee. Leveranciers wijzigen IP-adressen, uw record raakt verouderd en mail kan de authenticatie niet meer doorstaan. Automatiseer het onderhoud als u flattening toepast.

Oude versus nieuwe aanpak: de SPF-opzoeklimiet beheren met TrekMail

Bij de oude aanpak van de SPF-opzoeklimiet komen steeds meer mailboxproviders, marketingplatforms en relays op één hoofddomein terecht, totdat niemand de DNS-inrichting nog overziet. De nieuwe aanpak beperkt het aantal afhankelijkheden en scheidt verzendrollen vanaf het begin.

Oude aanpak: een overvol SPF-record op het hoofddomein, oude providers die blijven staan, marketingmail gemengd met mailboxverkeer en onduidelijkheid over wie mag verzenden.

Nieuwe aanpak: houd mailboxhosting eenvoudig, zet verzenders met veel verkeer op subdomeinen en geef uw hoofddomein een kort SPF-beleid met voldoende ruimte.

TrekMail kan daarbij helpen. Gebruikt u beheerde verzending via TrekMail op een betaald abonnement, dan beschrijft de DNS-configuratie `include:spf.trekmail.net` als onderdeel van uw SPF-record. Die include telt zelf als één lookup; controleer ook eventuele onderliggende verwijzingen. De beschreven prijs begint bij $3.50 per maand en de genoemde functies omvatten eigen domeinen, IMAP-mailboxen, catch-all, mailboxdoorsturing, een ingebouwde migratietool en API-toegang. Betaalde abonnementen vermelden een gratis proefperiode van 14 dagen waarvoor een creditcard nodig is. Nano wordt aangeboden als gratis abonnement zonder proefperiode en gebruikt BYO SMTP. Controleer actuele prijzen en voorwaarden.

Met Nano kunt u TrekMail als mailboxlaag gebruiken en via SES, Mailgun of een andere relay verzenden. Richt subdomeinen zorgvuldig in om te voorkomen dat uw hoofdbeleid de SPF-opzoeklimiet bereikt. De documentatie over eigen SMTP (BYO), beheerde TrekMail SMTP en een migratie starten in het dashboard behandelt de praktische uitvoering.

Voegt u domeinen samen? Lees dan ook e-mailhosting voor meerdere domeinen en e-mail op mijn domein instellen.

Tot slot: onder de SPF-opzoeklimiet blijven

Om onder de SPF-opzoeklimiet te blijven, houdt u SPF zo eenvoudig mogelijk. Beperk het aantal verzenders op het hoofddomein. Verplaats bulk- en appverkeer naar subdomeinen. Controleer leveranciersincludes telkens wanneer u een nieuw hulpmiddel toevoegt. Zit uw beleid dicht bij 10, beschouw dat dan als een waarschuwing.

Dat is de kern. De SPF-opzoeklimiet is geen theoretisch RFC-randgeval, maar een harde operationele grens die snel in beeld komt als u steeds nieuwe systemen toevoegt. Houd het record kort en de verantwoordelijkheid voor DNS duidelijk. Laat niet zomaar vijf leveranciers hetzelfde beperkte authenticatiepad delen, tenzij u graag om 2 uur 's nachts mailheaders onderzoekt.

Voor een overzichtelijkere inrichting biedt TrekMail e-mailhosting voor meerdere domeinen tegen een vast tarief, zonder kosten per gebruiker, met gedeelde opslag, ingebouwde IMAP-migratie en de keuze tussen BYO SMTP en beheerde TrekMail SMTP. Beschikbaarheid en voorwaarden kunnen per abonnement verschillen. Bekijk de prijzen van TrekMail of ga direct naar TrekMail.