DKIM-recordgenerator: sleutels maken en DNS instellen

Zoekt u een DKIM-recordgenerator omdat Gmail of Google Postmaster Tools authenticatiefouten meldt? Controleer eerst de basisconfiguratie. Onze handleiding voor e-mail met uw eigen domein behandelt MX, SPF, DKIM, DMARC en DNS-fouten die de aflevering kunnen verstoren.

Wat veel webtools onvoldoende uitleggen: DKIM bestaat uit een openbare sleutel in DNS en een privésleutel op het systeem dat berichten ondertekent. Laat een website beide maken, dan kan die dienst toegang tot uw privésleutel hebben gehad. Controleer of de generatie aantoonbaar lokaal in uw browser plaatsvindt. De sleutel geeft de mogelijkheid namens uw domein te ondertekenen; zij bewijst niet zelfstandig de zichtbare afzenderidentiteit.

Deze gids beschrijft geschikte manieren om in 2025-2026 een DKIM-recordgenerator te gebruiken: maak sleutels lokaal met OpenSSL voor uw eigen mailserver, of volg de DKIM-instructies van uw werkelijke verzendprovider, zoals TrekMail, Amazon SES, SendGrid, Mailgun of Google Workspace.

Wat is een DKIM-recordgenerator?

Een DKIM-recordgenerator levert de DNS-gegevens voor DomainKeys Identified Mail. Dat kan een RSA-sleutelpaar voor een TXT-record zijn, of door een provider aangeleverde CNAME-records die verwijzen naar de openbare DKIM-sleutel op een andere hostnaam. Niet iedere provider gebruikt CNAME.

DKIM ondertekent uitgaande mail met een privésleutel. Ontvangende servers halen de bijbehorende openbare sleutel uit DNS en controleren de handtekening. Daarmee verifiëren ze een handtekening namens het ondertekenende domein en de integriteit van de ondertekende delen volgens de toegepaste canonicalisatie.

Volgens RFC 8301 moeten ondertekenaars voor RSA-handtekeningen rsa-sha256 gebruiken en RSA-sleutels van minimaal 1024 bits; minimaal 2048 bits wordt aanbevolen. Daarom hoort een passende DKIM-recordgenerator RSA 2048 als uitgangspunt te nemen, niet 1024.

Waarom onbekende webgeneratoren risico's opleveren

Een webdienst voor DKIM-sleutels verdient alleen vertrouwen als u weet waar de privésleutel ontstaat en wie er toegang toe krijgt. Controleerbare generatie uitsluitend aan de clientzijde kan blootstelling aan de dienst beperken. Bij onbekende tools is dat niet vanzelfsprekend. Een gelekte sleutel kan misbruik van domeinhandtekeningen mogelijk maken.

DKIM is meer dan het opmaken van een DNS-record: het gaat om cryptografische ondertekening namens een domein. Bewaar de privésleutel alleen waar zij voor het ondertekenen nodig is en bescherm de toegang. Als een derde partij haar genereert, logt of opslaat, kan die partij mogelijk later namens het domein ondertekenen.

De openbare sleutel hoort in DNS; de privésleutel op het ondertekenende systeem. Levert een webformulier beide, controleer dan waar de privésleutel is gemaakt en of de dienst er toegang toe had.

Dat is een belangrijke toets voor iedere DKIM-recordgenerator: waar is de privésleutel gemaakt en wie kon erbij? Een onbekende website is geen voldoende onderbouwing om de sleutel voor productiemail te gebruiken.

Lokaal sleutels maken met OpenSSL

OpenSSL op uw eigen computer of ondertekenende server kan de blootstelling van privésleutels aan webdiensten beperken. Het is een bruikbare DKIM-recordgenerator als u de host, bestandsrechten en toegang goed beheert; lokaal genereren is op zichzelf geen veiligheidsgarantie.

Deze aanpak past bij een eigen omgeving met Postfix, Exim, Exchange, OpenDKIM of vergelijkbare software. Genereer de sleutel lokaal, installeer de privésleutel op de ondertekenende host en publiceer uitsluitend de openbare sleutel in DNS.

Maak een RSA-sleutelpaar van 2048 bits:

openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

Het bestand public.key ziet er ongeveer zo uit; de verkorte voorbeeldtekst is geen bruikbare sleutel:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr...
-----END PUBLIC KEY-----

Maak het vervolgens geschikt voor DNS:

1. Verwijder de regels BEGIN PUBLIC KEY en END PUBLIC KEY.
2. Verwijder alle regelafbrekingen.
3. Voeg de DKIM-tags toe.

Een handmatig TXT-record heeft doorgaans deze vorm; vervang de voorbeeldtekst door uw volledige openbare sleutel:

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."

Alleen de sleuteltekst is niet genoeg. Een DKIM-recordgenerator vermeldt vaak v=DKIM1; die tag is optioneel, maar moet bij gebruik als eerste staan. De tag p= is verplicht. Er zijn ook optionele tags, zoals s=email en t=s, maar die zijn meestal niet nodig voor een basisconfiguratie.

De DNS-valkuil van 255 octetten per tekenreeks

DNS stelt grenzen aan de afzonderlijke tekenreeksen van een TXT-record. De uitvoer van een DKIM-recordgenerator kan daardoor te lang zijn voor een ongeschikt invoerveld. Een RSA-openbare sleutel van 2048 bits moet soms worden verdeeld over meerdere aangehaalde tekenreeksen binnen hetzelfde record.

Een verouderd DNS-paneel kan een record afwijzen, afkappen of slechts deels opslaan. Dat kan leiden tot permerror, een ongeldige sleutelformaatmelding of een mislukte DKIM-controle terwijl de selector wel bestaat.

Kan uw DNS-paneel de waarde niet automatisch verwerken, splits haar dan in meerdere aangehaalde tekenreeksen binnen één TXT-record:

default._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArFirstPart"
  "SecondPartOfTheSamePublicKey"
)

De DKIM-verificateur of toepassing voegt die tekenreeksen zonder extra spaties samen tot één logische waarde. Dat is normale verwerking; het zijn geen afzonderlijke TXT-records. Een bruikbare DKIM-recordgenerator legt uit wanneer deze splitsing nodig is en hoe het DNS-paneel haar verwerkt.

Sleutelbeheer door de verzendprovider

Voor veel bedrijven is een DKIM-recordgenerator van de verzendprovider praktischer dan zelf sleutels beheren. Sommige providers leveren CNAME-records, andere TXT-records. Zij bewaren de privésleutels en kunnen sleutelrotatie verzorgen, maar automatisering en benodigde DNS-wijzigingen verschillen per dienst.

Verzendt u via TrekMail, Amazon SES, Google Workspace, SendGrid of Mailgun, volg dan de instructies voor uw specifieke verzendroute. Bij CNAME-delegatie publiceert u de aangeleverde selectorverwijzingen; de provider publiceert de openbare DKIM-sleutel op de doelhostnaam. Bij een TXT-configuratie publiceert u de opgegeven TXT-waarde.

TrekMail kan domeininstellingen en authenticatiecontroles in één werkwijze samenbrengen. Hoeveel sleutelbeheer u zelf uitvoert, hangt af van de verzendroute. Volg bij het toevoegen van een domein de actuele instructies in Een domein toevoegen.

De TrekMail-configuratie hangt af van de verzending. Nano gebruikt eigen SMTP voor uitgaand verkeer. Volgens de hier beschreven prijsopzet omvatten betaalde abonnementen beheerde SMTP, met Starter vanaf $3.50/maand. Voor betaalde abonnementen kan een proefperiode van 14 dagen gelden waarvoor een creditcard nodig is. Nano gebruikt volgens deze voorwaarden geen proefperiode en vereist geen kaart. Controleer actuele prijzen en voorwaarden.

Voor TrekMail-gebruikers wordt de passende DKIM-recordgenerator bepaald door de verzendroute:

1. Ondertekent TrekMail via beheerde SMTP, gebruik dan de DNS-records uit uw dashboard.
2. Bij eigen SMTP gebruikt u de DKIM-records van de relayprovider, nadat u daar de domeinondertekening hebt ingesteld en bevestigd.
3. Levert uw provider CNAME-selectors, gebruik die dan. Vervang ze niet door TXT-records omdat een handleiding alleen TXT beschrijft.

Twijfelt u tussen doorsturen, aliassen en echte postvakken, lees dan domeinalias of postvak en doorsturen met een e-mailalias. Deze keuzes beïnvloeden welk systeem de mail daadwerkelijk verstuurt en dus welke DKIM-configuratie nodig is.

Waar publiceert u de selector?

Een DKIM-recordgenerator levert geen record voor de domeinroot. DKIM-sleutels worden opgezocht onder een selectorhostnaam zoals default._domainkey, google._domainkey of tm1._domainkey.

DNS-panelen verwachten niet allemaal dezelfde invoer. Sommige willen alleen het hostlabel, andere de volledige hostnaam. Voegt het paneel de zonenaam zelf toe, dan kan een volledig ingevoerd domein leiden tot default._domainkey.example.com.example.com. Een record op die verkeerde naam zal niet voor de bedoelde selector worden gevonden.

Veelvoorkomende namen:

default._domainkey
selector1._domainkey
tm1._domainkey

Bij veel klantdomeinen kan dezelfde invoerfout zich snel herhalen. Werk daarom met controleerbare, herhaalbare DNS-procedures. Onze gids over e-mailhosting voor meerdere domeinen behandelt het beheer van grotere domeinverzamelingen.

De uitvoer van een DKIM-recordgenerator controleren

Een groen dashboardlabel is niet genoeg: controleer ook de DNS-antwoorden via de opdrachtregel. U kunt de uitvoer van een DKIM-recordgenerator toetsen door de selector rechtstreeks met dig op te vragen en het antwoord te bekijken.

Begin met een rechtstreekse query:

dig txt default._domainkey.example.com +short

Bij een gepubliceerd TXT-record hoort de DKIM-waarde zichtbaar te zijn, eventueel als meerdere aangehaalde tekenreeksen. Na een DNS-wijziging kunt u ook een publieke resolver bevragen. Dat toont diens antwoord, niet dat alle caches wereldwijd zijn bijgewerkt:

dig txt default._domainkey.example.com @8.8.8.8 +short

Let op het volgende:

1. Geen antwoord kan wijzen op een verkeerde selector of hostnaam, DNS-caching of andere queryproblemen. Onderzoek de volledige DNS-respons.
2. Een schijnbaar onvolledig antwoord kan door weergave of TXT-splitsing komen; vergelijk de volledige waarde voordat u afkapping concludeert.
3. Meerdere conflicterende DKIM TXT-records op dezelfde selector: herstel dat voordat u opnieuw test.
4. Correct DNS maar falende mail: controleer berichtkoppen en of de verzender de bijpassende selector en privésleutel gebruikt.

Google stelt voor bulkverzenders eisen aan SPF, DKIM en DMARC. DKIM-fouten kunnen, afhankelijk van de toepasselijke voorwaarden, bijdragen aan snelheidsbeperkingen of afwijzingen. DKIM-falen betekent niet automatisch DMARC-falen als uitgelijnde SPF slaagt. Raadpleeg Google's veelgestelde vragen over verzendrichtlijnen voor actuele details.

Controleer bij TrekMail ook de verzendroute. De referentie voor IMAP- en SMTP-instellingen beschrijft eigen SMTP voor Nano en de TrekMail SMTP-mogelijkheden bij betaalde abonnementen. Gaat mail ondanks correct DNS naar spam, volg dan Mijn e-mails komen in spam terecht.

Conclusie: laat DKIM aansluiten op uw mailomgeving

De juiste DKIM-recordgenerator past bij uw mailarchitectuur. Voor eigen servers is lokale sleutelgeneratie meestal geschikt. Op gehoste platforms volgt u de TXT- of CNAME-instructies van de provider en controleert u hoe sleutelrotatie wordt geregeld.

Gebruikt u een eigen MTA, maak dan sleutels lokaal met OpenSSL en bescherm de privésleutel als productie-inloggegevens. Gebruikt u TrekMail, SES of een andere verzendprovider, volg dan hun records. Plak geen willekeurige sleutels uit een onbekend webformulier om alleen een waarschuwing te laten verdwijnen.

Een samenhangende werkwijze met duidelijke verificatie kan het aantal handmatige DNS-ingrepen en foutmogelijkheden beperken. Dat helpt vooral bij meerdere merken, klantdomeinen of lopende migraties. Bouwt u de omgeving nog op, lees dan domeinmail doorsturen naar Gmail voordat u doorsturen instelt en vergelijk vervolgens de TrekMail-abonnementen.

Een DKIM-recordgenerator hoort geen ondoorzichtige stap te zijn, maar een beheersbaar onderdeel van een mailomgeving die u begrijpt.