DKIM-controle:
is uw sleutel sterk genoeg?

Typ uw domein hierboven in — selector optioneel. Wij halen het TXT-record op bij selector._domainkey.yourdomain (en proberen tien gangbare selectors als u dit veld leeg laat), toetsen elke tag aan RFC 6376 en valideren vervolgens de sleutel zelf: de p=-waarde wordt base64-gedecodeerd, de DER-structuur erin wordt veld voor veld doorlopen, en de modulus wordt gemeten en beoordeeld — onder 1024 bit is zwak, 1024 acceptabel, 2048+ aanbevolen. Gratis, geen registratie.

De selector is de naam vóór ._domainkey — gekozen door wie het ondertekenen heeft ingesteld, en onzichtbaar voor elke DNS-lijst. Drie manieren om de uwe te vinden: open een bericht dat u heeft verzonden en lees de s=-tag in de DKIM-Signature-header uit (in Gmail: „Origineel weergeven”); plak die hele header in deze tool en wij halen hem eruit; of laat de selector leeg en wij proberen de tien meest gangbare standaardnamen — google, selector1/2, k1/k2, s1/s2, default, dkim, mail. Twee live selectors vinden is normaal — dat is rotatie die werkt.

Acceptabel, verouderend, en de moeite waard om in te plannen. Niemand heeft RSA-1024 publiekelijk gefactoriseerd — maar NIST heeft het al in 2013 verboden voor nieuwe handtekeningen, RFC 8301 schrijft voor dat DKIM-ondertekenaars 2048 zouden moeten gebruiken, en de grote mailboxproviders ondertekenen zelf ook met 2048. 1024 is niet de noodsituatie — dat is 512, gefactoriseerd in 2012 met gehuurde cloud-rekenkracht. Het is de sleutel die u op uw eigen schema roteert, in plaats van, uiteindelijk, op dat van een aanvaller.

Testmodus. RFC 6376 §3.6.1 draagt verifiers op om mail van een domein in testmodus niet anders te behandelen dan onondertekende mail — zelfs als de handtekening perfect klopt. De vlag bestaat zodat u DKIM tijdens de uitrol risicoloos kunt uitproberen. Het addertje is dat hij te goed werkt: er gaat niets kapot zolang hij aanstaat, dus wordt hij nooit verwijderd. Uw domein ondertekent dan jarenlang mail voor niets. Vindt deze tool er een, dan bestaat de oplossing uit het verwijderen van vier tekens.

Een bewuste intrekking. RFC 6376 definieert een lege p= als „deze publieke sleutel is ingetrokken”. Het is de juiste doodverklaring voor een selector die u heeft uitgefaseerd, en duidelijker dan het record verwijderen, wat er hetzelfde uitziet als een typfout. Daaruit volgen twee lezingen. Bent u van deze selector weg geroteerd en ondertekent niets er meer mee, dan is het gewoon hygiëne: laat het zo. Ondertekent een afzender er nog steeds mee, dan faalt elk van die berichten op dit moment op DKIM. Controleer uw DMARC-rapporten op dkim=fail bij deze selector.

Verifiers moeten tot 4096 bit ondersteunen (RFC 8301). Maar een 4096-bit sleutel levert een TXT-waarde op die lang genoeg is om gesplitst te moeten worden, en dat verknoeien sommige DNS-provider-UI's. Voor een sleutel die u toch al zou moeten roteren, levert dat geen praktische winst op ten opzichte van 2048, dus 2048 is de sweet spot. De andere richting is k=ed25519 (RFC 8463): piepkleine sleutels van 32 bytes, moderne cryptografie. Ondersteuning bij verifiers is nog niet universeel, dus opzetten die dit gebruiken, ondertekenen doorgaans dubbel met RSA erbij. Deze tool leest k= uit en meldt welke u heeft gepubliceerd.

Alleen — nee, en dat zeggen we liever eerlijk. DKIM bewijst twee dingen: het bericht is sinds ondertekening niet gewijzigd, en het d=-domein staat ervoor in. Het bewijst niet dat de From:-regel die uw lezer ziet, overeenkomt met dat domein — een vervalser kan foutloos ondertekenen met zijn eigen domein terwijl hij het uwe toont. Dat gat dichten is de taak van DMARC (alignment), en bepalen welke servers überhaupt mogen verzenden is de taak van SPF. De werkende stack is SPF + DKIM + DMARC. Deze tool zorgt ervoor dat de DKIM-poot echt is — een ingetrokken of testmodus-sleutel ondermijnt de andere twee ongemerkt.