DKIM-sleutellengte: hoe kies je tussen 1024, 2048 en 4096?
door
Laatst bijgewerkt:
9 leestijd: 9 minuten
Belangrijkste Conclusies
- De DKIM-sleutellengte is het aantal bits van je RSA-ondertekeningssleutel. Langere sleutels bieden betere bescherming tegen vervalsing, maar zorgen voor grotere DNS-records die moeten worden gepubliceerd.
- 1024-bits RSA wordt in RFC 8301 afgeraden en voldoet niet aan de NIST-minimumvereisten, maar hostingpanelen zoals cPanel genereren deze nog steeds standaard.
- 2048-bits RSA is de juiste standaardinstelling voor 2026 en voldoet aan RFC 8301, NIST en de vereisten voor bulkverzenders van Google en Yahoo.
- Een openbare sleutel van 2048 bits overschrijdt de DNS TXT-limiet van 255 bytes, dus je moet deze opsplitsen in stukjes; anders mislukt de verificatie zonder dat er een foutmelding wordt gegeven.
- Als de chunking-stap wordt overgeslagen, leidt dit tot een onopgemerkte DKIM-fout: je e-mail wordt nog steeds verzonden, de logbestanden blijven in orde, maar de ontvangers wijzen de handtekening af.
- Wissel de sleutels om de 6 tot 12 maanden af met behulp van een parallelle selector, en gebruik Ed25519 uitsluitend in combinatie met RSA-2048 voor dubbele ondertekening, nooit op zichzelf.
Het bijwerken van je DKIM-sleutel zou de e-mailbeveiliging moeten verbeteren. In de praktijk leidt dit echter vaak tot authenticatiefouten als gevolg van een onjuiste DNS-configuratie.
Veel organisaties gebruiken nog steeds 1024-bit DKIM-sleutels zonder dat ze zich daarvan bewust zijn. Andere stappen over op 2048-bit om te voldoen aan de huidige beveiligingsaanbevelingen, om vervolgens te ontdekken dat grotere sleutels nieuwe publicatievereisten met zich meebrengen. Eén enkele fout bij het toevoegen van de openbare sleutel aan het DNS kan ervoor zorgen dat de DKIM-verificatie mislukt, terwijl e-mails gewoon blijven worden verzonden.
De uitdaging bestaat erin de juiste sleutellengte te kiezen, deze op de juiste manier te publiceren en deze in de loop van de tijd te onderhouden zonder de e-mailverificatie te verstoren.
In deze handleiding wordt uitgelegd hoe de lengte van een DKIM-sleutel van invloed is op de beveiliging, de afleverbaarheid en de naleving van regelgeving in 2026. U leert wat de verschillen zijn tussen sleutels van 1024-bit, 2048-bit, 4096-bit en Ed25519, hoe u uw huidige implementatie kunt controleren, hoe u veelvoorkomende fouten bij het publiceren van DNS-records kunt voorkomen en hoe u sleutels veilig kunt vernieuwen.
Wat is de lengte van een DKIM-sleutel?
De DKIM-sleutellengte is de grootte, in bits, van het RSA-sleutelpaar dat e-mails ondertekent en verifieert volgens de DKIM-standaard (RFC 6376). De privésleutel ondertekent elk uitgaand bericht op de mailserver, en de bijbehorende openbare sleutel staat in een DNS TXT-record, zodat ontvangende servers de handtekening kunnen verifiëren.
Langere sleutels zijn moeilijker te kraken. Een sleutel van 2048 bit is veel beter bestand tegen vervalsing dan een sleutel van 1024 bit. De sleutellengte is echter een afweging, die tegelijkertijd van invloed is op de cryptografische sterkte, de grootte van het DNS-record en de compatibiliteit met ontvangers.
De openbare sleutel wordt gepubliceerd onder een selector, het label (zoals selector1._domainkey.example.com) dat de ontvanger aangeeft welke sleutel hij moet gebruiken, aangezien één domein meerdere sleutels tegelijk kan gebruiken.
Vergelijking van de opties voor de lengte van DKIM-sleutels
Niet alle DKIM-sleutels zijn gelijk. Sommige zijn verouderd, andere voldoen aan de huidige standaard, en weer andere lossen het ene probleem op maar veroorzaken tegelijkertijd een ander. Hieronder zie je hoe 1024-bit, 2048-bit, 4096-bit en Ed25519 in de praktijk met elkaar vergeleken kunnen worden.
1024-bits RSA
1024-bits RSA was de oorspronkelijke DKIM-standaard en is nu de zwakste optie die nog is toegestaan. De standaarden zijn inmiddels verder gegaan. RFC 8301 (2018) stelt 1024 bits vast als de minimaal aanvaardbare sleutellengte, maar beveelt ten minste 2048 bits aan voor ondertekening. Het vereist ook dat verificatoren sleutels van minder dan 1024 bits als ongeldig behandelen.
NIST SP 800-131A Rev. 2 gaat nog een stap verder door RSA-sleutels van minder dan 2048 bits voor het genereren van digitale handtekeningen te verbieden en 1024-bits RSA te classificeren als cryptografie voor verouderd gebruik. De richtlijnen van Google voor afzenders accepteren nog steeds 1024-bits DKIM-sleutels als minimumvereiste voor bezorging via Gmail, maar bevelen 2048-bits sleutels aan voor betere beveiliging.
Ondanks alle aanbevelingen worden 1024-bits sleutels nog steeds veel gebruikt. Veel hostingpanelen en oudere e-mailplatforms genereren deze nog steeds standaard, waardoor organisaties onbewust met 1024-bit RSA blijven werken.
Een RSA-sleutel van 1024 bit voldoet niet aan de huidige cryptografische aanbevelingen; daarom zijn normalisatie-instanties en e-mailproviders overgestapt op implementaties met 2048 bit. Organisaties die nog steeds met 1024-bit DKIM werken, zijn echter over het algemeen beter af met het plannen en valideren van een gecontroleerde migratie dan met overhaaste wijzigingen die tot authenticatiefouten leiden.
2048-bits RSA
2048-bits RSA is de huidige DKIM-standaard. RFC 8301 beveelt RSA-sleutels van ten minste 2048 bits aan voor ondertekening, NIST SP 800-131A Rev. 2 classificeert RSA-sleutels van 2048 bits of meer als aanvaardbaar voor het genereren van digitale handtekeningen, en de richtlijnen voor afzenders van Google bevelen 2048-bits sleutels aan omwille van de veiligheid. Een 2048-bits sleutel voldoet aan de huidige eisen van de sector, providers en nalevingsinstanties.
De meeste DKIM-fouten waarbij 2048-bits sleutels betrokken zijn, zijn geen cryptografische fouten. Het zijn fouten bij het publiceren via DNS. Een openbare sleutel van 2048 bits is ongeveer 392 base64-tekens lang, terwijl een enkele DNS TXT-string beperkt is tot 255 bytes. De sleutel kan niet als één enkele string worden gepubliceerd. Deze moet worden opgesplitst in meerdere strings tussen aanhalingstekens binnen hetzelfde TXT-record, die DNS automatisch weer samenvoegt tijdens het opzoeken.
Als de sleutel onjuist is gepubliceerd, mislukt de DKIM-verificatie ook al lijkt het record te bestaan en blijft de mailserver berichten normaal ondertekenen.
4096-bits RSA
RSA met een sleutellengte van 4096 bits is de maximale sleutellengte die de meeste ontvangers zullen verifiëren. RFC 8301 schrijft voor dat verificatoren sleutels van 1024 tot 4096 bits moeten valideren en sleutels met een grotere lengte slechts optioneel, dus een sleutel die langer is dan 4096 bits loopt het risico helemaal niet te worden geverifieerd. PowerDMARC Hosted DKIM ondersteunt sleutellengtes tot 4096 bits.
Voor de meeste organisaties is 4096-bit overbodig. Het biedt geen noemenswaardige verbetering van de beveiliging ten opzichte van 2048-bit, dat al voldoet aan de minimumvereisten van NIST SP 800-131A Rev. 2 en aan de richtlijnen van Google voor afzenders, terwijl het een groter DNS-record oplevert en een kleine extra belasting met zich meebrengt tijdens de verificatie van de handtekening.
Gebruik 4096-bit uitsluitend in omgevingen met strenge beveiligingseisen of waar strenge regelgeving geldt, en waar een intern beleid of een auditor dit specifiek voorschrijft.
Ed25519 (Toekomstige koers)
Ed25519 is een DKIM-ondertekeningsalgoritme dat is gestandaardiseerd door RFC 8463 (2018). Het grootste voordeel ervan is de sleutelgrootte. Een openbare Ed25519-sleutel wordt gecodeerd tot een Base64-string van 44 octetten, waardoor het volledige DNS-sleutelrecord in één enkele TXT-string past. In tegenstelling tot RSA-2048 en RSA-4096 is het opsplitsen van DNS-records niet nodig en werkt het met systemen die geen TXT-records met meerdere strings kunnen publiceren. RFC 8463 beschrijft Ed25519 ook als een algoritme dat sterke cryptografische beveiliging biedt met aanzienlijk kortere sleutels dan RSA.
De uitdaging ligt in de acceptatie. RFC 8463 schrijft voor dat verificatiesystemen Ed25519-SHA256 moeten ondersteunen, maar beveelt alleen aan om ermee te ondertekenen. In de praktijk is de ondersteuning door e-mailplatforms, MTA’s en e-mailproviders nog steeds niet uniform. Een implementatie die uitsluitend op Ed25519 is gebaseerd, kan leiden tot hiaten in de DKIM-verificatie bij ontvangers die het algoritme niet ondersteunen.
Om die reden kan Ed25519 het beste in combinatie met RSA-2048 worden ingezet. RFC 8463 ondersteunt expliciet dubbele ondertekening, waardoor een bericht zowel een RSA-SHA256- als een Ed25519-SHA256-handtekening kan bevatten. Aangezien een selector slechts één openbare sleutel kan publiceren, moet elke handtekening een andere selector gebruiken, terwijl ze hetzelfde ondertekeningsdomein delen. Ontvangers verifiëren de handtekening die zij ondersteunen, wat compatibiliteit biedt en organisaties tegelijkertijd in staat stelt om Ed25519 in te voeren.
| Sleutellengte | Beveiligingsniveau | Grootte van DNS-records | Nalevingsstatus (2026) | Aanbevolen gebruik |
|---|---|---|---|---|
| 1024-bits RSA | Zwak, verouderd | Past in één TXT-string | Onder het NIST-minimum; volgens NIST uitsluitend voor gebruik in bestaande systemen; door Google aanvaard als absoluut minimum | Alleen voor verouderde systemen; plan een gecontroleerde migratie naar 2048-bit |
| 2048-bits RSA | Sterk; huidige norm | ~392 Base64-tekens; moet in meerdere tekenreeksen worden opgesplitst | Voldoet aan RFC 8301, NIST en de aanbevelingen van Google | Standaard voor vrijwel alle organisaties |
| 4096-bits RSA | Zeer sterk | Groter; moet worden opgesplitst; de meeste ontvangers zullen de grootste controleren | Overtuft de huidige eisen | Uitsluitend voor omgevingen met strenge beveiliging of gereguleerde omgevingen |
| Ed25519 | Krachtig algoritme, kortere sleutels dan bij RSA | 44 octetten; biedt ruimte voor één TXT-string, zonder opdeling in chunks | Gestandaardiseerd in RFC 8463; verificatoren MOETEN dit ondersteunen, ondertekenaars DIENEN dit te ondersteunen; ondersteuning door ontvangers is nog steeds ongelijkmatig | Dubbele ondertekening in combinatie met RSA-2048 |
Hoe u de lengte van uw huidige DKIM-sleutel kunt controleren
Controleer, voordat u een upgrade van de DKIM-sleutel plant, de sleutelgrootte die momenteel in DNS is gepubliceerd.
1. Bepaal je DKIM-selector
Open de koptekst van een ondertekende e-mail en zoek de DKIM-Signature veld. De waarde van het s= tag is uw selector. U kunt de selector ook vinden in de DKIM-configuratie-instellingen van uw e-mailprovider.
2. Zoek het DKIM-record op
Zoekopdracht selector._domainkey.uwdomein.com met behulp van een DKIM-opzoektool of DNS-querytool om het gepubliceerde TXT-record op te halen.
3. Controleer de openbare sleutel
Zoek de p= tag in het record. Deze bevat de openbare DKIM-sleutel. De meeste DKIM-opzoektools zullen automatisch de sleutellengte vaststellen en aangeven of deze 1024-bit, 2048-bit of een andere grootte heeft.
4. Evalueer het resultaat
Als het domein nog steeds een 1024-bits sleutel gebruikt, plan dan een migratie naar 2048-bits RSA. Als er al een 2048-bits sleutel is geïmplementeerd en deze correct functioneert, zijn er doorgaans geen onmiddellijke maatregelen nodig.
De PowerDMARC DKIM Checker haalt je gepubliceerde record op en detecteert automatisch de selector voor de belangrijkste providers, zodat je de lengte van je sleutel binnen enkele seconden kunt controleren in plaats van de base64-code handmatig te moeten decoderen. Probeer het gratis uit
Het 2048-bit DNS-chunkingprobleem (en hoe je dit kunt voorkomen)
Een van de meest voorkomende oorzaken van DKIM-fouten na een upgrade naar een 2048-bits sleutel is het onjuist publiceren van DNS-records.
Het probleem komt voort uit beperkingen van het DNS TXT-record . Een enkele TXT-string kan maximaal 255 bytes bevatten, terwijl een in base64 gecodeerde 2048-bits RSA-openbare sleutel doorgaans ongeveer 392 tekens lang is. Daardoor kan de sleutel niet als één enkele string worden gepubliceerd. Als een DNS-provider het record afkapt of de invoer weigert, mislukt de DKIM-verificatie.
| Component | Beperking |
|---|---|
| Enkele DNS-TXT-string | Maximaal 255 bytes |
| Typische openbare RSA-sleutel van 2048 bits | Ongeveer 392 Base64-tekens |
| Gevolg bij onjuiste publicatie | DKIM-verificatie mislukt |
Om een 2048-bits sleutel correct te publiceren, moet je de openbare sleutel opsplitsen in meerdere tekenreeksen tussen aanhalingstekens binnen hetzelfde TXT-record. DNS voegt de tekenreeksen automatisch samen tijdens het opzoeken.
selector1._domainkey.example.com. IN TXT (
“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1xN8s9k2”
“Qp7Yv3RwL0fHmZ2bKct5oXn8eW4uV1aA9dGqB6sT0pJrN3mC2hF7lYxoZ4kP1wIDAQAB”
)
De ondersteuning voor lange TXT-records verschilt per DNS-provider. Bij sommige platforms moeten beheerders meerdere tekenreeksen tussen aanhalingstekens handmatig invoeren, terwijl andere lange waarden automatisch opsplitsen en weer samenvoegen. Controleer altijd de vereisten van uw provider voor de opmaak van DNS-records voordat u een DKIM-sleutel publiceert.
Houd rekening met de volgende punten:
| Vereiste | Toelichting |
|---|---|
| Meerdere locaties | De sleutel kan op elk willekeurig punt worden opgesplitst. DNS voegt de reeksen automatisch weer samen tot één enkele waarde. |
| Lengte van de tekenreeks | Geen enkele afzonderlijke tekenreeks mag de DNS-limiet van 255 bytes overschrijden. |
| Validatie | Controleer het gepubliceerde DKIM-record nadat de DNS-wijzigingen zijn doorgevoerd en controleer of de volledige openbare sleutel wordt geretourneerd. |
| Problemen oplossen | Als het ondertekenen van e-mails wel lukt, maar ontvangers melden dat de DKIM-verificatie mislukt, controleer dan of de gepubliceerde openbare sleutel niet is afgekapt of dat er geen opmaakfouten in zitten. |
Controleer na het publiceren van een nieuwe DKIM-sleutel of het DNS-record correct is en ga na of de ontvangende servers de volledige openbare sleutel foutloos kunnen ophalen.
Wanneer en hoe moet je DKIM-sleutels rouleren?
Het rouleren van DKIM-sleutels vermindert het risico dat gepaard gaat met langdurige blootstelling van sleutels en is een veelvoorkomende vereiste in beveiligings- en nalevingsprogramma’s. Hoewel de DKIM-standaard geen universeel roulatieschema voorschrijft, rouleren veel organisaties hun ondertekeningssleutels om de 6 tot 12 maanden als onderdeel van hun routinematige beveiligingsonderhoud.
Bij een veilig DKIM-rotatieproces wordt een nieuwe selector ingevoerd voordat de bestaande wordt buiten gebruik gesteld. Dit zorgt ervoor dat de DKIM-validatie tijdens de overgang ononderbroken blijft.
- Stap 1: Genereer een nieuw DKIM-sleutelpaar en wijs er een nieuwe selector aan toe. Veel organisaties gebruiken selectornamen op basis van de datum om het bijhouden en controleren te vereenvoudigen.
- Stap 2: Publiceer de nieuwe openbare sleutel in DNS onder de nieuwe selector. Als u een 2048-bits RSA-sleutel gebruikt, zorg er dan voor dat het DNS-record correct wordt gepubliceerd.
- Stap 3: Wacht tot de DNS-propagatie is voltooid op basis van de TTL van het record.
- Stap 4: Werk de mailserver of e-mailserviceprovider bij, zodat berichten met de nieuwe selector worden ondertekend.
- Stap 5: Houd de vorige selector actief totdat berichten die met de oude sleutel zijn ondertekend, de normale bezorgpaden hebben doorlopen en de DNS-caches zijn verlopen.
- Stap 6: Verwijder de oude selector en het bijbehorende DNS-record zodra deze niet meer in gebruik is.
Door deze aanpak kunnen beide selectors tijdens de overgang naast elkaar bestaan, waardoor wordt voorkomen dat de DKIM-verificatie mislukt als gevolg van vertragingen bij de DNS-propagatie of records in de cache.
Voor organisaties die meerdere domeinen, selectors of e-maildiensten beheren, kan het lastig zijn om handmatige rotatie consequent te handhaven.
Vereisten voor de lengte van DKIM-sleutels per platform en nalevingskader
De vereisten voor de lengte van DKIM-sleutels verschillen per e-mailprovider, beveiligingsstandaard en nalevingskader. Sommige kaders leggen expliciete cryptografische vereisten vast, terwijl andere zich richten op bredere richtlijnen en best practices binnen de sector.
Nalevings- en leveranciersvereisten
| Kader / Aanbieder | Vereiste lengte van de DKIM-sleutel |
|---|---|
| Vereisten voor bulkverzenders van Google | Minimaal 1024-bit; 2048-bit aanbevolen |
| Vereisten voor afzenders op Yahoo | Over het algemeen in overeenstemming met de vereisten van Google voor afzenders |
| NIST SP 800-131A Rev. 2 | RSA-sleutels met minder dan 2048 bits zijn niet toegestaan voor het genereren van digitale handtekeningen |
| Omgevingen die onder de HIPAA-regelgeving vallen | Volg doorgaans de cryptografische richtlijnen van het NIST, waardoor 2048-bit RSA het praktische minimum is |
| FedRAMP-omgevingen | Voldoen aan de cryptografische normen van het NIST en de goedgekeurde sleutellengtes |
| PCI DSS-omgevingen | Er gelden geen specifieke vereisten voor de sleutellengte bij DKIM, maar organisaties volgen doorgaans cryptografische praktijken die in overeenstemming zijn met de NIST-richtlijnen |
Platformondersteuning en standaardinstellingen
| Platform | Overwegingen met betrekking tot de lengte van de DKIM-sleutel |
|---|---|
| cPanel | In sommige configuraties worden standaard 1024-bits DKIM-sleutels gebruikt. Controleer de lengte van de gepubliceerde sleutel voordat u ervan uitgaat dat aan de vereisten wordt voldaan. |
| Microsoft Exchange 2013/2016 | De ondersteuning voor sleutellengtes en de standaardinstellingen kunnen variëren, afhankelijk van de implementatiemethode en de DKIM-implementatie. |
| Google Werkruimte | Ondersteunt 2048-bits DKIM-sleutels standaard. |
| Microsoft 365 | Ondersteunt 2048-bits DKIM-sleutels standaard. |
| Moderne cloud-e-mailplatforms | Ondersteunt in het algemeen de implementatie van 2048-bits DKIM zonder dat er aanvullende configuratievereisten nodig zijn. |
Bij alle grote e-mailproviders, beveiligingskaders en bedrijfsomgevingen blijft een RSA-sleutellengte van 2048 bits de aanbevolen lengte voor DKIM-sleutels. Deze lengte voldoet aan de huidige beveiligingsrichtlijnen, brede compatibiliteitseisen en nalevingsverwachtingen, terwijl de implementatieproblemen die gepaard gaan met langere RSA-sleutels worden vermeden.
Hoe genereer je een DKIM-sleutel van 2048 bits?
Het genereren van een DKIM-sleutelpaar van 2048 bits kan worden gedaan met behulp van een tool voor het genereren van DKIM-sleutels of rechtstreeks via de opdrachtregel.
Methode 1: Gebruik een DKIM-sleutelgenerator
De PowerDMARC DKIM-generator genereert een DKIM-sleutelpaar van 2048 bits en levert de openbare sleutel in een DNS-compatibel formaat, samen met de bijbehorende privésleutel voor uw mailserver of e-mailplatform.
Methode 2: Een sleutelpaar genereren met OpenSSL
# Een privésleutel van 2048 bits genereren
openssl genrsa -out dkim_private.key 2048
# De bijbehorende openbare sleutel uitpakken
openssl rsa -in dkim_private.key -pubout -out dkim_public.key
Houd u na het genereren van het sleutelpaar aan de volgende aanbevelingen:
| Aanbeveling | Details |
|---|---|
| Gebruik een beschrijvende selector | Op datum gebaseerde selectors, zoals 20260101 of jan2026, vereenvoudigen het sleutelbeheer en het bijhouden van de rotatie. |
| Bewaar de privésleutel veilig | Sla de privésleutel uitsluitend op het systeem op dat verantwoordelijk is voor het ondertekenen met DKIM. Deze mag nooit in DNS worden gepubliceerd of openbaar worden gedeeld. |
| Publiceer de openbare sleutel in DNS | Voeg de openbare sleutel toe aan het betreffende selector._domainkey TXT-record. |
| Controleer de DNS-opmaak | Als u een RSA-sleutel van 2048 bits gebruikt, zorg er dan voor dat de openbare sleutel correct wordt gepubliceerd en voldoet aan de lengtebeperkingen voor DNS TXT-records. |
| Test vóór de implementatie | Controleer of het DKIM-record openbaar toegankelijk is en of berichten die met de nieuwe selector zijn ondertekend, de DKIM-validatie doorstaan. |
Zodra de sleutel is gepubliceerd en de DNS-propagatie is voltooid, moet u uw e-mailplatform bijwerken om berichten met de nieuwe selector te gaan ondertekenen.
De lengte van DKIM-sleutels correct beheren in 2026
Een correct gegenereerde, gepubliceerde en onderhouden 2048-bits sleutel biedt een betere bescherming tegen vervalsing zonder dat dit tot bezorgingsproblemen leidt. Een onjuist gepubliceerde sleutel kan echter de DKIM-verificatie ongeldig maken, ongeacht de cryptografische sterkte ervan.
Controleer uw huidige DKIM-implementatie voordat u wijzigingen aanbrengt. Als u nog steeds een 1024-bits sleutel gebruikt, plan dan een gecontroleerde migratie naar 2048-bits RSA. Als u al 2048-bits gebruikt, controleer dan de configuratie van uw DNS-records, stel een procedure voor sleutelrotatie op en houd de authenticatieresultaten regelmatig in de gaten.
Een sterke e-mailverificatie hangt niet alleen af van de keuze van de juiste sleutellengte. Het hangt af van het correct beheren van de gehele DKIM-levenscyclus, van het genereren van sleutels en het publiceren ervan in DNS tot het rouleren ervan en de voortdurende validatie.
FAQs
Eist Google in 2026 2048-bits DKIM?
De regels van Google voor bulkverzenders accepteren minimaal 1024-bit, maar raden 2048-bit ten zeerste aan. Aangezien het NIST 1024-bit RSA niet toestaat voor het genereren van digitale handtekeningen, is 2048-bit de praktische standaard, ongeacht de beperking van Google.
Wat gebeurt er als ik een DKIM-sleutel van 1024 bits gebruik?
Uw e-mail wordt nog steeds geauthenticeerd bij ontvangers die 1024-bit accepteren, waaronder Gmail. Maar het voldoet niet aan de door NIST vastgestelde minimumvereiste van 2048-bit, kan bij nalevingscontroles worden afgekeurd en kan door aanvallers met voldoende middelen worden gekraakt.
Hoe splits ik een DKIM-sleutel van 2048 bits in DNS?
Een openbare sleutel van 2048 bits (~392 tekens) overschrijdt de limiet van 255 bytes voor TXT-strings, dus moet je deze opsplitsen in strings tussen aanhalingstekens binnen hetzelfde TXT-record. DNS voegt deze automatisch samen. Controleer dit na publicatie met een DKIM-opzoektool.
Wordt Ed25519 DKIM ondersteund door Gmail en Outlook?
De ondersteuning wordt beter, maar is in 2026 nog niet overal even goed bij ontvangers en ESP’s. Sluit geen overeenkomst af met alleen Ed25519. Sluit een dubbele overeenkomst af met RSA-2048 en Ed25519, zodat ontvangers die Ed25519 niet ondersteunen, kunnen terugvallen op RSA.
Hoe vaak moeten DKIM-sleutels worden vernieuwd?
Om de 6 tot 12 maanden wordt algemeen als de beste werkwijze beschouwd. Gebruik een methode met parallelle selectie, zodat een oude sleutel geldig blijft totdat de nieuwe is doorgevoerd, waardoor e-mail tijdens de overgang ondertekend blijft.
Content-specialist bij PowerDMARC
Milena is een ervaren schrijfster en content creator met meer dan 7 jaar ervaring in het creëren van boeiende content over IT, cyberbeveiliging, virtuele evenementen en meer. Ze heeft bewezen werk van hoge kwaliteit af te leveren voor internationale tijdschriften en is afgestudeerd aan prestigieuze instellingen zoals New York University Abu Dhabi, UWC China en het Europacollege.
Laatste berichten van Milena Baghdasaryan (Bekijk alle berichten)
