SPF-opzoeklimiet: controleren en zorgvuldig herstellen

De SPF-opzoeklimiet is zo'n DNS-beperking die onschuldig lijkt totdat mail problemen krijgt. Je voegt een afzender, CRM of helpdesk toe en de SPF-evaluatie overschrijdt een protocolgrens. Een normaal bericht kan vervolgens worden gefilterd, vertraagd of geweigerd. Dat gevolg is afhankelijk van de ontvanger en de overige authenticatie, niet automatisch hetzelfde voor elke mail.

Begin voor de bredere rol van SPF bij zakelijke e-mail. Die context is belangrijk: SPF is geen afgevinkt brandingonderdeel, maar een van de signalen waarmee een ontvanger beoordeelt of een bron namens een domein mag versturen.

Deze gids legt uit wat de limiet inhoudt, wat meetelt, waarom flattening niet zonder onderhoud werkt en hoe je een inrichting maakt die ook bij toekomstige wijzigingen beheersbaar blijft.

Wat is de SPF-opzoeklimiet?

De SPF-opzoeklimiet begrenst tijdens SPF-evaluatie het aantal mechanismen en modifiers dat DNS-opzoekingen veroorzaakt. Volgens RFC 7208 is die grens 10. Overschrijding levert permerror op, geen geslaagde SPF.

Kortom: SPF heeft een evaluatiebudget. Worden meer dan 10 DNS-opzoekende termen bereikt, dan hoort de ontvanger de evaluatie te stoppen met een permanente fout. Dat is geen eigenaardigheid van Gmail, maar een regel uit de SPF-specificatie. Het gaat niet simpelweg om het aantal DNS-pakketten dat je ziet.

RFC 7208 noemt de termen die meetellen: include, a, mx, ptr, exists en redirect. ip4, ip6 en all verbruiken dit budget niet.

Dat onderscheid is belangrijk. De lengte van je record vertelt niet wat evaluatie kost. Een kort record kan te veel opzoekende termen activeren; een langer record kan binnen de limiet blijven. Onderzoek het daadwerkelijke evaluatiepad.

Wat telt mee voor de SPF-opzoeklimiet?

De SPF-opzoeklimiet telt de relevante DNS-opzoekende mechanismen en modifiers, niet alle woorden in je TXT-record. Geneste includes tellen ook mee wanneer ze tijdens evaluatie worden gevolgd. Wat je in je eigen DNS-paneel ziet, kan dus minder zijn dan de totale evaluatiekosten.

Deze termen gebruiken het budget:

1. include: evalueert SPF van een ander domein en matcht wanneer die evaluatie slaagt.
2. a: controleert de adresrecords van een host tegenover het verbindende IP.
3. mx: controleert MX-hosts en hun adresrecords, met aanvullende limieten.
4. ptr: gebruikt reverse DNS en wordt afgeraden.
5. exists: controleert of de bedoelde DNS-query voor een A-record een resultaat oplevert.
6. redirect: gebruikt een ander SPF-beleid als het huidige record geen mechanisme laat matchen.

Deze termen gebruiken geen DNS-opzoekbudget tijdens SPF-evaluatie:

• ip4
• ip6
• all

De valkuil is recursie. Neemt je record Microsoft op en verwijst diens SPF weer naar andere records, dan tellen de gevolgde onderliggende termen mee voor hetzelfde budget. Je bent dus mede afhankelijk van het SPF-ontwerp van je leveranciers.

Je denkt dat je 6 afzenders hebt toegevoegd, maar de ontvanger kan na recursie 11 of 12 opzoekende termen tegenkomen. Zo overschrijdt een team de SPF-opzoeklimiet terwijl het dacht nog onder 10 te zitten.

Waarom groeiende teams tegen de limiet aanlopen

De SPF-opzoeklimiet komt vaak in beeld na het toevoegen van tools, niet alleen na een hostingwissel. Marketingplatforms, supportpakketten, recruitmentapps, CRM en transactionele diensten vragen allemaal om een include, die gemakkelijk in hetzelfde hoofddomeinrecord belandt.

Aanvankelijk kan het record eenvoudig zijn. De volgende voorbeelden zijn illustratief; controleer actuele leverancierwaarden en je afzenders voordat je ze publiceert:

v=spf1 include:_spf.google.com ~all

Daarna groeit het aantal diensten:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspot.com include:amazonses.com ~all

Je beheert dan niet alleen een eigen beleid, maar een keten van afhankelijkheden die buiten je eigen DNS kan veranderen.

Daarom kan de SPF-opzoeklimiet in productie onverwacht problemen geven. Je veranderde vanochtend niets, maar een leverancier wijzigde zijn interne structuur. Een eerder geslaagde evaluatieroute kan daardoor later permerror opleveren.

Is het afleverprobleem breder dan SPF, lees dan TrekMails uitleg over waarom e-mails in spam belanden. Authenticatie, reputatie, inhoud en ontvangerbeleid kunnen naast elkaar een rol spelen.

Wat gebeurt er bij overschrijding?

Bij overschrijding van de SPF-opzoeklimiet wordt de SPF-uitkomst permerror. Ontvangers hoeven het bericht vervolgens niet allemaal hetzelfde te behandelen, maar er is geen geslaagde SPF-route meer beschikbaar.

Een evaluatie die de limiet overschrijdt krijgt geen gedeeltelijke goedkeuring omdat zij er bijna binnen bleef. Zoek daarom de oorzaak uit in plaats van de fout als onschuldig te beschouwen.

Googles huidige richtlijnen vragen ook om passende authenticatie en domeinafstemming. Verstuur je op grotere schaal naar Gmail, controleer dan zowel SPF als DKIM en de toepasselijke eisen. Zie Googles richtlijnen voor e-mailafzenders.

Er zijn ook verwante grenzen om te kennen:

1. Lege DNS-resultaten. RFC 7208 beveelt aan het aantal void lookups tot twee te beperken. Een fout in een include of een verdwenen leveranciersdomein kan bijdragen aan permerror.
2. Omvang van DNS-antwoorden. Grote antwoorden kunnen worden afgekapt en fallback vereisen. Netwerk- of resolverproblemen kunnen dan tijdelijke fouten of time-outs veroorzaken; een groot record alleen bewijst zo'n probleem niet.

Waarom SPF-flattening geen onderhoudsvrije oplossing is

De SPF-opzoeklimiet maakt flattening aantrekkelijk: vervang includes door IP-adressen en verminder het budgetverbruik. Daarmee kun je een beperking omzeilen, maar je neemt ook verantwoordelijkheid voor het actueel houden van die adressen.

Handmatige flattening ziet er bijvoorbeeld zo uit:

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

Dit kost weinig opzoekbudget, maar SaaS-leveranciers kunnen IP-reeksen en infrastructuur wijzigen. Verouderde adressen kunnen legitieme afzenders niet langer toelaten of oude infrastructuur blijven autoriseren. Plan betrouwbare updates en controle als je flattening gebruikt.

De oude aanpak is steeds meer leveranciers in hetzelfde hoofddomeinrecord stoppen en daarna telkens flattenen als het te complex wordt.

Een andere aanpak is verzendfuncties verdelen over passende subdomeinen, het SPF-beleid per daadwerkelijk gebruikt envelopdomein beperken en geldige, afgestemde DKIM instellen. Dat kan afhankelijkheden beter beheersbaar maken en de verantwoordelijke dienst duidelijker aanwijzen.

Volgens het huidige aanbod biedt TrekMail eigen domeinen, IMAP-mailboxen, catch-all, migratie en forwarding, plus eigen of beheerde SMTP afhankelijk van het plan. Gratis plannen kunnen eigen SMTP gebruiken; betaalde plannen kunnen beheerde SMTP omvatten. Controleer de actuele functies en limieten, in plaats van aan te nemen dat elk domein of elke mailbox onbeperkt inbegrepen is. Zie vereiste DNS-records en eigen SMTP gebruiken.

Een duurzame aanpak voor de SPF-opzoeklimiet

Segmentatie kan een goede langetermijnaanpak voor de SPF-opzoeklimiet zijn. Scheid gewone bedrijfsmail, marketing, support en transactionele mail waar passend. De verzenddienst moet het bedoelde subdomein daadwerkelijk als envelopdomein gebruiken; alleen een DNS-record toevoegen creëert geen nieuwe evaluatieroute.

Een mogelijk model:

1. Hoofddomein voor persoonlijke zakelijke mail, bijvoorbeeld alice@company.com.
2. Marketingsubdomein, bijvoorbeeld newsletter.company.com.
3. Supportsubdomein, bijvoorbeeld support.company.com.
4. Transactioneel subdomein, bijvoorbeeld updates.company.com.

Voorbeeldrecords, aan te passen na controle van de actuele leverancierseisen:

company.com TXT "v=spf1 include:_spf.google.com ~all"
newsletter.company.com TXT "v=spf1 include:servers.mcsv.net ~all"
support.company.com TXT "v=spf1 include:mail.zendesk.com ~all"
updates.company.com TXT "v=spf1 include:sendgrid.net ~all"

Elke afzonderlijke SPF-evaluatie heeft zijn eigen budget van 10 opzoekende termen. Daarmee kun je het gedeelde risico beperken, mits de gekozen envelopdomeinen echt worden gebruikt en elk genest beleid binnen de limieten blijft.

Het kan ook helpen verkeersstromen apart te volgen. Het is echter geen reputatiefirewall: providers kunnen reputatie op IP-, domein- of organisatieniveau combineren. Slechte marketingpraktijken kunnen dus ook elders gevolgen hebben.

Voor nieuwe domeinen helpen TrekMails documentatie over een domein toevoegen en DNS-verificatie bij de controles. Bij een overstap kan IMAP-migratie handmatig kopieerwerk beperken. Zij verplaatst mailboxgegevens, niet DNS, apps of reputatie, en garandeert geen overstap zonder onderbreking.

Hoe controleer je het SPF-opzoekbudget?

Meet de SPF-opzoeklimiet in plaats van te gokken. Haal het ruwe TXT-record op en volg de includes en redirect-paden die voor je afzender worden geëvalueerd, inclusief geneste verwijzingen.

Begin met dig:

dig txt example.com +short

dig txt _spf.google.com +short

dig txt spf.protection.outlook.com +short

Tel vervolgens de relevante opzoekende termen op het evaluatiepad, ook onderliggende termen. Controleer waar het pad stopt bij een match; alleen alle woorden optellen is geen volledige SPF-evaluatie.

Een praktische werkwijze:

1. Haal SPF op voor het werkelijk gebruikte envelopdomein of subdomein.
2. Noteer elke include, a, mx, exists en redirect; houd ook rekening met afgeraden reverse-DNS-mechanismen als die nog aanwezig zijn.
3. Volg geneste records en herhaal de evaluatie, met aandacht voor matches en foutresultaten.
4. Verwijder diensten die na verificatie niet meer versturen.
5. Beoordeel geschikte envelopsubdomeinen voordat je flattening inzet.

Controleer ook dubbele SPF-records. Combineer het beleid in één SPF TXT-record per host in plaats van losse records voor verschillende diensten te publiceren. Een TXT-record kan technisch meerdere tekenreeksen bevatten. Voor de bredere inrichting zijn e-mail met een domein maken, e-mailhosting voor meerdere domeinen en imapsync nuttig.

TrekMails rol in een overzichtelijker inrichting

TrekMail verwijdert de SPF-opzoeklimiet niet: het is een protocolregel. Een platform kan wel helpen de inrichting eromheen overzichtelijker te beheren. Kosten en benodigde accounts hangen af van plan en gebruik.

Dat is voor verschillende doelgroepen relevant.

Zelfstandige oprichters en kleine teams kunnen mail op het hoofddomein eenvoudig houden en passende eigen of beheerde SMTP kiezen. Bureaus en MSP's kunnen klantstromen scheiden en beschikbare domeinbeheerfuncties benutten. Een prijsmodel zonder bedrag per gebruiker kan daarbij passen, maar voorkomt geen complexe configuratie op zichzelf.

Oude en nieuwe aanpak:

Oud: bedrijfsmail, aliassen, apps en marketing bij dezelfde provider en in hetzelfde SPF-record verzamelen omdat extra onderdelen duurder kunnen zijn.

Nieuw: een passend multi-domeinmodel gebruiken, IMAP-mailboxen centraal beheren, echte envelopdomeinen per functie kiezen en SPF beperkt houden ondanks leverancierswijzigingen.

Volgens de huidige prijzen begint Starter bij $3.50 per maand. Het gratis aanbod bij $0 vermeldt 10 domeinen, 5GB gedeelde opslag en eigen SMTP. Betaalde plannen kunnen beheerde SMTP, hogere limieten en aanvullende automatisering bevatten. Controleer actuele voorwaarden op TrekMail-prijzen.

Conclusie: behandel de SPF-opzoeklimiet als ontwerpvoorwaarde

De SPF-opzoeklimiet is geen zeldzame uitzondering, maar een vaste protocolbeperking. Groeit je verzameling diensten, controleer dan preventief of je evaluatiepaden binnen de grenzen blijven.

Wacht niet op permerror om een te vol beleid te ontdekken. Inventariseer afzenders, verwijder ongebruikte includes, splits waar passend de werkelijke envelopdomeinen en houd het hoofddomein overzichtelijk. Test wijzigingen en zorg voor monitoring en terugdraaimogelijkheden. Zo beperk je het risico voor dagelijkse zakelijke mail, zonder aflevering te beloven.

Voor een overzichtelijker beheer van meerdere domeinen kun je TrekMails actuele functies voor eigen domeinen, IMAP-mailboxen, gedeelde opslag, migratie en SMTP beoordelen. Geschiktheid en limieten hangen van het plan af. Bekijk het gratis aanbod op trekmail.net of vergelijk plannen op trekmail.net/pricing.