DKIM|externe leveranciers
Als een leverancier namens jou mail ondertekent maar geen controle heeft over jouw DNS-zone, hoef je niet je DKIM private key uit handen te geven om het ondertekenen werkend te houden: DNS laat je alleen de public key delegeren, terwijl jij zelf de CNAME-verwijzing (en de mogelijkheid om die om te leiden) in handen houdt.
Waarom dit belangrijk is
Een DKIM-ondertekeningsgateway heeft zijn public key nodig, gepubliceerd onder de DNS-zone van jouw domein, bij de selector waarmee de gateway ondertekent. Heeft de gateway-operator geen directe toegang tot jouw DNS, dan zou je anders telkens handmatig hun public key naar je eigen zone moeten kopiëren zodra ze roteren. Een CNAME-verwijzing voorkomt dat: hij laat jouw selector verwijzen naar een record dat de gateway-operator zelf beheert, zodat zij sleutels op hun eigen schema kunnen roteren zonder ooit toegang tot jouw DNS nodig te hebben.
Hoe het werkt
Richt een CNAME-record in voor je DKIM-selector dat verwijst naar een hostname die de gateway-operator zelf beheert in hun eigen DNS-zone. De gateway-operator publiceert vervolgens de daadwerkelijke DKIM public key (als TXT-record) op die hostname. Omdat de CNAME van jouw selector daar simpelweg naartoe wijst, gaat elke rotatie die de gateway uitvoert automatisch in, zonder dat jij verdere DNS-wijzigingen hoeft door te voeren.
Goed om te weten
Dit is hetzelfde CNAME-delegatiepatroon dat kort aan bod komt in DKIM | richtlijnen; dit artikel behandelt het volledig uitgewerkte voorbeeld.
Uitgewerkt voorbeeld
Stel dat Sample Corp (sample.com) een e-mailgatewaydienst inhuurt, Example Net (example.net), om haar nieuwsbrieven te versturen en met DKIM te ondertekenen. DKIM werkt door een klein stukje verificatiegegevens in DNS te publiceren (het adresboek van internet), zodat mailboxproviders zoals Gmail kunnen controleren of de handtekening van een bericht echt is.
In plaats van dat Sample Corp die verificatiegegevens telkens handmatig in haar eigen DNS moet kopiëren zodra Example Net ze bijwerkt, richt Sample Corp in plaats daarvan een doorverwijzing in (een CNAME) die altijd verwijst naar waar Example Net haar gegevens op dat moment publiceert. Zo volgt de DNS van Sample Corp automatisch mee zodra Example Net haar sleutels wijzigt, zonder dat Sample Corp daar zelf iets voor hoeft te doen. Sample Corp houdt de eigendom van die doorverwijzing en kan hem op elk moment ergens anders naartoe laten wijzen, terwijl het dagelijkse sleutelbeheer bij Example Net blijft.
In de praktijk worden meestal twee van zulke doorverwijzingen naast elkaar ingericht, zodat Example Net soepel van een oude naar een nieuwe sleutel kan overschakelen, zonder downtime.
Ter referentie, dit zijn de daadwerkelijke DNS-records:
- In de DNS van
sample.com:<vendor>-selector1._domainkey.sample.com(CNAME) →sample-com-selector1.dkim.example.net - In de DNS van
sample.com:<vendor>-selector2._domainkey.sample.com(CNAME) →sample-com-selector2.dkim.example.net - In de DNS van
example.net:sample-com-selector1.dkim.example.net(TXT) →v=DKIM1; k=rsa; p=<...>; n=<sleutelgrootte>,<publicatiedatum> - In de DNS van
example.net:sample-com-selector2.dkim.example.net(TXT) →v=DKIM1; k=rsa; p=<...>; n=<sleutelgrootte>,<publicatiedatum>
Hiermee beheert de gateway-operator het DKIM-sleutelbeheer volledig zelf, inclusief rotatie, zonder dat de klant ooit verdere DNS-wijzigingen hoeft door te voeren.
Bronnen & verder lezen
- RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures: rfc-editor.org/rfc/rfc6376, aangevuld met RFC 8301 en RFC 8463.
- M3AAWG DKIM Key Rotation Best Common Practices, en de M3AAWG best practices voor het implementeren van DKIM ter voorkoming van kwetsbaarheden door sleutellengte.