SPF-controle:
blijft uw record binnen de limiet van 10 lookups?

Typ hierboven uw domein. Wij halen de TXT-records op, bevestigen dat precies één begint met v=spf1 (twee is een directe fail — ze smelten niet samen, ze sneuvelen allebei), en parsen vervolgens elk mechanisme tegen RFC 7208: elke include wordt recursief uitgeklapt tot een boom, elke DNS-lookup wordt geteld tegen het budget van 10, het uiteindelijke all-beleid wordt beoordeeld, en elk IP-bereik dat uw record autoriseert, wordt opgeteld tot één lijst. Gratis, geen registratie.

Ontvangers die SPF evalueren, voeren per controle maximaal 10 DNS-bevragende mechanismen uit (RFC 7208 §4.6.4). include, a, mx, ptr, exists en redirect tellen allemaal mee, inclusief de mechanismen die verstopt zitten in de includes van uw leveranciers. Bij lookup #11 breekt de evaluatie af met permerror. Er bounct niets aan uw kant; DMARC behandelt uw domein simpelweg alsof het geen SPF publiceert. De storing komt geleidelijk, één aanmelding per keer, en kondigt zich nooit aan.

-all is de bestemming: weiger wat niet van u is. ~all is de reis ernaartoe: „markeer het, weiger het niet”. Dat is de juiste instelling zolang u nog verzenders ontdekt — die facturatietool waar niemand het over had. Het is ook de veilige keuze als een verloren legitieme e-mail u meer kost dan een vervalste. Twee kanttekeningen: met DMARC erbij krimpt het praktische verschil, want DMARC laat onbevoegde mail bij beide falen. En -all aan het einde van een record dat over de lookup-limiet gaat, is strengheid vastgemaakt aan een lijk — de permerror wint.

Nee — en de faalwijze is meedogenloos. RFC 7208 zegt dat meerdere v=spf1-records ervoor zorgen dat de controle permerror teruggeeft: niet „de eerste wint”, niet „ze smelten samen” — allebei worden ongeldig. Meestal gebeurt het onschuldig: een website-plugin, een wizard van een verzenddienst of een tweede beheerder die „SPF toevoegt” zonder het bestaande record op te merken. De oplossing kost één minuut: voeg alle mechanismen samen tot één record en verwijder de rest. Deze tool telt uw records daarom als allereerste, vóór al het andere.

Het beëindigt uw record met „…en iedereen anders slaagt ook.” Elk IP op het internet wordt een bevoegde verzender voor uw domein: een spammer die uw adres vervalst, krijgt een SPF-pass, en als uw DMARC-beleid steunt op SPF-alignment, kan die vervalste mail ook DMARC passeren — uw authenticatie staat nu garant voor de aanvaller. Het is echt erger dan helemaal geen SPF publiceren, want „geen record” maakt ontvangers achterdochtig, terwijl „+all” ze juist vertrouwen geeft. Het duikt in het wild op als een misplaatste deliverability-„fix”. Als deze tool er één vindt, zal dat allerminst subtiel worden gemeld.

Op zichzelf niet. SPF valideert de envelope-afzender (het adres uit de SMTP-conversatie), niet het From:-veld dat uw lezer ziet. Een vervalser kan SPF laten slagen op zijn eigen domein terwijl hij het uwe toont. Dat gat dichten is de taak van DMARC: het eist dat het zichtbare From overeenkomt met wat SPF of DKIM valideerde, en vertelt ontvangers ook wat ze moeten doen als dat niet zo is. De volledige stack is SPF + DKIM + DMARC, en deze tool zorgt dat het SPF-deel overeind staat, want een permerror hier ondermijnt stilzwijgend de andere twee.

In volgorde van pijn: verwijder wat niets verzendt — a en mx zijn gratis winst als uw webserver en MX nooit uitgaande mail versturen. ptr is altijd te verwijderen. Verwijder dode leveranciers — elke include hoort bij een dienst waar u nog voor betaalt. Splits per subdomein — laat nieuwsbrieven verzenden als news.uwdomein.com met een eigen record en eigen budget. Laatste redmiddel, flattening: includes vervangen door hun letterlijke ip4/ip6-reeksen kost nul lookups. Maar het bevriest een kopie van de netwerken van uw leveranciers — als die hernummeren, rot uw record stilzwijgend weg. Flatten alleen met tooling of monitoring die het opnieuw controleert.