De meest betrouwbare plek om een DKIM selector is de DKIM-Signature koptekst van het bericht dat u onderzoekt. Lees de s=-waarde en koppel deze aan het d=-ondertekeningsdomein uit diezelfde handtekening.
De selector identificeert waar verificatiemateriaal wordt gepubliceerd. Het identificeert niet de zichtbare afzender en bewijst niet dat de handtekening is geslaagd. Deze handleiding volgt het bewijs van een ontvangen bericht tot de juiste DNS naam en legt vervolgens uit wat de zoekopdracht wel en niet kan vaststellen.
Haal het origineel ontvangen bericht op
Gebruik een gecontroleerd bericht dat via de daadwerkelijke service naar een afzonderlijke ontvanger wordt verzonden. Bewaar het originele bericht zoals het daar is ontvangen. Een doorgestuurd screenshot of een opnieuw opgeslagen, bewerkt bericht kan bewijsmateriaal weglaten of wijzigen.
Zoek elke DKIM-Signature header. Een bericht kan er meer dan één bevatten. Registreer voor elke handtekening het ondertekeningsdomein en de selector afzonderlijk en correleer vervolgens het verificatieresultaat van de vertrouwde ontvanger.
- d: ondertekeningsdomein.
- s: keuzeschakelaar.
- a: ondertekening/hash-algoritme.
- h: geselecteerde lijst met ondertekende kopteksten.
- bh en b: lichaam hasj en handtekeningwaarden, niet DNS -records met openbare sleutels.
Deze velden worden gedefinieerd door RFC 6376 §3.5.
Vervang niet het zichtbare Van-domein door d= bij het bouwen van de sleutelzoekopdracht. Uitlijning is een latere vergelijking tussen de passerende handtekeningidentiteit en de zichtbare Van-identiteit.
Construeer en bevraag de verificatienaam
Onder RFC 6376 §3.6.2.1, combineert de verificatienaam de twee waarden van dezelfde handtekening:
<selector>. _domainkey .<ondertekeningsdomein>
In dit synthetische voorbeeld identificeert de handtekening:
De synthetische handtekening heeft d=example.com en s=mail2026.
De bijbehorende zoekopdracht is:
dig TXT mail2026._domainkey.example.com +noall +antwoord
Als een aanbieder het sleutelbeheer delegeert via een CNAME, inspecteer ook die ketting:
dig CNAME mail2026._domainkey.example.com +noall +antwoord
Dit zijn illustratieve DNS controles, geen verificatie van een vastgelegd echt bericht. Gebruik de werkelijke handtekeningwaarden. Onder RFC 1034 §3.6.2Volg voor een gepubliceerde alias het beoogde doel en stel vast dat de verificatiegegevens via de keten beschikbaar zijn.
Publieke DNS bevat het verificatiesleutelmateriaal of de delegatie die ernaartoe leidt. De privé ondertekeningssleutel hoort thuis in het geautoriseerde ondertekensysteem, niet in een TXT record.
Interpreteer de zoekopdracht naast de verificatieresultaten
Een antwoord met een publieke sleutel laat zien dat een oplosser op dat moment bepaald verificatiemateriaal kan ophalen. Het bewijst niet dat een bericht een handtekening bevat, dat de bijbehorende privésleutel correct is gebruikt of dat de ondertekende inhoud intact is gebleven.
Als de sleutel bestaat maar de handtekening mislukt, onderzoek dan het volledige verificatieresultaat. Inhoudswijzigingen, verkeerd opgemaakte of incompatibele sleutelgegevens, dekking van handtekeningen, tijdgerelateerde omstandigheden en DNS observaties kunnen verschillende oplossingen vereisen.
Als er geen sleutel wordt gevonden, controleer dan de exacte d= En s=, de gezaghebbende zone, het CNAME doel, de geschiedenis van het buiten gebruik stellen van sleutels en fouten in de oplosser. Publiceer geen geraden selector alleen maar om een blokje groen te maken.
Als het origineel geen relevante DKIM handtekening heeft, kan een selectorzoekopdracht geen handtekening produceren. Controleer of de daadwerkelijke afzender is geconfigureerd om te ondertekenen, of de dienst de vereiste identiteit ondersteunt en of een latere route het bewijsmateriaal heeft gewijzigd.
Verwerk meerdere handtekeningen en sleutelroulatie
Maak een aparte rij voor elke handtekening en het vertrouwde resultaat. De eigen handtekening van een dienst is mogelijk niet uitgelijnd, terwijl een handtekening van een klantdomein de uitlijning doorstaat. Een ander bericht bevat mogelijk een mislukte klantdomeinhandtekening en alleen een niet-gerelateerde handtekening.
Controleer voor rotatie welke selector het echte bericht heeft gebruikt, en niet alleen welke twee records beschikbaar zijn in DNS . Behoud de relatie tussen de configuratiestatus, de ondertekeningsovergang en berichten die al onderweg zijn. Het buiten gebruik stellen van een oude selector kan van invloed zijn op de latere verificatie van opgeslagen of vertraagde berichten.
Voor Microsoft 365 gebruikt u de huurderspecifieke installatiehandleiding. Gebruik voor Werkruimte de installatiegids voor het geselecteerde domein. Het gebruikelijke selectiepatroon van geen van beide aanbieders mag het lezen van het feitelijke bewijsmateriaal vervangen.
Bevestig het aanmelden bij de daadwerkelijke service
Als een leverancier zegt dat uw domein dat heeft DKIM geconfigureerd, vraag hem dan om een bericht weer te geven dat is verzonden door de relevante workflow en het domein dat het daadwerkelijk heeft ondertekend. Een openbaar zichtbare sleutel is een configuratieafhankelijkheid en geen bewijs van live ondertekening.
Dit is van belang als meerdere tools hetzelfde zichtbare merk gebruiken. E-mail van medewerkers, ondersteuningstickets en ontvangstbewijzen kunnen verschillende selectors, ondertekeningsdomeinen en eigenaren hebben. Een succesvolle controle op één kan de rest niet vervangen.
Houd het eigendom en de delegatie van handtekeningen bij
Houd een selectorinventaris bij die is gekoppeld aan de service, het domein, het sleutelbeheermodel en de bedrijfseigenaar. Maak onderscheid tussen directe controle over een sleutel en delegatie aan een provider. Controleer de delegatie wanneer een service buiten gebruik wordt gesteld.
Beperk de toegang tot privésleutels en definieer de reactie op een vermoedelijk compromis. Een geldig openbaar register is geen bewijs dat de sleutelbewaring correct is. Op dezelfde manier zorgt een geldige handtekening voor een bewering op domeinniveau over de gedekte inhoud; het keurt een betalingsverzoek niet goed en sluit geen rekeningcompromis uit.
De bruikbare bewijsketen bestaat uit berichten, handtekeningidentiteit, sleutelopzoeking, vertrouwde verificatie en afstemming. Houd deze observaties bij elkaar, zodat de volgende recensent de diagnose kan reproduceren.
De praktische afhaalmaaltijd
Houd het originele bericht, de handtekeningidentiteiten, DNS observatie en het resultaat van de vertrouwde ontvanger bij elkaar. Dat bewijs onderscheidt een ontbrekende sleutel van een niet-ondertekend bericht, een mislukte handtekening of een handtekening die wel slaagt maar niet op één lijn ligt.
Pas het onderscheid toe
Met twee hypothetische handtekeningen, d=example.com/s=mail2026 en d=service.example.net/s=outbound, kunt u mail2026._domainkey.example.com en outbound._domainkey.service.example.net afzonderlijk doorzoeken. Combineer mail2026 nooit met de tweede d. Bewaar elke opzoektijd en het vertrouwde resultaat naast het bijbehorende paar. Een latere ontbrekende sleutel wist een eerdere waarneming van een vertrouwde ontvanger niet.