E-mailbezorging en DNS

DKIM instellen: stap voor stap voor eigen domeinen

Door Alexey Bulygin
Stappenplan voor DKIM instellen op eigen domeinen

DKIM instellen is een belangrijk onderdeel van een betrouwbare verzendconfiguratie voor een eigen domein. Een ontbrekende, ongeldige of afgekorte sleutel, of een handtekening met het verkeerde domein, kan de inboxplaatsing nadelig beïnvloeden. Deze gids geeft u een praktische werkwijze: genereer de sleutel, publiceer het DNS-record, controleer het via de opdrachtregel en spoor uitlijningsfouten op die DMARC ook na een groen vinkje nog kunnen laten mislukken.

Voor de volledige basis rond MX, SPF, mailboxen en mailclients begint u bij e-mail maken met uw domein. Kiest u eerst een platform, dan behandelt zakelijke e-mail die bredere afweging.

Het probleem is eenvoudig. De meeste DKIM-fouten komen niet door cryptografie, maar door plakfouten in DNS, panelen die het domein dubbel toevoegen, beschadigde sleutels van 2048 bits of een e-maildienstverlener die met zijn eigen domein ondertekent in plaats van het uwe. U kunt uren aan de verkeerde oorzaak besteden. Een herhaalbaar stappenplan helpt dat voorkomen.

Wat DKIM instellen daadwerkelijk doet

Bij DKIM publiceert u een openbare sleutel in DNS en laat u uw mailserver elk bericht met de bijbehorende privésleutel ondertekenen. Ontvangende servers controleren de handtekening en de autorisatie door het ondertekenende domein, en kunnen wijzigingen aan ondertekende headers of berichtinhoud tijdens transport detecteren.

DKIM gebruikt asymmetrische cryptografie. Uw verzendsysteem bewaart de privésleutel; DNS publiceert de openbare sleutel. Een uitgaand bericht krijgt een DKIM-Signature-header met een ondertekenend domein (d=) en selector (s=). De ontvanger zoekt die selector in DNS op en controleert de handtekening tegen de berichtinhoud. Dit mechanisme is vastgelegd in RFC 6376.

Vanaf februari 2024 heeft Google de eisen voor bulkverzenders aangescherpt. Google vereist zowel SPF als DKIM, en minstens één daarvan moet aansluiten op het domein in de zichtbare From-header om DMARC-uitlijning te laten slagen. Lees de actuele formulering in Googles veelgestelde vragen over verzendrichtlijnen.

Dat is belangrijk: een technisch geldige handtekening is niet automatisch bruikbaar voor uw doel. Een ongeldige of niet-uitgelijnde DKIM-configuratie kan tot spamplaatsing, DMARC-problemen of beide bijdragen.

Voorbereiding voordat u DNS aanpast

Goed DKIM-beheer begint met vaststellen wie uw mail daadwerkelijk ondertekent. Dat lijkt vanzelfsprekend, maar juist hier gaat het mis bij migraties, wijzigingen in doorsturing en providerwissels. Waar u DKIM-records genereert of verkrijgt, hangt volledig af van het verzendpad.

Stel eerst deze vraag: wie verstuurt de uitgaande mail van dit domein?

  1. Verzendt Google Workspace, genereer de DKIM-sleutel dan in Google Admin.
  2. Verzendt Microsoft 365, schakel DKIM daar in.
  3. Verzendt SendGrid, Mailgun of Amazon SES, authenticeer het domein dan bij die provider.
  4. Verzendt TrekMail Managed SMTP, gebruik dan de DKIM-waarden die TrekMail toont.
  5. Beheert TrekMail de inboxen maar gebruikt u externe SMTP, volg dan de ondertekeningsinstructies van uw SMTP-provider en stel zo nodig SMTP in TrekMail in.

TrekMail ondersteunt beide routes. Nano gebruikt BYO SMTP; betaalde abonnementen kunnen beheerde SMTP gebruiken, afhankelijk van de voorwaarden. De documentatie over Bring Your Own SMTP geeft voorbeelden voor SES, SendGrid en Mailgun. TrekMails uitleg over afleverproblemen vermeldt ook dat Managed SMTP met de DKIM-sleutel van uw domein ondertekent. Dat kan DMARC bij doorsturing en relays helpen, zolang de handtekening geldig en uitgelijnd blijft.

Voorbeeld: uw mailbox staat in TrekMail, maar uitgaande mail gaat via SendGrid. SendGrid moet dan ondertekenen. TrekMail kan de mailbox opslaan, maar stelt daarmee niet automatisch DKIM in SendGrid voor u in.

De eerste vaste regel: genereer sleutels in het systeem dat het bericht ondertekent. Genereert u ze elders, dan kan het record wel in DNS staan maar verder niets doen.

DKIM-recordtypen: TXT versus CNAME

DKIM instellen betekent meestal een TXT-record met de openbare sleutel publiceren. Sommige providers vragen in plaats daarvan om een of meer CNAME-records die verwijzen naar sleutels die zij hosten. Beide werkwijzen zijn bruikbaar. Neem exact over wat uw verzender opgeeft.

De klassieke DKIM-configuratie gebruikt een TXT-record op:

selector._domainkey.example.com

De waarde ziet er zo uit:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Beheerde diensten gebruiken vaak CNAME voor DKIM, zodat zij sleutels kunnen roteren zonder dat u opnieuw DNS hoeft te wijzigen. TXT geeft u directe controle, maar legt het onderhoud ook bij u als een sleutel moet worden vervangen.

MethodeWat u publiceertGeschikt voorBelangrijkste risico
TXTVolledige openbare sleutel in DNSGoogle Workspace en veel zelfbeheerde of directe providerconfiguratiesLange sleutels worden afgekort of verkeerd geplakt
CNAMEAlias naar een door de provider gehost DKIM-recordBeheerde platforms en eenvoudigere sleutelrotatieVerkeerd doel of een ontbrekend record uit een reeks

Het veld voor de hostnaam is een valkuil. Is uw domein example.com en de selector k1, dan is de hostnaam doorgaans:

k1._domainkey

Niet dit:

k1._domainkey.example.com

Veel DNS-panelen voegen het hoofddomein automatisch toe. Vult u daar de volledige naam in, dan publiceert u uiteindelijk k1._domainkey.example.com.example.com. Dat record staat niet waar ontvangende servers het verwachten.

Voor de vereiste DNS-laag van TrekMail raadpleegt u vereiste DNS-records. Die uitleg vermeldt ook dat sommige DNS-providers DKIM-TXT-waarden in delen tussen aanhalingstekens willen ontvangen.

DKIM stap voor stap instellen in DNS

De werkwijze is kort: verkrijg de selector, publiceer het record, wacht op DNS, controleer het exacte antwoord en schakel ondertekening in als uw provider nog een laatste schakelaar vereist. Zonder controle blijft het giswerk.

Gebruik dit stappenplan.

  1. Open de verzendprovider en genereer of toon het DKIM-record.
  2. Kopieer de selector exact. Hernoem hem alleen als de provider dat ondersteunt.
  3. Maak het DNS-record aan op selector._domainkey.
  4. Plak de volledige TXT-waarde of het CNAME-doel exact zoals aangeleverd.
  5. Stel TTL in op 3600, tenzij u een reden hebt voor een andere waarde.
  6. Wacht op DNS-propagatie.
  7. Controleer met dig of nslookup voordat u productiemail verstuurt.
  8. Schakel ondertekening bij de provider in als de interface een laatste activeringsschakelaar heeft.

Voorbeeld met een TXT-record:

; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Voorbeeld met een CNAME-record:

; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.

DNS-wijzigingen zijn vaak snel zichtbaar, maar niet onmiddellijk. TrekMails gids voor DNS-problemen noemt voor veel updates ongeveer 5 tot 15 minuten. Dat is geen vaste termijn: caches en TTL kunnen langer doorwerken. Blijft de status daarna ongewijzigd, controleer dan de opmaak, dubbele records en de hostnaam.

DKIM en het probleem met sleutels van 2048 bits

Gebruik voor moderne DKIM-configuraties RSA-sleutels van 2048 bits als uw provider en DNS-host die ondersteunen. Ze zijn sterker, maar ook langer, wat in oudere DNS-panelen problemen kan geven. Een afgekorte sleutel lijkt aanwezig terwijl de controle mislukt, en kan daardoor misleidend zijn.

Google beveelt sleutels van 2048 bits aan waar ondersteund, met 1024 bits als terugvaloptie voor hosts die langere records niet aankunnen. Het praktische probleem zit vaak niet in DNS zelf, maar in het beheerpaneel ervoor.

Problemen met een DKIM-sleutel van 2048 bits zien er meestal zo uit:

  1. Het paneel kort de waarde ongemerkt af.
  2. Het paneel vereist delen tussen aanhalingstekens zonder dat duidelijk te maken.
  3. Het paneel voegt regeleinden toe aan de base64-sleutel.
  4. Het paneel escape't tekens op een manier die de provider niet verwacht.

Vereist uw DNS-host gesplitste strings, publiceer de waarde dan zo:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"

De ontvanger voegt de delen tussen aanhalingstekens samen. Dat is normaal. Spaties in het sleutelmateriaal zelf toevoegen is dat niet. Een extra teken kan de DKIM-controle al laten mislukken.

Beheert u veel domeinen, dan merkt u hier de operationele kosten. De ene registrar verwerkt lange TXT-waarden goed, de andere niet en een derde herschrijft ze. Daarom standaardiseren bureaus vaak op minder registrars of kiezen zij waar mogelijk CNAME-ondertekening met sleutels bij de provider. Voor een omgeving met meerdere klanten beschrijft e-mailhosting voor meerdere domeinen het bredere beheermodel.

DKIM controleren op DNS en echte berichten

Een dashboard met “actief” is geen volledig bewijs. Een echte controle betekent openbare DNS rechtstreeks opvragen, het antwoord controleren en vervolgens in headers van echte mail vaststellen dat het verwachte domein en de selector worden gebruikt. Minder dan dat is slechts een deelcontrole.

Begin bij de opdrachtregel.

# macOS / Linux
dig txt k1._domainkey.example.com +short

# Windows
nslookup -type=txt k1._domainkey.example.com

U wilt het volledige v=DKIM1-record zien, of geciteerde delen die samen duidelijk de volledige sleutel vormen. Is het antwoord leeg, controleer dan achtereenvolgens:

  1. De selector klopt.
  2. Het hostnaamveld bevat het domein niet dubbel.
  3. Het recordtype komt overeen met de instructie van de provider.
  4. De waarde is volledig en niet afgekort.
  5. Het oude record zit niet nog in een cache.

Stuur daarna een testbericht naar Gmail of een andere mailbox waarvan u de headers kunt bekijken. Zoek de authenticatieresultaten en de DKIM-handtekening.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...

Lijkt DNS in orde maar blijft de inboxplaatsing slecht, kijk dan verder. TrekMails gids voor mail die in spam belandt noemt DNS-controles, domeinopwarming, lijstkwaliteit en inhoud. DKIM helpt de authenticatie op orde te brengen, maar geeft u niet automatisch een goede reputatie.

Let ook op doorsturing. SPF kan daarbij mislukken; DKIM kan DMARC in veel van die routes laten slagen zolang de geldige, uitgelijnde handtekening behouden blijft. Lees over e-maildoorsturing als dit onderdeel van uw inrichting is, zodat u een SPF-fout bij doorsturing niet verwart met het mislukken van alle authenticatie.

DKIM en de uitlijningsvalkuil

Uitlijning is waar veel “werkende” DKIM-configuraties tekortschieten. De handtekening kan geldig zijn terwijl DMARC toch mislukt als het ondertekenende domein niet aansluit op het From-domein dat gebruikers zien en SPF geen uitgelijnde geldige route biedt. Dit is slechts soms een DNS-probleem; vaak zit het in de providerconfiguratie.

Een veelvoorkomend geval:

From: ceo@example.com
DKIM-ondertekenaar: d=sendgrid.net
Resultaat: DKIM kan slagen, maar DMARC-uitlijning via DKIM kan mislukken omdat het ondertekenende domein niet aansluit op example.com.

Googles richtlijnen zeggen dat bij bulkverzenders het zichtbare From-domein op organisatiedomeinniveau moet aansluiten op SPF of DKIM. Ondertekent uw e-maildienstverlener met zijn eigen domein, dan kan de handtekening geldig zijn maar uw doel voor uitgelijnde DKIM niet bereiken.

De oplossing heet bij providers vaak domeinauthenticatie, white-labeling of aangepaste return-path-configuratie. Let erop dat return-path betrekking heeft op SPF-uitlijning; voor DKIM wilt u uiteindelijk een handtekening zoals:

DKIM-Signature: ... d=example.com; s=s1; ...

Dit is de DKIM-configuratie die aan DMARC kan bijdragen. Een handtekening met een niet-uitgelijnd domein is daarvoor niet voldoende.

Oude versus nieuwe aanpak van DKIM

De oude aanpak is handmatig en foutgevoelig: elk domein, elke provider, elke selector en elk DNS-detail wordt apart behandeld. De nieuwe aanpak draait om standaardisatie. Kies een herhaalbaar verzendmodel, centraliseer DNS-controles en los niet steeds hetzelfde probleem opnieuw op.

Oude aanpakNieuwe aanpak
Sleutels in willekeurige tools maken en hopen dat ze bij de verzender passenDKIM genereren bij de daadwerkelijke verzender
TXT-waarden afzonderlijk plakken en wachten op supportvragenWaar mogelijk providerbeheer gebruiken en via de opdrachtregel controleren
Elk domein als een uitzonderingsgeval behandelenEén stappenplan gebruiken voor klant- en teamdomeinen
Spamproblemen pas onderzoeken nadat een campagne misluktDNS, uitlijning en headers controleren vóór de eerste productieverzending

TrekMail sluit aan op dit model. De beschreven mogelijkheden omvatten meerdere eigen domeinen in één dashboard, gedeelde opslag in plaats van een prijs per mailbox, IMAP-migratie en de keuze tussen BYO SMTP en inbegrepen SMTP afhankelijk van het abonnement. De vermelde startprijs voor betaalde abonnementen is $3.50 per maand; controleer de actuele facturering en voorwaarden. Het platform richt zich op teams, kleine bedrijven, bureaus en MSP's die hun beheerlast willen beperken.

Is het grotere probleem het proces en niet DNS, lees dan over e-mailbeheer voor klanten. In omgevingen met meerdere domeinen hangen afleverproblemen vaak eerst samen met eigenaarschap en pas daarna met records.

Laatste DKIM-controlelijst

Een degelijke DKIM-configuratie gebruikt het juiste ondertekenende systeem, de juiste DNS-hostnaam, een volledige sleutel, openbare DNS-controle en uitgelijnde ondertekening voor DMARC. Een fout in een van die onderdelen kan de hele authenticatieketen verzwakken.

  1. Bevestig welk systeem de uitgaande mail ondertekent.
  2. Publiceer exact de selector en het recordtype van de provider.
  3. Gebruik selector._domainkey in het hostnaamveld, tenzij uw DNS-host expliciet de volledige naam vereist.
  4. Houd sleutels van 2048 bits intact. Splits strings tussen aanhalingstekens alleen als het DNS-paneel dat vereist.
  5. Controleer met dig of nslookup.
  6. Stuur een test en controleer headers op dkim=pass en een uitgelijnde header.d.
  7. Controleer DMARC-resultaten na ingebruikname.

Dat is de kern: DKIM instellen vraagt vooral nauwkeurigheid. Wilt u minder afhankelijkheden, standaardiseer dan uw domeinen en verzendpad in TrekMail, houd DNS inzichtelijk en vervang telkens apart uitzoekwerk door een vaste werkwijze.

Dit artikel delen

We gebruiken noodzakelijke technologieën om TrekMail te laten werken en te beveiligen. Door te bevestigen staat u ook beperkte analyses en advertentiemeting toe zoals beschreven in ons Cookiebeleid.

Inloggen bij TrekMail

Toegang tot je dashboard, mailboxen en DNS.

of

12 tekens wachtwoorden komen overeen

of

Herstelmail verzonden

Als er een account bestaat voor dit e-mailadres, hebben we instructies gestuurd om je wachtwoord opnieuw in te stellen.

Door verder te gaan ga je akkoord met de TrekMail- Voorwaarden en het Privacybeleid.