SPF en DMARC bij de top 10.000 domeinen: cijfers 2026

We hebben de SPF- en DMARC-checkers van InfraNest losgelaten op de 10.000 populairste domeinen van de Tranco-lijst. Van de 7.204 domeinen die mail ontvangen, combineert slechts 55,7% een geldig SPF-record met een DMARC-beleid dat ook echt wordt afgedwongen. De meeste andere publiceren iets dat op e-mailauthenticatie lijkt, maar dat staat óf op één wijziging van kapotgaan, óf is zo ingesteld dat het niets tegenhoudt.

Dit is het eerste datarapport van InfraNest. De methode en de geaggregeerde cijfers zijn openbaar, en iedereen kan dezelfde checks op zijn eigen domein herhalen.

Hoe we SPF en DMARC hebben gemeten

• De lijst: de top 10.000 domeinen van Tranco-lijst K9PXW, een onderzoeksranking van populaire sites die moeilijk te manipuleren is. Gescand op 25 september 2026.
• De checks: precies de code achter onze gratis SPF-checker en DMARC-checker. Elk cijfer in dit rapport is wat die tools de eigenaar van het domein zouden laten zien.
• DNS: de resolver van Cloudflare via HTTPS, met die van Google als terugvaloptie. 23 domeinen konden door geen van beide worden uitgelezen en zijn buiten beschouwing gelaten.
• Wie telt mee: alleen domeinen die mail ontvangen, dus met een echt MX-record. Dat zijn er 7.204. De overige 2.773 zijn vooral CDN-, API- en trackinghostnames die nooit mail versturen (75 daarvan geven dat expliciet aan met een null-MX-record).

De meeste cijfers draaien om twee definities:

Wat we niet hebben gemeten: DKIM, omdat de selectors daarvan niet uit DNS op te vragen zijn; of echte mail door de alignment-controle komt; en subdomeinen. De geaggregeerde dataset is vrij te gebruiken met bronvermelding.

Een second opinion. We hebben een willekeurige steekproef van 100 domeinen opnieuw gecontroleerd met checkdmarc, een onafhankelijke opensourcetool. Het SPF-oordeel kwam bij 98 domeinen overeen, het aantal lookups bij alle 76 records die beide tools geldig vonden, en het DMARC-beleid bij 99; elk overgebleven verschil was een record dat checkdmarc niet kon lezen of om stilistische redenen afkeurde, wat we handmatig hebben bevestigd. De kruiscontrole bracht ook een bug in onze eigen checker aan het licht: records die via twee verzenders dezelfde provider includeren, werden aangezien voor include-lussen. Dat is ook in onze SPF-checker opgelost, en alle cijfers hier komen uit de gecorrigeerde scan.

SPF-record: bijna iedereen heeft er een, en een op de zes staat op breken

92,9% van de domeinen die mail ontvangen, publiceert een SPF-record. Het zwakke punt is niet óf er een SPF-record is, maar hoeveel DNS-lookups het kost.

RFC 7208 staat een ontvangende server 10 DNS-lookups toe om een SPF-beleid te evalueren, en elke include, a, mx en exists telt mee, ook de lookups die genest zitten in de include van een provider. Bij 11 is het resultaat een permanente fout, en ontvangers behandelen het domein dan alsof het helemaal geen SPF heeft.

• 2,7% van de SPF-records (184 domeinen) zit al boven de limiet. Hun SPF-record doet niets.
• Nog eens 14,3% gebruikt 8 tot 10 lookups. Elke include kost minstens één lookup, en veel providers nesten achter hun include nog meer includes. Een nieuw CRM, helpdesksysteem of nieuwsbrieftool is dus vaak genoeg om deze domeinen over de grens te duwen, en niets waarschuwt degene die het toevoegt.
• Het mediane record gebruikt 4 lookups; een op de tien gebruikt er 9 of meer.
• 52 domeinen (0,8%) publiceren twee SPF-records. Ook dat is een permanente fout: bij twee records evalueren ontvangers geen van beide.

Hoe records eindigen, is minder zorgwekkend dan het lijkt. 46,3% eindigt op -all en 47,4% op ~all. Met een afgedwongen DMARC-beleid ervoor is ~all een prima keuze. Slechts 2,1% eindigt op ?all, wat nergens om vraagt, en maar 3 domeinen eindigen op +all, waarmee ze het hele internet toestemming geven om namens hen te versturen.

TipControleer je eigen aantal met de gratis SPF-checker. Die loopt elke include na zoals een ontvanger dat doet en laat zien welke verzender de meeste lookups kost.

DMARC-beleid: vaak gepubliceerd, veel minder vaak afgedwongen

82,3% van de domeinen die mail ontvangen, publiceert een DMARC-record, maar slechts 58,3% dwingt het af. Het verschil zit in p=none: een beleid dat ontvangers vraagt mislukte controles te rapporteren en er verder niets mee te doen.

Monitoringmodus is de juiste manier om met DMARC te beginnen. Het is de verkeerde plek om te blijven hangen, en de data doet vermoeden dat veel domeinen er nooit uit komen: 21,8% van alle maildomeinen zit er op dit moment in.

Ook de rapportagekant heeft zijn eigen problemen:

• 11,0% van de maildomeinen publiceert DMARC zonder enig rapportadres (rua). Ze hebben een beleid, maar geen manier om te zien wat het tegenhoudt.
• Nog eens 5,3% stuurt de rapporten naar een adres dat ze nooit zal ontvangen. Als het rapportadres bij een ander domein hoort, eist RFC 7489 dat dat domein een autorisatierecord publiceert (<your-domain>._report._dmarc.<their-domain>). Zonder dat record sturen ontvangers die zich aan de standaard houden niets, en concludeert de eigenaar dat niemand namens hem mail verstuurt.
• 2,1% van de DMARC-records past het beleid met een pct onder 100 maar op een deel van de mail toe.

De top 1.000 doet het beter, maar niet veel

Van de 1.000 populairste domeinen heeft 71,1% een geldige SPF en een afgedwongen DMARC, tegenover 54,1% bij de posities 1.001 tot 10.000. De top 1.000 gebruikt ook vaker p=reject: 57,2% van de DMARC-records, tegenover 40,8% daaronder.

Eén ding is aan de top juist slechter: 3,4% van de SPF-records in de top 1.000 zit boven de lookup-limiet, tegenover 2,7% daaronder. Grotere organisaties versturen via meer diensten, en elke dienst kost lookups.

Wat ik hieruit haal

Ik verwachtte verwaarlozing te vinden. Dat vond ik niet. Meer dan negen op de tien van deze domeinen publiceren SPF, en vier op de vijf publiceren DMARC. Iemand heeft ooit het werk gedaan. Wat misgaat, is alles na die eerste inrichting.

Niemand is eigenaar van het record. Marketing voegt een nieuwsbrieftool toe, sales een CRM, support een helpdesksysteem, en elk ervan verbruikt ongemerkt een lookup of twee, tot het budget op is. p=none was bedoeld als een paar weken meekijken en wordt de permanente instelling. En de rapporten gaan naar een inbox die niemand leest, of, bij een op de twintig domeinen, naar een adres dat ze nooit zal ontvangen.

Dat patroon herken ik. Ik heb twaalf jaar kassa- en automatiseringssystemen gebouwd voor restaurants en winkels, en het was altijd hetzelfde: de inrichting krijgt aandacht, het onderhoud niet, want er gaat niets stuk op de dag dat je de wijziging doorvoert. E-mailauthenticatie is zo'n systeem. Het faalt stilletjes, weken na de wijziging die het kapotmaakte, en het eerste signaal is vaak een klant die vraagt waarom je e-mail in zijn spammap belandde.

Daarom heb ik de checkers van InfraNest ook zo gebouwd dat ze de berekening laten zien in plaats van een groen vinkje, en daarom zeg ik ook gewoon eerlijk dat onze eigen SPF-checker tot deze week één geval verkeerd beoordeelde. Juist door dit rapport tegen een onafhankelijke tool te controleren, kwam dat aan het licht. Als je dingen meet voor anderen, controleer je eerst je eigen instrumenten.

Als je domein mail verstuurt, zijn deze drie checks deze week tien minuten van je tijd waard:

1. Tel je SPF-lookups. Zit je op 8 of meer, maak dan een plan voordat de volgende tool erbij komt. Verplaats bulkverzenders naar een subdomein met een eigen SPF-record, of verwijder includes van diensten die je niet meer gebruikt.
2. Geef p=none een einddatum. Lees de rapporten een paar weken, los de legitieme verzenders op die falen, en stap dan over op quarantine en later op reject.
3. Zorg dat je rapporten aankomen. Als rua naar een ander domein verwijst, controleer dan of dat domein het autorisatierecord voor jouw domein publiceert. De DMARC-checker test dit voor je.

Controleer je eigen domein

Haal je domein door de SPF-checker en de DMARC-checker; moet er iets worden gerepareerd, dan bouwen de SPF-generator en de DMARC-generator een gecorrigeerd record. Om later te merken dat deze records veranderen, bevat het DNS-beheer van InfraNest drift detection over al je providers heen.

Bron: InfraNest-scan van de top 10.000 domeinen van Tranco-lijst K9PXW (Le Pochat et al., "Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation", NDSS 2019), 25 september 2026. Geaggregeerde data: email-auth-2026-09.json, CC BY 4.0.