DKIM-sleutel: geschikte lengte, DNS-publicatie en rotatie

Uw DKIM-sleutel is onderdeel van de DNS-configuratie waarmee ontvangers uw mail verifiëren. Een zwakke, ongeldige of verouderde sleutel kan de authenticatie en verwerking schaden. Gmail heeft sinds februari 2024 verzendvereisten gehandhaafd en beschrijft verdere handhaving vanaf november 2025; raadpleeg de actuele richtlijnen. Ruimt u de DNS-basis nog op, begin dan bij zakelijke e-mail.

Het korte advies: gebruik waar ondersteund een RSA-sleutel van 2048 bits. Publiceer die correct in DNS, zo nodig met meerdere strings tussen aanhalingstekens binnen één TXT-record. Roteer volgens een schema met selectors. Laat de oude selector na de omschakeling voldoende lang staan voor onderweg zijnde mail. Dat is een zorgvuldig uitgangspunt, geen garantie tegen fouten.

Voor een nieuw domein gebruikt u ook e-mail maken met uw domein en TrekMails controlelijst met vereiste DNS-records, zodat DKIM, SPF en DMARC samen worden ingericht.

Wat is een DKIM-sleutel?

Hier bedoelen we het openbare deel van uw DKIM-sleutelpaar. Uw verzendsysteem ondertekent uitgaande mail met de privésleutel. Ontvangers halen de openbare sleutel uit DNS om de ondertekende inhoud en de autorisatie door het ondertekenende domein te controleren. Dit bewijst niet op zichzelf het auteurschap van het zichtbare From-adres.

DKIM staat voor DomainKeys Identified Mail. De privésleutel blijft op het verzendsysteem; de openbare sleutel staat onder een selector in DNS, bijvoorbeeld s1._domainkey.example.com.

Bij ontvangst leest de server de DKIM-handtekening in de headers, haalt de sleutel uit DNS op en verifieert de handtekening. Bij een geldige verificatie kan hij vaststellen:

• De ondertekende headers en het ondertekende deel van de inhoud komen overeen volgens de gebruikte canonicalisatieregels.
• De ondertekenaar had toegang tot de privésleutel voor dat domein en die selector.

Dat garandeert geen inboxplaatsing. Het geeft wel een cryptografisch authenticatiesignaal dat moderne filters kunnen gebruiken.

Welke sleutellengte gebruikt u?

Een RSA-sleutel van 2048 bits is een gangbare aanbeveling voor 2025 en 2026. De norm staat nog 1024 bits toe, maar 2048 bits geeft meer cryptografische marge en is doorgaans praktischer dan 4096 bits, met grotere DNS-antwoorden en mogelijke compatibiliteitsproblemen. Controleer ondersteuning bij uw systemen.

De formele basis staat in RFC 8301: ondertekenaars moeten RSA-sleutels van minstens 1024 bits gebruiken en zouden minstens 2048 bits moeten gebruiken. Die aanbeveling is belangrijk voor de praktische keuze.

Neemt u een oude mailomgeving over, ga dan niet uit van een goede sleutel. Oudere panelen en mailsystemen genereerden vaak standaard 1024 bits. Controleer of een sterkere sleutel nu ondersteund wordt.

Googles documentatie onderstreept de operationele betekenis. Gmail vereist DKIM voor bulkverzenders en de FAQ beschrijft mogelijke snelheidsbeperking bij authenticatiefouten. Zie Googles FAQ over verzendrichtlijnen.

Waarom een sleutel van 2048 bits problemen geeft in DNS

Een RSA-sleutel van 2048 bits kan verkeerd worden gepubliceerd doordat een afzonderlijke DNS-TXT-string maximaal 255 octetten bevat. Het volledige openbare sleutelmateriaal is langer. Een paneel dat één lange waarde verwacht, kan die weigeren, afkorten of onjuist opslaan.

Hier gaat het vaak mis. Niet de cryptografie, maar de DNS-interface is dan het probleem.

De waarde in p= is voor een RSA-sleutel van 2048 bits lang genoeg om meerdere geciteerde strings binnen één TXT-record nodig te hebben. De DKIM-verificatiesoftware voegt die strings samen; de resolver hoeft ze niet tot één string om te vormen. Onjuiste publicatie kan verificatie laten mislukken.

Veelvoorkomende fouten:

• Het DNS-paneel kapt het record af bij 255 octetten.
• Het paneel voegt ongewenste spaties of regeleinden in de sleutel toe.
• U publiceert meerdere TXT-records in plaats van één record met meerdere strings.
• U verwijdert een deel van het voorvoegsel v=DKIM1; k=rsa; p= bij een poging de waarde in te korten.

Dat levert geen zwakkere sleutel op, maar een ongeldige sleutelpublicatie.

Een sleutel van 2048 bits correct publiceren

Publiceer één TXT-record per selector en splits de lange waarde alleen in DNS-strings. De ontvangende applicatie voegt die samen. Houd de syntaxis geldig en controleer het exacte DNS-antwoord via de opdrachtregel.

In een zonebestand ziet dat er zo uit:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

Veel webinterfaces verwachten hetzelfde record op één regel:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

Controleer vervolgens van buitenaf. Vertrouw niet alleen op de voorbeeldweergave.

dig txt s1._domainkey.example.com +short

Het TXT-antwoord moet volledig terugkomen. Twee geciteerde strings zijn normaal. Ontbrekende delen, vreemde escaping of gedeeltelijke uitvoer vragen nader onderzoek van het record en de gebruikte opdracht.

In TrekMail kunt u de documentatie over beheerde TrekMail SMTP en de DNS-wizard volgen. Betaalde abonnementen beschrijven beheerde SMTP en het benodigde domeinspecifieke DKIM-record in het dashboard. De vermelde startprijs voor Starter is $3.50 per maand, met een proefperiode van 14 dagen waarvoor een creditcard nodig is. Nano wordt aangeboden als gratis abonnement met eigen SMTP. Controleer de actuele voorwaarden.

Voorbeeld: u genereert een sleutel van 2048 bits en plakt die bij een registrar die lange TXT-waarden ongemerkt afkort. Mail verlaat nog steeds uw server, maar de ontvanger kan de DKIM-handtekening niet verifiëren. Daarom controleert u van buitenaf.

Een DKIM-sleutel roteren met minder risico voor mail

Maak een nieuwe selector, publiceer de nieuwe openbare sleutel, schakel de ondertekening over en laat de oude selector gedurende een passende overgangsperiode staan. Overschrijf de oude sleutel niet zomaar op dezelfde plek. Rotatie via selectors kan fouten bij vertraagde of opnieuw aangeboden mail helpen voorkomen.

Een zorgvuldige werkwijze:

1. Genereer een nieuw sleutelpaar van 2048 bits.
2. Geef het een nieuwe selector, bijvoorbeeld s2.
3. Publiceer s2._domainkey.example.com in DNS.
4. Schakel de verzendconfiguratie over naar s2.
5. Laat s1 nog minstens enkele dagen gepubliceerd, passend bij uw wachtrijen en beleid.
6. Verwijder s1 pas nadat oude ondertekende mail voldoende tijd heeft gehad.

Een voorbeeld van een praktische overgangsperiode is 7 dagen. Dat is geen garantie dat elke wachtrij, herhaalpoging en DNS-cache dan is afgehandeld. Bij een gecompromitteerde sleutel kan onmiddellijk intrekken belangrijker zijn dan een overgangsperiode.

Vervang de sleutel niet onder dezelfde selector tenzij u de gevolgen voor ondertekening, aflevering en caches begrijpt. De meeste teams kunnen niet alle situaties beheersen. Gebruik selectors waarvoor ze bedoeld zijn.

Documenteer bij meerdere verzendsystemen welke selector bij welk systeem hoort. Dat helpt bij fouten van CRM, ticketsystemen, webapps en mailboxproviders die hetzelfde domein gebruiken.

Wanneer roteert u een DKIM-sleutel?

Roteer volgens een vaste planning en ook bij blootstelling van een privésleutel, providerwisseling of migratie van het verzendplatform. Een halfjaarlijkse cyclus kan een werkbaar uitgangspunt zijn. Omgevingen met meer risico kunnen vaker roteren; een duidelijk beleid is beter dan losse, onvoorspelbare ingrepen.

De praktische regel: als de privésleutel mogelijk is gelekt, handel dan onmiddellijk volgens uw incidentprocedure. Is er niets mis, volg dan uw rotatieschema.

Redenen om eerder te roteren:

• U verplaatste uitgaande mail naar een andere provider.
• U beëindigde de samenwerking met een leverancier die kon ondertekenen.
• U exporteerde sleutels via een onveilige procedure.
• U vond een oud gedeeld beheerdersaccount zonder duidelijke eigenaar.

Geen goede redenen om uit te stellen:

• “Dat doen we later als er tijd is.”
• “De huidige sleutel slaagt nog, dus alles is goed.”
• “We weten niet meer waar de privésleutel staat.”

Bij veel klantdomeinen wordt dit een beheerprobleem, niet een cryptografisch probleem. Dan wordt e-mailhosting voor meerdere domeinen relevant. Eén domein is handwerk; vijftig domeinen vragen een proces.

Moet u Ed25519 voor DKIM gebruiken?

Ed25519 geeft een veel kortere sleutel en vermijdt de lange TXT-waarden van RSA-2048. De afweging is ondersteuning bij ontvangers. Het is voor DKIM gestandaardiseerd in RFC 8463, maar RSA-2048 is doorgaans een voorspelbaardere standaardkeuze voor brede interoperabiliteit.

Het praktische voordeel is de omvang. Een openbare Ed25519-sleutel is veel kleiner dan een RSA-sleutel, waardoor publicatie in DNS eenvoudiger kan zijn.

Het nadeel is wisselende ondersteuning. Sommige ontvangers en tools verwerken dit goed; bij andere moet u de werking testen. Voor brede compatibiliteit is RSA-2048 een gangbare keuze, zonder universele garantie. Ondersteunt uw platform dubbele ondertekening en kent u het mailpad, dan kan testen van Ed25519 naast RSA zinvol zijn.

Voor de meeste beheerders:

• Gebruik RSA-2048 als standaardkeuze.
• Gebruik Ed25519 alleen als u de ondersteuning bij ontvangers begrijpt en kunt testen.
• Schakel niet uitsluitend naar Ed25519 omdat het DNS-record korter oogt.

Oude en nieuwe aanpak: DKIM op schaal beheren

De oude aanpak is handmatig TXT-records aanpassen, lange sleutels in verschillende registrarpanelen plakken en hopen dat niemand rotatie vergeet. De nieuwe aanpak maakt DNS- en ondertekeningsbeheer herhaalbaar en waar mogelijk gedelegeerd, zodat de levenscyclus van sleutels deel van het platformbeheer is.

Oude aanpak:

• Elk domein heeft een andere DNS-interface.
• Elke sleutelrotatie is een kalenderherinnering die iemand negeert.
• Een typefout bij een registrar verstoort de authenticatie voor een klant en blijft onopgemerkt tot aflevering terugloopt.

Nieuwe aanpak:

• Eén werkwijze voor veel domeinen.
• Beheerde SMTP verzorgt ondertekening volgens de gekozen configuratie.
• Minder terugkerend onderzoek naar lange TXT-records en afwijkende authenticatie.

TrekMail richt zich op hosting voor meerdere domeinen tegen vaste tarieven in plaats van per gebruiker. De beschreven functies omvatten gedeelde opslag, IMAP-mailboxen, ingebouwde IMAP-migratie, catch-all, doorsturing, BYO SMTP op Nano en beheerde SMTP op betaalde abonnementen. Beschikbaarheid hangt af van de voorwaarden. Werkt u met doorstuurregels, dan kunnen afwijkende authenticatieresultaten meespelen; lees ook domeinmail doorsturen naar Gmail.

Voor teams en bureaus zit de waarde niet in een wondermiddel voor DNS, maar in minder herhaald handwerk en beter inzicht. De vermelde startprijs voor Starter is $3.50 per maand; controleer actuele prijzen en facturering.

Tot slot: de DKIM-sleutel

Gebruik doorgaans RSA-2048, publiceer correct in DNS, controleer met echte lookups en roteer volgens een schema met selectors. Werkt u nog met 1024 bits, beoordeel dan een upgrade. Beschadigt het DNS-paneel lange TXT-waarden, verbeter de publicatiemethode of leg het beheer bij een platform dat dit ondersteunt.

Bekijk DKIM niet los van de rest. Een werkende sleutel is het nuttigst naast goed ingerichte SPF, DMARC en verzendinfrastructuur. Ga verder met vereiste DNS-records en e-mail maken met uw domein als u de volledige inrichting aanscherpt.