Wat is een DKIM-selector en hoe beheer je deze bij meerdere e-mailproviders?

Wat is een DKIM-selector?

Een DKIM-selector is een korte tekenreeks in de header van een met DKIM ondertekende e-mail, die de ontvangende mailserver aangeeft waar de bijbehorende openbare sleutel in het DNS te vinden is. Deze wordt gedefinieerd in de `s=`-tag van de DKIM-Signature-header.

Elke DKIM-handtekening bevat een selectorwaarde. De selector vormt, in combinatie met het ondertekenende domein uit de `d=`-tag, een DNS-zoekpad dat verwijst naar een specifiek TXT-record dat de openbare sleutel bevat die wordt gebruikt om de handtekening te verifiëren.

Zo ziet de selector eruit in de header van een e-mail:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; h=from:to:subject:date;
bh=abc123…=; b=xyz789…=

In dit voorbeeld is `selector1` de DKIM-selector. De ontvangende server zal `selector1._domainkey.example.com` opvragen om de openbare sleutel op te halen.

Organisaties gebruiken vaak meerdere ondertekeningssleutels tegelijk, afhankelijk van hun e-mailbehoeften. Elke sleutel krijgt een eigen selector, zodat beide zonder conflicten onder hetzelfde domein kunnen bestaan.

Selectors maken het ook mogelijk om sleutels te rouleren zonder dat er downtime ontstaat. Je kunt een nieuwe sleutel publiceren onder een nieuwe selector terwijl de oude selector actief blijft, en vervolgens overschakelen zodra de propagatie is voltooid.

Hoe werken DKIM-selectors?

Wanneer een ontvangende mailserver een met DKIM ondertekende e-mail ontvangt, leest deze de selector (`s=`) en het domein (`d=`) uit de e-mailheader, voert een DNS-zoekopdracht uit op `{selector}._domainkey.{domain}`, haalt de openbare sleutel op uit het resulterende TXT-record en gebruikt die sleutel om de cryptografische handtekening op het bericht te verifiëren.

Hier volgt de stapsgewijze uitleg:

Stap 1: De verzendende server ondertekent de e-mail

Voordat de e-mail de verzendende mailserver (of ESP) verlaat, gebruikt de server zijn privésleutel om een cryptografische handtekening te genereren over bepaalde headervelden en de berichttekst. Deze handtekening wordt, samen met de selectorwaarde en het ondertekeningsdomein, aan de e-mail toegevoegd als de `DKIM-Signature`-header.

Stap 2: De ontvangende server haalt de selector en het domein eruit

Zodra de e-mail in de inbox terechtkomt, analyseert de ontvangende server de `DKIM-Signature`-header en haalt daar twee waarden uit:

1. De selector van `s=` 
2. Het domein vanaf `d=`.

Stap 3: De ontvangende server vraagt DNS op

The server constructs a DNS query by combining the selector, the fixed string `_domainkey`, and the domain: {selector}._domainkey.{domain} → TXT record

Als bijvoorbeeld `s=google` en `d=example.com`, luidt de DNS-query: google._domainkey.example.com

Stap 4: DNS retourneert de openbare sleutel

Het TXT-record op dat DNS-pad bevat de openbare sleutel en de bijbehorende parameters:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAO…

Stap 5: De ontvangende server controleert de handtekening

De server gebruikt de openbare sleutel om de cryptografische handtekening in de e-mailheader te verifiëren. 

1. Als de handtekening overeenkomt, is DKIM geslaagd. 
2. Als de sleutel ontbreekt, is het record onjuist opgebouwd.
3. Als de handtekening niet overeenkomt, mislukt de DKIM-verificatie.

De selector koppelt de e-mailheader aan het DNS-record omdat de ontvangende server zonder het DNS-record geen manier zou hebben om de juiste publieke sleutel te vinden, vooral wanneer een domein meerdere DKIM-sleutels publiceert voor verschillende diensten.

Syntaxis en indeling van de DKIM-selector 

DKIM-selectors moeten voldoen aan specifieke syntaxisregels die zijn vastgelegd in RFC 6376.

Toegestane tekens:

• Alfanumerieke tekens (a–z, A–Z, 0–9)
• Koppeltekens (-)
• Punten (.) voor selectors in subdomeinstijl

Beperkingen:

• Bij DNS-resolutie wordt bij het invoeren van selectors geen onderscheid gemaakt tussen hoofdletters en kleine letters, hoewel het gebruik van kleine letters de gangbare praktijk is.
• In RFC 6376 is geen maximale lengte vastgelegd, maar er gelden wel praktische DNS-beperkingen. Bij de meeste implementaties worden selectors beperkt tot maximaal 63 tekens (de maximale lengte van een DNS-label).
• Selectors mogen niet met een koppelteken beginnen of eindigen.
• Punten in selectors vormen subdomeinhierarchieën in de DNS-query. Zo is `2024.jan._domainkey.example.com` een geldig querypad als de selector `2024.jan` is.

Het DNS TXT-recordformaat in het pad van de selector bevat de volgende tags:

Opmerking: 2048-bits RSA-sleutels produceren openbare sleutelstrings die de limiet van 255 tekens voor een enkele DNS TXT-string overschrijden. DNS lost dit op via TXT-records met meerdere strings, waarbij de waarde wordt verdeeld over meerdere strings tussen aanhalingstekens die de resolver samenvoegt volgens RFC 6376. Niet alle DNS-beheerinterfaces kunnen dit echter efficiënt verwerken, wat een veelvoorkomende oorzaak is van DKIM-fouten

Hoe uw DKIM-selector te vinden 

Er zijn vier betrouwbare methoden om te achterhalen welke DKIM-selectors voor een bepaald domein worden gebruikt. Elke methode heeft zijn eigen voordelen, afhankelijk van of je zelf de beheerder van het domein bent, toegang hebt tot e-mailheaders of de situatie van buitenaf controleert.

Methode 1: E-mailheaders controleren

Het controleren van de e-mailheaders is de meest directe manier. Open een bericht dat vanaf het betreffende domein is verzonden en bekijk de volledige e-mailheaders.

• In Gmail: Open het bericht → klik op het menu met de drie puntjes → ‘Origineel weergeven’.
• In Outlook: Open het bericht → Bestand → Eigenschappen → „Internetkoppen“.
• In Apple Mail: Weergave → Bericht → Alle kopteksten.

Zoek naar de `DKIM-Signature`-header en zoek de `s=`-tag. Die waarde is de selector.

Als de e-mail via meerdere ondertekeningsdiensten is verstuurd, kun je meer dan één `DKIM-Signature`-header zien, elk met een andere selector.

Methode 2: Gebruik een DKIM-opzoektool

Als je de naam van de selector kent, kun je het DKIM-record rechtstreeks opvragen via selector._domainkey.example.com opvragen. PowerDMARC’s DKIM-recordopzoekfunctie, MXToolbox of DNS-opdrachten via de opdrachtregelzoals dig en nslookup kunnenhet TXT-record dat voor die selector is gepubliceerd.

Gebruik graven:

bash

dig TXT selector1._domainkey.example.com +short

 

Met behulp van nslookup:

bash

nslookup -q=TXT selector1._domainkey.example.com

Bij deze methode moet je de naam van de selector al kennen, of veelgebruikte standaardwaarden uitproberen.

De DKIM-opzoekfunctie van PowerDMARC kan ook selectors voor veel domeinen automatisch detecteren, de DKIM-syntaxis valideren, ontbrekende of onjuist opgebouwde records identificeren en helpen bij het oplossen van veelvoorkomende DKIM-configuratieproblemen. 

Methode 3: Controleer de beheerconsole van uw ESP

De meeste e-mailproviders vermelden de DKIM-selector en de openbare sleutel in hun authenticatie-instellingen. Bijvoorbeeld:

• Google Workspace: Beheerdersconsole → Apps → Google Workspace → Gmail → E-mail verifiëren
• Microsoft 365: Defender-portaal → Beleid en regels → Beleid inzake bedreigingen → E-mailverificatie → DKIM
• Mailchimp: Website → Domeinen → Verificatie → DKIM-instellingen

Methode 4: Geaggregeerde DMARC-rapporten

Dit is de meest effectieve manier om alle selectors te achterhalen die actief e-mails namens uw domein ondertekenen, ook degene waarvan u misschien niet op de hoogte bent.

DMARC-geaggregeerde rapporten (RUA-rapporten) bevatten de DKIM-authenticatieresultaten voor elk bericht dat door rapporterende mailservers is ontvangen. Elk resultaat bevat de gebruikte selector, het ondertekenende domein en de status geslaagd/mislukt.

Als uw organisatie meerdere e-mailproviders gebruikt of als externe diensten namens u inloggen, zullen DMARC-rapporten selectors aan het licht brengen die u mogelijk niet zou ontdekken door alleen de headers te controleren. Dit is met name nuttig voor het opsporen van schaduw-IT-e-maildiensten die ooit zijn geautoriseerd maar nooit buiten gebruik zijn gesteld.

De DMARC-analysator analyseert deze geaggregeerde rapporten automatisch en toont alle actieve DKIM-selectors per domein in één dashboard, waardoor het niet meer nodig is om XML-gegevens handmatig uit meerdere rapportagebronnen te halen en te vergelijken.

Note: There is no DNS wildcard or enumeration method to discover all selectors under `_domainkey.{domain}`. DNS does not support listing all subrecords of a zone from the outside. You cannot brute-force all possible selectors. The four methods above are the practical options.

5. Standaard DKIM-selectors van ESP: referentietabel 2026 

Een van de meest voorkomende taken bij het beheer van DKIM is het vaststellen welke selector bij welke e-maildienst hoort. In de onderstaande tabel staan de standaard DKIM-selectors die begin 2026 door 14 grote e-maildienstverleners worden gebruikt.

Belangrijk: ESP's kunnen standaard selectors op elk moment wijzigen, en sommige platforms wijzen accountspecifieke of willekeurige selectors toe. Controleer de selector die in uw eigen ESP-beheerdersconsole wordt weergegeven altijd aan de hand van deze tabel.

Als uw domein e-mail via drie of vier van deze platforms tegelijk verstuurt, hebt u drie of vier actieve DKIM-selectors in uw DNS, en elk daarvan moet afzonderlijk worden bijgehouden, geverifieerd en geroteerd. 

Het beheren van meerdere DKIM-selectors bij verschillende e-mailproviders wordt op grote schaal een hele uitdaging, vooral wanneer elk platform andere rotatieschema’s, selectorformaten en DNS-vereisten hanteert. 

PowerDMARC Hosted DKIM helpt bij het centraliseren van het beheer van selectors via één enkel dashboard, waardoor het eenvoudiger wordt om DKIM-selectors toe te voegen, te rouleren, te valideren en te monitoren zonder herhaaldelijk handmatig DNS-records te moeten wijzigen.

Start een gratis proefperiode

Naamgevingsconventies en beste praktijken

DKIM-selectors kunnen binnen de syntaxisregels vrijwel elke naam krijgen. Zonder een consistente naamgevingsconventie raakt het beheer van selectors al snel in de war naarmate er diensten worden toegevoegd en sleutels worden vernieuwd.

Aanbevolen naamgevingspatronen

Een gestructureerde naamgevingsmethode maakt het veel eenvoudiger om de verantwoordelijkheid vast te stellen, wijzigingen bij te houden, storingen op te sporen en verwarring in de bedrijfsvoering later te voorkomen. 

Patroon 1: ESP + Datum

Voorbeelden:

• google-2026-eerste-kwartaal
• sendgrid-202601
• hubspot-2025q4

Dit is het patroon dat in de praktijk het meest bruikbaar is. In één oogopslag kun je zien welke dienst eigenaar is van de sleutel en wanneer deze voor het laatst is vernieuwd. Tijdens een audit kun je elke selector met een datum die meer dan 12 maanden oud is, direct markeren.

Patroon 2: Servicefunctie + Volgorde

Voorbeelden:

• marketing-01
• transactioneel-01
• bedrijf-01

Handig wanneer meerdere e-mailproviders hetzelfde domein bedienen en u de selectors liever per e-mailstroom wilt ordenen dan per aanbieder.

Patroon 3: ESP-standaard (geen aangepaste naamgeving)

Veel ESP’s staan het zelf kiezen van selector-namen niet toe. Google Workspace gebruikt altijd `google`. Microsoft 365 gebruikt `selector1` en `selector2`. In deze gevallen moet je het doen met wat het platform biedt en de koppeling extern bijhouden.

Te vermijden naamgevingspraktijken

Slecht gestructureerde of te algemene namen kunnen voor verwarring zorgen tijdens audits, bij het oplossen van problemen en bij sleutelrotaties, vooral in omgevingen met meerdere ESP’s en een groot aantal actieve selectors. Vermijd de volgende naamgevingspraktijken: 

• Algemene namen zonder context: `key1`, `test`, `dkim` geven geen informatie over de ESP of de rotatiestatus.
• Selectors die gevoelige informatie bevatten: Verwerk geen details over de interne infrastructuur, hostnamen van servers of werknemers-ID's in selectornamen. Selectornamen zijn via DNS openbaar zichtbaar.
• Te lange selectors: Hoewel technisch gezien maximaal 63 tekens zijn toegestaan, maken selectors van meer dan 30 tekens DNS-records en opzoekopdrachten onnodig complex.

Een opstelling met één domein en één e-mailprovider is eenvoudig. Je genereert een sleutelpaar, publiceert de openbare sleutel onder de selector van de e-mailprovider, en je bent klaar. De operationele uitdaging begint wanneer datzelfde domein e-mails via meerdere platforms verstuurt.

Een praktisch managementkader

De volgende levenscyclus in vijf fasen biedt een gestructureerde aanpak voor het beheer van selectiecriteria:

Fase 1: Inventarisatie

Leg elke actieve DKIM-selector voor elk domein dat u beheert, inclusief de ESP, sleutellengte, publicatiedatum en de verantwoordelijke persoon of het verantwoordelijke team. Geaggregeerde DMARC-rapporten zijn de snelste manier om deze inventaris op te bouwen, omdat ze elke selector onthullen die momenteel e-mail voor uw domein ondertekent, inclusief de selectors waarvan niemand zich herinnert ze te hebben ingesteld.

Fase 2: Valideren

Controleer voor elke selector in je inventaris via DNS of de openbare sleutel is gepubliceerd en correct is opgemaakt. Stuur een testmail via elke e-maildienst en controleer of DKIM-verificatie slaagt. Controleer de sleutellengte en markeer elke selector die een 1024-bits sleutel gebruikt.

Fase 3: Standaardiseren

Stel een naamgevingsconventie vast en pas deze toe op elke selector waarover u de controle hebt. Voor ESP’s die vaste selectornamen gebruiken, dient u de koppeling duidelijk te documenteren. Stel een roulatieschema op en wijs verantwoordelijkheden toe.

Fase 4: Monitoren.

Gebruik de geaggregeerde DMARC-rapporten om de DKIM-slaag- en faalpercentages per selector continu te monitoren. Een plotselinge stijging van het faalpercentage bij een specifieke selector duidt meestal op een wijziging in de DNS, het verlopen van een sleutel of een configuratiewijziging bij de e-mailprovider.

Fase 5: Buiten gebruik stellen

Wanneer u stopt met het gebruik van een ESP, moet u de DKIM-sleutel intrekken door een lege `p=`-waarde in het DNS-record van de selector te publiceren. Verwijder het DNS-record niet zomaar. Een lege `p=`-waarde geeft ontvangende servers expliciet aan dat de sleutel is ingetrokken. Als u het record volledig verwijdert, leidt dit tot een fout bij het opzoeken van het DNS-record, wat dubbelzinnig is en door verschillende ontvangers op verschillende manieren kan worden geïnterpreteerd.

PowerDMARC biedt een gecentraliseerd dashboard dat alle actieve DKIM-selectors in elk domein van uw account in kaart brengt, waarbij tegelijkertijd gegevens uit DMARC-aggregatrapporten en DNS-monitoring worden gehaald. Voor MSP's die grote klantenportefeuilles beheren, vervangt dit het bijhouden via spreadsheets, dat onbeheersbaar wordt zodra er meer dan enkele tientallen domeinen zijn.

DKIM-sleutelrotatie en selectiestrategie

Bij DKIM-sleutelrotatie wordt een nieuw sleutelpaar gegenereerd en wordt de nieuwe openbare sleutel onder een nieuwe (of bijgewerkte) selector gepubliceerd, waarna de verzendende dienst zo wordt geconfigureerd dat deze met de nieuwe privésleutel ondertekent.

Een DKIM-privésleutel die jarenlang ongewijzigd blijft, vormt een steeds groter risico. Als de sleutel in verkeerde handen valt door een inbreuk op de server, een interne dreiging of een kwetsbaarheid in het sleutelopslagsysteem, kan een aanvaller namens uw domein e-mails ondertekenen die de DKIM-verificatie doorstaan. Door de sleutel regelmatig te vernieuwen, wordt de blootstellingsperiode beperkt.

Hoe u DKIM-sleutels kunt vernieuwen zonder dat dit tot uitval leidt

Het standaardrotatieproces maakt achtereenvolgens gebruik van twee selectors:

1. Genereer een nieuw sleutelpaar: Maak een nieuw 2048-bits RSA- (of Ed25519-) sleutelpaar aan.
2. Publiceer de nieuwe openbare sleutel onder een nieuwe selector: Als uw huidige selector bijvoorbeeld `google-2025q3` is, publiceer de nieuwe sleutel dan onder `google-2026q1`.
3. Wacht tot de DNS-updates zijn doorgevoerd: Het duurt 24 tot 48 uur voordat het nieuwe TXT-record wereldwijd is doorgevoerd. Voor Microsoft 365 in het bijzonder kan het tot 96 uur duren voordat het volledig is doorgevoerd.
4. Werk de ondertekeningsconfiguratie bij: Configureer de ESP of de mailserver om uitgaande berichten te ondertekenen met de nieuwe privésleutel en de nieuwe selector.
5. Controleer: Verzend testberichten en controleer of DKIM slaagt met de nieuwe selector.
6. De oude sleutel intrekken: Publiceer na een overgangsperiode (meestal 7 tot 14 dagen, zodat berichten die met de oude sleutel zijn ondertekend nog kunnen worden afgeleverd) een lege `p=`-waarde voor de oude selector.

DKIM-sleutelrotatie in omgevingen met meerdere e-mailproviders

Elke ESP heeft zijn eigen draaimechanisme:

• Microsoft 365: biedt ingebouwde selectorrotatie tussen `selector1` en `selector2`. Start de rotatie via het Defender-portaal.
• SendGrid: schakelt automatisch tussen `s1` en `s2`.
• Google Workspace: vereist handmatige regeneratie van de sleutel via de beheerconsole.
• De meeste marketingplatforms: vereisen handmatige rotatie via hun domeinverificatie-instellingen.

Als je alle selectors op dezelfde dag vervangt, ontstaat er een geconcentreerd risicoperiode en wordt het moeilijker om problemen op te lossen als er iets misgaat. Verdeel de vervangingen over verschillende weken of maanden.

De gehoste DKIM-functie van PowerDMARC functie regelt het genereren van sleutels, DNS-publicatie en selectorrotatie voor alle domeinen in uw account, met configureerbare rotatieschema's per domein en per ESP.

Start een gratis proefperiode

Veelvoorkomende fouten bij DKIM-selectors en hoe je deze kunt oplossen 

Wanneer DKIM niet werkt, is de oorzaak vrijwel altijd terug te voeren op een van de weinige fouten in de selector- of DNS-configuratie. In de onderstaande tabel staan de meest voorkomende fouten, de bijbehorende symptomen en hoe u deze kunt oplossen.

Het 2048-bits afkappingsprobleem in detail

Wanneer organisaties hun DKIM-sleutels upgraden van 1024-bits naar 2048-bits (aangezien 1024-bits RSA voor DKIM-doeleinden als zwak wordt beschouwd), wordt de lengte van de Base64-gecodeerde openbare sleutel ongeveer verdubbeld. De resulterende tekenreeks is doorgaans langer dan 400 tekens.

DNS TXT-records hebben een limiet van 255 tekens per tekenreeks binnen het record. De oplossing, zoals vastgelegd in RFC 6376, is om de waarde over meerdere tekenreeksen binnen één TXT-record te verdelen. Ontvangende mailservers voegen deze tekenreeksen automatisch samen.

De meeste gangbare DNS-beheerinterfaces gaan hier niet efficiënt mee om:

• Sommige interfaces korten de waarde zonder waarschuwing stilzwijgend in tot 255 tekens.
• Sommige interfaces weigeren de invoer volledig met een vaag foutbericht.
• Bij sommige interfaces moet de beheerder de tekenreeks handmatig opsplitsen en elk deel tussen aanhalingstekens plaatsen.

Als je een 2048-bits sleutel publiceert en DKIM meteen niet meer werkt, controleer dan het daadwerkelijke DNS-antwoord met `dig` of `nslookup`. Vergelijk de geretourneerde `p=`-waarde met de volledige openbare sleutel uit je sleutelpaar. Als de geretourneerde waarde korter is, heeft je DNS-provider deze ingekort.

Om dit te voorkomen: 

• Gebruik een DNS-provider die van nature lange TXT-records ondersteunt (Cloudflare, AWS Route 53 en de meeste DNS-platforms voor bedrijven kunnen dit goed aan).
• Gebruik DKIM op basis van CNAME, waarbij het DNS-pad van de selector verwijst naar een CNAME die door de ESP wordt gehost. De ESP beheert het TXT-record op zijn eigen infrastructuur, waardoor het probleem volledig wordt vermeden.
• Als u een provider moet gebruiken waarbij handmatige opsplitsing vereist is, verdeel de sleutel dan in reeksen van maximaal 250 tekens, elk tussen aanhalingstekens, binnen één TXT-record.

DKIM-selectors en DMARC-afstemming 

DKIM en DMARC zijn afzonderlijke protocollen, maar hun onderlinge werking verrast veel beheerders. Het kan gebeuren dat DKIM slaagt terwijl DMARC nog steeds faalt. Als dat gebeurt, is de oorzaak vrijwel altijd een discrepantie in de domeinafstemming, die te maken heeft met de manier waarop het ondertekeningsdomein van de selector zich verhoudt tot het domein in de `From:`-header.

Hoe DMARC-afstemming samenwerkt met DKIM

DMARC vereist dat ten minste één authenticatiemechanisme (SPF of DKIM) zowel de validatiecontrole doorstaat als overeenkomt met het domein in de `From:`-header.

Voor DKIM-afstemming moet het `d=`-domein in de DKIM-Signature-header overeenkomen met het domein in de `From:`-header. De selector zelf wordt niet geëvalueerd voor afstemming. Afstemming is uitsluitend gebaseerd op het `d=`-domein.

DMARC ondersteunt twee afstemmingsmodi:

De twee scenario’s waarin DKIM slaagt maar DMARC faalt

Een van de meest verwarrende uitkomsten bij e-mailverificatie is dat DKIM wordt goedgekeurd terwijl DMARC nog steeds faalt. Dit gebeurt meestal wanneer de handtekening zelf geldig is, maar het ondertekenende domein niet correct overeenkomt met het zichtbare ‘Van:’-domein dat in het bericht wordt gebruikt.

Scenario 1: Een externe e-mailprovider maakt gebruik van zijn eigen domein

Sommige e-mailproviders zullen, wanneer DKIM niet expliciet voor uw domein is geconfigureerd, uitgaande berichten ondertekenen met het eigen domein van de provider in `d=`. Een e-mail die bijvoorbeeld namens `[email protected]` wordt verzonden, kan een DKIM-handtekening bevatten met `d=esp-provider.com`.

De DKIM-verificatie is geslaagd (de handtekening is geldig), maar DMARC mislukt omdat `esp-provider.com` niet overeenkomt met `example.com`.

Stel DKIM-ondertekening in de e-maildienst in, zodat uw eigen domein in de `d=`-tag wordt gebruikt. Hiervoor moet u doorgaans de DKIM-selector van de e-maildienst als DNS-record onder uw domein toevoegen en aangepaste DKIM-ondertekening inschakelen in de instellingen van de e-maildienst.

Scenario 2: Onderdomeinondertekening met strikte DMARC-afstemming

Als je DMARC-beleid strikte afstemming gebruikt (`adkim=s`) en je e-mailprovider ondertekent met `d=sub.example.com`, terwijl het `From:`-adres `example.com` gebruikt, zal DMARC mislukken, ook al slaagt DKIM.

Schakel over naar een soepele afstemming (`adkim=r`, de standaardinstelling) of zorg ervoor dat het `d=`-domein in de DKIM-handtekening exact overeenkomt met het `From:`-domein.

Controle van de afstemming tussen meerdere ESP’s

In omgevingen met meerdere ESP’s kan elk verzendend platform met verschillende `d=`-domeinen ondertekenen. De ene ESP ondertekent mogelijk met uw hoofddomein, een andere met een subdomein, en een derde gebruikt standaard zijn eigen domein totdat u aangepaste ondertekening configureert.

De geaggregeerde DMARC-rapporten tonen het `d=`-domein en het afstemmingsresultaat voor elk bericht dat met DKIM is ondertekend. Bekijk deze rapporten om te zien of er e-maildienstverleners (ESP’s) zijn die berichten ondertekenen met een verkeerd afgestemd domein. De DMARC-rapporten van PowerDMARC geven per afzender aan waar de afstemming mislukt, waardoor u eenvoudig kunt vaststellen welke e-maildienstverlener opnieuw moet worden geconfigureerd.

Conclusie

De organisaties die het beheer van selectors beschouwen als een doorlopend operationeel proces, in plaats van als een eenmalige configuratietaak, zijn de organisaties die een consistente leverbaarheid garanderen, audits zonder problemen doorstaan en snel reageren op incidenten.

Als u meer dan een handvol domeinen beheert of met meerdere e-mailproviders werkt, is het de moeite waard om de zichtbaarheid van uw DKIM-selector te centraliseren.

PowerDMARC biedt dat gecentraliseerde overzicht door de analyse van geaggregeerde DMARC-rapporten, DNS-monitoring en gehost DKIM-beheer te combineren in één interface die speciaal is ontworpen voor dit soort operationele complexiteit.

Beheer DKIM-selectors eenvoudig voor meerdere e-mailproviders. Meld u aan voor een proefperiode om DKIM-records te monitoren, de DMARC-afstemming te verbeteren en de afleverbaarheid van e-mail te waarborgen.

FAQs

Hoe vind ik mijn DKIM-selector?

Je kunt je DKIM-selector vinden door de volledige headers van een e-mail te bekijken en de DKIM-Signature . De waarde achter s= is de selector. Bijvoorbeeld, in s=googleis de selector google.

Hoeveel DKIM-selectors kan een domein hebben?

Er is geen technische beperking op het aantal DKIM-selectors dat een domein kan hebben. Organisaties gebruiken vaak meerdere selectors tegelijk voor verschillende e-mailproviders, afdelingen of sleutelwisselperiodes.

Kunnen meerdere ESP’s verschillende DKIM-selectors gebruiken op hetzelfde domein?

Ja. Elke e-maildienstverlener gebruikt doorgaans zijn eigen DKIM-selector. Zo kunnen Google Workspace, SendGrid en Mailchimp bijvoorbeeld allemaal afzonderlijke selectors onder hetzelfde domein hebben zonder dat dit tot conflicten leidt.

Wat is het verschil tussen een DKIM-selector en een DKIM-sleutel?

De selector is het label dat wordt gebruikt om het DKIM-record in het DNS te vinden, terwijl de DKIM-sleutel het daadwerkelijke cryptografische paar van openbare en privésleutels is dat wordt gebruikt om e-mails te ondertekenen en te verifiëren.

Waarom wordt DKIM goedgekeurd, maar faalt DMARC nog steeds?

Dit komt meestal door een mislukte DMARC-afstemming. De DKIM-handtekening wordt misschien wel goedgekeurd, maar de d= domein in de DKIM-handtekening komt niet overeen met het From: domein dat in de e-mail wordt gebruikt.

Hoe vaak moeten DKIM-selectors en -sleutels worden vernieuwd?

Volgens beveiligingsrichtlijnen wordt aanbevolen om DKIM-sleutels om de 6 tot 12 maanden te vernieuwen. Tijdens het vernieuwen moeten zowel de oude als de nieuwe selectors tijdelijk actief blijven om te voorkomen dat er validatiefouten optreden tijdens de DNS-propagatie.