DKIM-recordcontrole

De rol van DKIM bij e-mailauthenticatie

DomainKeys Identified Mail (DKIM) is een cruciale standaard voor e-mailauthenticatie die helpt bij het voorkomen van e-mailspoofing en phishing. Door een cryptografische handtekening aan de header van een e-mailbericht toe te voegen, kan de ontvangende mailserver controleren of de e-mail daadwerkelijk afkomstig is van de geclaimde verzender en of de inhoud tijdens het transport niet is gewijzigd.

De basis van deze verificatie ligt in het Domain Name System (DNS). De domeineigenaar publiceert een openbare sleutel als een DNS TXT-record. Wanneer een e-mail wordt ontvangen, haalt de ontvangende server dit record op om de handtekening in de e-mailheader te verifiëren. Een correct geconfigureerd DKIM TXT-record is daarom essentieel voor een betrouwbare e-mailbezorging.

Structuur en componenten van een DKIM TXT-record

Een DKIM-record bestaat uit een reeks tags en waarden, gescheiden door puntkomma's. Elk onderdeel heeft een specifieke functie bij het definiëren van hoe de cryptografische sleutel moet worden gebruikt:

• v (Versie): Specificeert de versie van de DKIM-standaard. Indien aanwezig, moet deze tag altijd als eerste worden geplaatst en de exacte waarde DKIM1 hebben.
• k (Sleuteltype): Geeft het gebruikte cryptografische algoritme aan, zoals rsa of ed25519.
• p (Openbare sleutel): Bevat de Base64-gecodeerde openbare sleutel die wordt gebruikt om de e-mailhandtekening te controleren.
• s (Diensten): Definieert de diensten die de sleutel mogen gebruiken, waarbij de waarde email of * (alle diensten) moet bevatten.
• h (Hash-algoritmen): Specificeert de toegestane hash-algoritmen voor de handtekening.

Cryptografische sleutels en hash-algoritmen

De veiligheid van DKIM hangt sterk samen met het gekozen sleuteltype, de sleutelgrootte en de gebruikte hash-algoritmen. De DKIM-recordcontrole herkent twee typen openbare sleutels: RSA en Ed25519.

Bij het gebruik van RSA-sleutels is de sleutelgrootte (uitgedrukt in bits) een kritieke factor voor de veiligheid. RSA-sleutels die kleiner zijn dan 1024 bits worden als onveilig beschouwd en als ongeldig gerapporteerd. Hoewel 1024-bits sleutels nog worden geaccepteerd, is de huidige aanbeveling om RSA-sleutels van minimaal 2048 bits te gebruiken om voldoende weerstand te bieden tegen moderne rekenkracht. Voor Ed25519-sleutels geldt dat de gedecodeerde openbare sleutel exact 32 bytes lang moet zijn.

Daarnaast speelt het hash-algoritme een belangrijke rol. Het verouderde sha1 is niet langer veilig voor DKIM-handtekeningen en mag niet meer worden gebruikt. In plaats daarvan moeten moderne DKIM-configuraties het gebruik van sha256 ondersteunen en toestaan.

DNS-beperkingen en de 255-byte limiet

Bij het publiceren van een DKIM-record in DNS moeten beheerders rekening houden met de technische beperkingen van het DNS-protocol. Een DNS TXT-record kan bestaan uit meerdere losse tekenreeksen (chunks). Elke individuele tekenreeks binnen het record is strikt beperkt tot een maximale lengte van 255 bytes.

Wanneer een DKIM-record (vooral bij het gebruik van een sterke 2048-bits RSA-sleutel) langer is dan 255 bytes, moet het record in het zonebestand worden opgesplitst in meerdere opeenvolgende, tussen aanhalingstekens geplaatste delen. DNS-servers voegen deze onderdelen automatisch samen bij het beantwoorden van een query. Als deze opdeling of de aanhalingstekens onjuist worden geformatteerd, raakt het record corrupt en faalt de DKIM-verificatie.

Lokale controle versus DNS-query's

De DKIM-recordcontrole voert een gerichte, lokale analyse uit van de recordtekst die u invoert. Dit verschilt wezenlijk van een live DNS-query of een volledige e-mailhandtekeningverificatie:

• Lokale verwerking: De analyse vindt volledig plaats in uw eigen webbrowser. De ingevoerde gegevens worden niet geüpload naar externe servers of opgeslagen door BroBroGo.
• Geen DNS-interactie: De tool voert geen DNS-query's uit om te controleren of het record daadwerkelijk live staat op uw domein, en controleert de geldigheid van uw DNS-selector niet.
• Geen handtekeningcontrole: Er wordt geen daadwerkelijke e-mail geanalyseerd of cryptografisch geverifieerd.

Deze tool dient als een configuratiebeoordeling om syntaxfouten, zwakke sleutels en opmaakproblemen op te sporen voordat u het record in uw DNS-zone publiceert.

Veelvoorkomende fouten en waarschuwingen

Bij het handmatig configureren of kopiëren van DKIM-records kunnen diverse fouten optreden. De controle identificeert deze problemen en geeft specifieke meldingen:

• Syntactische fouten: Zoals het ontbreken van een gelijkteken in een tag-waardepaar ("Het veld “‹tag›” mist een gelijkteken.") of een ongeldige tagnaam ("De tagnaam “‹tag›” is ongeldig.").
• Dubbele tags: Een tag mag niet meerdere keren voorkomen ("Het ‹tag›-label komt meer dan eens voor.").
• Volgorde en geldigheid van de versie: De v-tag moet altijd vooraan staan ("De v=DKIM1-tag moet de eerste tag zijn wanneer deze aanwezig is.") en exact de juiste waarde hebben ("De v tag moet precies DKIM1 zijn, niet “‹detail›”.").
• Problemen met de openbare sleutel: Het ontbreken van de sleutel ("De vereiste p-public-key tag ontbreekt.") of een ongeldige opmaak ("De p-waarde is geen geldige openbare sleutel voor het geselecteerde sleutelpaar type.").
• Ingetrokken sleutels: Een lege p-tag geeft expliciet aan dat een sleutel is ingetrokken ("De p-waarde is leeg, wat een ingetrokken DKIM-sleutel publiceert.").

Veelgestelde vragen (FAQ)

Waarom worden lange DKIM-records opgesplitst in aanhalingstekens omsloten tekenreeksen?

Een DNS TXT-record kan meerdere tekenreeksen bevatten, waarbij elke reeks is beperkt tot 255 bytes. DNS voegt de reeksen op volgorde samen, zodat alle stukjes binnen één TXT-record moeten blijven.

Welke DKIM-sleuteltypen herkent deze controle?

Het herkent RSA- en Ed25519-publieke sleutels, controleert hun Base64-vorm en meldt RSA-sleutels onder 1024-bits als ongeldig en sleutels onder 2048-bits als zwakker dan aanbevolen.

Bewijst een schoon resultaat dat DKIM werkt?

Nee. Deze pagina controleert alleen de recordtekst die je plakt. Het vraagt DNS niet op, verifieert geen berichthandtekening, bevestigt de selectornaam noch bewijst dat e-mailontvangers het record kunnen ophalen.

Wat betekent het als de p-tag leeg is in het record?

Een lege p-tag (bijvoorbeeld p=) geeft aan dat de bijbehorende DKIM-sleutel is ingetrokken. Dit wordt door mailservers geïnterpreteerd als een bewuste deactivering van die specifieke sleutel.