gids · DKIM instellen

Hoe stelt een productteam DKIM veilig in?

Stel DKIM in door een ondertekenend domein te kiezen dat eigendom is van je organisatie en een unieke selector per provider of ondertekeningssysteem, het sleutelpaar in een beschermde service te genereren, alleen de publieke sleutel te publiceren op selector._domainkey.example.com en het werkelijke uitgaande pad zo te configureren dat elk bedoeld bericht wordt ondertekend. Verifieer de handtekening tegen de oorspronkelijke bytes van het bericht vanuit een externe mailbox, controleer dat het d=-domein gealigned is met het zichtbare From-domein als DMARC daarvan afhangt, en rol daarna geleidelijk uit. Documenteer eigenaarschap van selectors, rotatie, intrekking en rollback voordat het productieverkeer overgaat.

Breng elk echt uitgaand pad in kaart voordat je een sleutel genereert

Begin met een inventaris, niet met een DNS-record. Maak een lijst van elk systeem dat e-mail kan uitsturen met de zichtbare From-domeinen van de organisatie: applicatieworkers, transactionele providers, marketingplatforms, supporttools, identiteitssystemen, ticketsoftware, relays en noodpaden. Leg voor elk systeem de eigenaar, berichtklassen, envelope-afzender, zichtbare From-domein, huidige DKIM d=-domein, selector, ondertekeningscomponent en de vraag vast of een andere relay het bericht daarna wijzigt. Een voor één provider gepubliceerde DKIM-sleutel doet niets voor een ander pad dat de privésleutel nooit gebruikt. Evenzo bewijst een generiek providerdashboard dat één geverifieerd domein toont niet dat elke tenant, regio, stream, template of fallback is ondertekend. Gebruik gecontroleerde voorbeelden uit elk pad en bewaar de oorspronkelijke headers. Bepaal welke paden zijn geautoriseerd voordat je ondertekening inschakelt; DKIM authenticeert de verantwoordelijkheid van een domein voor een handtekening, niet de toestemming van de ontvanger of de juistheid van de berichtinhoud.

Kies een ondertekenend domein dat DMARC-alignment ondersteunt

De DKIM-tag d= geeft het ondertekenende domein aan. Kies een domein dat je organisatie beheert en gedurende de hele levensduur van de mailstream kan blijven beheren. Als DMARC op DKIM gaat leunen, moet het d=-domein gealigned zijn met het domein in het zichtbare RFC 5322 From-veld volgens de geldende relaxed- of strict-alignmentregel. Een ondertekenend domein van de provider kan een geldig DKIM-resultaat opleveren en toch niet gealigned zijn met het From-domein van je organisatie. Bepaal of het apexdomein of een subdomein met een specifiek doel elke stream moet ondertekenen, rekening houdend met eigenaarschap, scheiding van reputatie, gedelegeerde DNS en isolatie bij incidenten. Verzin geen extra domeinen alleen om een reputatie- of beleidsprobleem te omzeilen. Leg de relatie met het organisatiedomein en de beoogde DMARC-modus vast. Test de alignment aan de hand van de uiteindelijk ontvangen headers; leid haar nooit alleen af uit een selectorlookup, want het bericht kan een andere d=-waarde gebruiken.

Wijs selectors toe als operationele identiteiten

Met een selector kan een domein meerdere sleutels publiceren en deze wijzigen zonder één globaal record te vervangen. Maak een deterministisch selectorbeleid dat een provider of ondertekenaar en een rotatiegeneratie identificeert zonder geheimen te lekken. Bijvoorbeeld: product-a-2026q3 kan duidelijker zijn dan default, maar houd namen binnen DNS-conventies en de limieten van je tooling. Hergebruik nooit één privésleutel voor niet-gerelateerde providers, omgevingen of tenants alleen om DNS-records te beperken. Houd een register bij met selector, d=-domein, doel, ondertekeningsdienst, eigenaar, aanmaaktijd, algoritme, fingerprint van de openbare sleutel, uitrolstatus, rotatiedeadline en bewijs van uitfasering. Controleer vóór publicatie de exacte selectornaam: de lookup is `selector._domainkey.signing-domain`. Een onbedoeld record op het zichtbare From-domein, return-path-domein of in de verkeerde DNS-zone verifieert de bedoelde handtekening niet. Verwijder een oude selector pas nadat vertraagde e-mail en daarmee ondertekende retries zijn verlopen.

Genereer en bescherm de private sleutel

Genereer het sleutelpaar in een beheerde sleutelservice of een strak gecontroleerd ondertekeningssysteem als de provider dat ondersteunt. De private sleutel mag nooit terechtkomen in openbare DNS, versiebeheer, browsercode, CI-output, analytics, gewone logs, tickets, documenten, prompts of gedeelde chats. Geef alleen het mailonderdeel dat de sleutel nodig heeft toegang om te ondertekenen, scheid productie van lagere omgevingen en leg beheerderstoegang vast. RFC 8301 werkt de cryptografische eisen van DKIM bij en stelt dat ondertekenaars RSA-sleutels van minstens 1024 bits moeten gebruiken en er minstens 2048 bits zouden moeten gebruiken; de RFC wijst ook op operationele DNS-beperkingen bij grotere sleutels. Volg de actuele mogelijkheden en aanbevelingen van de gekozen ondertekenaar en de ontvangers die je bereikt, in plaats van een verouderd voorbeeld te kopiëren. Als je Ed25519 overweegt: RFC 8463 definieert het gebruik ervan in DKIM, maar de interoperabiliteit moet worden getest en waar nodig moet een compatibele handtekeningstrategie behouden blijven. Rotatie moet mogelijk zijn zonder de private sleutel te exporteren.

Publiceer de publieke sleutel nauwkeurig

Publiceer een TXT-record op de exacte eigenaarnaam `selector._domainkey.signing-domain`. Het DKIM-sleutelrecord bevat tags zoals v=DKIM1, indien nodig een sleuteltype en p= met het materiaal van de openbare sleutel zonder privésleutelwrappers. Volg de exacte recordindeling van de ondertekenaar en het gedrag van je DNS-provider rond aanhalingstekens. Controleer vóór het opslaan of de DNS-interface de zone automatisch toevoegt, lange strings splitst of tekens escapt. Vraag na publicatie de gezaghebbende nameservers rechtstreeks op, vraag daarna onafhankelijke recursieve resolvers op en reconstrueer de volledige TXT-waarde. Meerdere tekenstrings in één TXT-record worden door DNS-clients samengevoegd, terwijl meerdere concurrerende resource records dubbelzinnigheid kunnen veroorzaken. Bewaar het vorige antwoord en de TTL voor terugdraaien. Verlaag de beveiliging niet door een bredere sleutel te publiceren of een testflag in productie te laten staan alleen om een checker stil te krijgen. Een zichtbaar record bewijst DNS-publicatie, niet dat de afzender de bijpassende privésleutel gebruikt.

Configureer de laatste ondertekenaar en de ondertekende velden

Configureer het onderdeel dat het uiteindelijke bericht aan het uitgaande transport overdraagt, of zorg dat geen later onderdeel ondertekende content wijzigt. Een DKIM-handtekening dekt een body-hash en de headervelden die in h= staan. RFC 6376 vereist dat het From-headerveld wordt ondertekend voor een geldige handtekening. Neem headers op die voor je product belangrijk zijn voor de identiteit, begrijp hoe herhaalde headers worden geselecteerd en vermijd het ondertekenen van velden die een noodzakelijk systeem verderop moet herschrijven, tenzij die transformatie gecontroleerd verloopt. Kies de canonicalisatie bewust. Relaxed canonicalisatie tolereert gedefinieerde wijzigingen in witruimte en headeropmaak, maar staat geen willekeurige wijzigingen in de body toe. Simple canonicalisatie is kwetsbaarder. Ingevoegde footers, herschreven links, gewijzigde MIME-boundaries, conversie van transfer encoding, onderwerptags en normalisatie van regeleinden na ondertekening kunnen de verificatie breken. Onderteken het volledig gerenderde bericht na goedgekeurde transformaties, en voorkom dat onbetrouwbare gebruikers d=, s=, headerlijsten of sleutels kunnen kiezen.

Verifieer originele ontvangen berichten van begin tot eind

Stuur gecontroleerde berichten via elk echt pad dat op productie lijkt naar externe testmailboxen die het team beheert. Bewaar het ruwe originele bericht, niet een gekopieerde body of een opnieuw geserialiseerde ticketbijlage. Bekijk de d=- en s=-waarden in DKIM-Signature, de lijst met ondertekende headers, de body-hash, het algoritme, de canonicalisatie, het tijdstempel en een eventuele vervaldatum. Vraag de publieke sleutel op vanaf een onafhankelijk netwerk en voer een verifier die de standaarden kent uit op de originele bytes. Vergelijk de Authentication-Results-header van de vertrouwde ontvanger met je eigen verifier, met inachtneming van de vertrouwensgrenzen uit RFC 8601. Test platte tekst, multipart alternative, verwachte bijlagen, onderwerpen met Unicode, lange headers, templates, trackingtransformaties, retries en relaypaden. Negatieve tests moeten een bewust gewijzigde ondertekende header in een fixture omvatten, een ontbrekende selector, een verlopen of uitgefaseerde selector en een pad dat ondertekening overslaat. Knoei nooit met echte klantmail om een test te maken.

Beoordeel DKIM, DMARC en bezorging als afzonderlijke resultaten

Een DKIM-pass betekent dat de verificateur een geldige handtekening vond voor het geïdentificeerde ondertekenende domein over de ondertekende velden en body. Dit authenticeert niet elke niet-ondertekende header, bevestigt geen menselijke auteur, bewijst geen toestemming van de ontvanger, waarborgt geen wettelijke compliance en garandeert geen acceptatie of inboxplaatsing. DMARC evalueert afzonderlijk of een passerend DKIM- of SPF-domein is gealigned met het zichtbare From-domein en past het beleid van de domeineigenaar toe. Leg voor gecontroleerde tests ten minste het DKIM-resultaat en de reden, d=-domein, selector, zichtbare From-domein, alignmentresultaat, SPF-resultaat, DMARC-resultaat, ontvanger en tijdstempel vast. Houd volledige ontvangeradressen en inhoud buiten routinematige metrics. SMTP-provideracceptatie, acceptatie door de ontvangende server, latere bounce, plaatsing in een mailboxmap en engagement zijn latere statussen. Als DKIM slaagt maar e-mail wordt geweigerd of gefilterd, onderzoek dan DMARC-alignment, SPF, IP- en domeinreputatie, klachtpercentage, berichtbeleid, snelheid en richtlijnen van de ontvanger in plaats van herhaaldelijk sleutels te roteren.

Roteer zonder een gat in de verificatie

Gebruik overlappende selectors. Genereer eerst een nieuwe beschermde sleutel en publiceer het publieke record onder een nieuwe selector. Controleer gezaghebbende en recursieve DNS, stel de ondertekenaar in op de nieuwe selector en stuur gecontroleerde tests via elk pad. Monitor welk deel van de handtekeningen de oude en de nieuwe selector gebruikt en wat hun verificatieresultaten zijn. Houd de oude publieke sleutel beschikbaar gedurende de maximale leeftijd van berichten in de wachtrij, het retryvenster en de DNS-cacheperiode, plus een expliciete veiligheidsmarge. Stop daarna alle ondertekening met de oude selector, controleer dat geen actieve configuratie er nog naar verwijst en faseer het record uit volgens je beleid. Een noodintrekking na blootstelling van de private sleutel kan snellere verwijdering, het pauzeren van verkeer, rotatie van providercredentials en communicatie over het incident vereisen; documenteer die afweging vooraf. Overschrijf bij routinematige rotatie niet één selector ter plekke, want gecachete oude publieke sleutels kunnen de verificatie laten falen voor berichten die met de nieuwe private sleutel zijn ondertekend.

Analyseer fouten vanuit de handtekening naar buiten

Stel bij een ontbrekende handtekening vast of het bericht een niet-ondertekende stream, een niet-geautoriseerd From-domein, een fallback-relay of een ander templatepad heeft gebruikt. Controleer bij key-not-found de exacte lookup van s= en d=, de delegatie van de zone, het gezaghebbende antwoord, DNSSEC- of resolverfouten en de propagatie. Vergelijk bij een afwijkende body-hash de ruwe MIME van vóór het ondertekenen met die van het ontvangen bericht om transformaties na ondertekening te vinden. Controleer bij een afwijkende handtekening of de gepubliceerde publieke sleutel overeenkomt met de actieve private sleutel en bekijk de canonicalisatie en de ondertekende headers. Beoordeel bij een DKIM-pass met een DMARC-fail de alignment met het zichtbare From-domein. Classificeer tijdelijke fouten bij DNS-lookups apart van blijvende configuratiefouten, en gebruik begrensde transport-retries alleen als de SMTP-respons tijdelijk is. Pauzeer de betreffende stream bij ondertekening over domeinen heen, onbekende sleutels, wijdverbreide verificatiefouten of een vermoedelijk gelekte sleutel. Bewaar bewijs met zo min mogelijk persoonsgegevens en wijzig per gecontroleerde hertest één variabele.

Gebruik de DKIM-documentatie van je verzendsysteem

Stel DKIM in op de daadwerkelijke verzendsystemen en DNS-autoriteit, valideer oorspronkelijke ontvangen berichten en vertrouw op actuele IETF-standaarden en providerspecifieke documentatie.

Veelgestelde vragen

Waar wordt een publieke DKIM-sleutel gepubliceerd?

Publiceer hem als TXT-record op selector._domainkey.signing-domain, met exact de selector en het d=-domein die de uitgaande handtekening zal bevatten.

Hoort een private DKIM-sleutel in DNS thuis?

Nee. DNS bevat alleen materiaal van de publieke sleutel. Bewaar de private sleutel binnen een beheerde ondertekenaar of afgeschermde secretomgeving, met nauw afgebakende toegang en rotatiecontroles.

Kun je één DKIM-selector hergebruiken voor elke e-mailprovider?

Vermijd dat ontwerp. Scheid selectors en private sleutels per provider, ondertekenaar, omgeving of risicogrens, zodat rotatie en compromittering geen gevolgen hebben voor paden die er niets mee te maken hebben.

Betekent een DKIM-pass dat DMARC slaagt?

Niet per se. DMARC vereist dat het geslaagde DKIM d=-domein gealigned is met het zichtbare From-domein, tenzij een gealignde SPF-pass in plaats daarvan aan DMARC voldoet.

Waarom faalt DKIM na een footer of herschreven trackinglinks?

DKIM dekt geselecteerde headers en een body-hash. Een wijziging verderop die buiten de gekozen canonicalisatieregels valt, kan de handtekening ongeldig maken nadat die is aangemaakt.

Hoe roteer je DKIM-sleutels?

Publiceer en verifieer eerst een nieuwe selector, schakel gecontroleerde ondertekening daarop over, monitor de resultaten, houd de oude publieke sleutel aan gedurende de retry- en cachevensters en faseer hem daarna uit.

Bepaalt DKIM de inboxplaatsing?

Nee. DKIM levert afgebakend bewijs van een domeinhandtekening. Ontvangers beoordelen daarnaast zelfstandig DMARC, SPF, reputatie, klachten, content, verzendsnelheden en mailboxbeleid voordat ze over de bezorging beslissen.

Begin met een inventaris, niet met een DNS-record. Maak een lijst van elk systeem dat e-mail kan uitsturen met de zichtbare From-domeinen van de organisatie: applicatieworkers, transactionele providers, marketingplatforms, supporttools, identiteitssystemen, ticketsoftware, relays en noodpaden. Leg voor elk systeem het volgende vast: de eigenaar, berichtklassen, envelope-afzender, zichtbare From-domein, huidige DKIM d=-domein, selector, ondertekeningscomponent en of een andere relay het bericht daarna wijzigt. Een voor één provider gepubliceerde DKIM-sleutel doet niets voor een ander pad dat de privésleutel nooit gebruikt. Evenzo bewijst een generiek providerdashboard dat één geverifieerd domein toont niet dat elke tenant, regio, stream, template of fallback is ondertekend. Gebruik gecontroleerde voorbeelden uit elk pad en bewaar de oorspronkelijke headers. Bepaal welke paden zijn geautoriseerd voordat je ondertekening inschakelt; DKIM authenticeert de verantwoordelijkheid van een domein voor een handtekening, niet de toestemming van de ontvanger of de juistheid van de berichtinhoud.

Nee. Valideer oorspronkelijke ontvangen berichten tegen de gepubliceerde sleutel en bevestig de d=- en s=-waarden in de DKIM-Signature-header.

Bronnen

Verder leren

DKIM controleren voor applicatiemailControleer DKIM door een echte handtekening te inspecteren, de selector en het domein op te vragen, het bericht te verifiëren, de resultaten van de ontvanger te lezen en de alignment te testen.Een DMARC-check uitvoeren voor applicatiemailControleer de vindbaarheid en syntaxis van je DMARC-record, SPF- en DKIM-alignment, beleid, rapporten en echte applicatieberichten, zonder een DNS-lookup te verwarren met bezorging.Een SPF-record controleren voor applicatiemailControleer het juiste SPF-domein, de syntaxis, mechanismen, het geneste DNS-budget, de autorisatie van bron-IP's, het resultaat en de DMARC-alignment voor applicatiemail.Een deliverabilityservice voor e-mail beoordelenBeoordeel deliverabilityservices voor e-mail op scope, bewijs, authenticatie, feedbackloops, suppressies, privacy, overdraagbaarheid en operationele fit.SMTP als mailprotocol: hoe applicatiemail zich verplaatstLeer hoe SMTP-submission, relay, envelopes, responscodes, TLS, retries en berichtinhoud de e-mailworkflow van een applicatie bepalen.