Den mest pålitliga platsen att hitta en DKIM väljare är den DKIM-Signature rubriken för meddelandet du undersöker. Läs s=-värdet och koppla ihop det med d=-signeringsdomänen från samma signatur.
Väljaren identifierar var verifieringsmaterialet publiceras. Den identifierar inte den synliga avsändaren eller bevisar att signaturen passerade. Den här guiden följer bevisen från ett mottaget meddelande till det korrekta DNS namnet, och förklarar sedan vad uppslagningen kan och inte kan fastställa.
Få det ursprungliga mottagna meddelandet
Använd ett kontrollerat meddelande som skickas via den faktiska tjänsten till en separat mottagare. Bevara det ursprungliga meddelandet som mottaget där. En vidarebefordrad skärmdump eller ett återsparat, redigerat meddelande kan utelämna eller ändra bevis.
Leta reda på varje DKIM-Signature huvud. Ett meddelande kan innehålla mer än ett. För varje signatur, registrera dess signeringsdomän och väljare separat, och korrelera sedan den betrodda mottagarens verifieringsresultat.
- d: signeringsdomän.
- s: väljare.
- a: signerings-/hashalgoritm.
- h: vald lista med signerad rubrik.
- bh och b: body hash och signaturvärden, inte offentliga DNS -nyckelposter.
Dessa fält definieras av RFC 6376 §3.5.
Ersätt inte den synliga From-domänen d= när du bygger nyckelsökningen. Inriktning är en senare jämförelse mellan den passerande signeringsidentiteten och den synliga From-identiteten.
Konstruera och fråga efter verifieringsnamnet
Under RFC 6376 §3.6.2.1, kombinerar verifieringsnamnet de två värdena från samma signatur:
<väljare>. _domainkey .<signeringsdomän>
I detta syntetiska exempel identifierar signaturen:
Den syntetiska signaturen har d=example.com och s=mail2026.
Motsvarande uppslag är:
dig TXT mail2026._domainkey.example.com +noall +answer
Om en leverantör delegerar nyckelhantering genom en CNAME, inspektera den kedjan också:
gräva CNAME mail2026._domainkey.example.com +noall +svar
Dessa är illustrativa DNS kontroller, inte verifiering av ett fångat verkligt meddelande. Använd de faktiska signaturvärdena. Under RFC 1034 §3.6.2, för ett publicerat alias, följ det avsedda målet och fastställa att verifieringsdata är tillgänglig genom kedjan.
Offentlig DNS innehåller verifieringsnyckelmaterialet eller delegeringen som leder till det. Den privata signeringsnyckeln hör hemma i det auktoriserade signeringssystemet, inte i en TXT post.
Tolka uppslagningen tillsammans med verifieringsresultaten
Ett svar med publik nyckel visar att en resolver kan hämta visst verifieringsmaterial vid den tidpunkten. Det bevisar inte att ett meddelande innehåller en signatur, att motsvarande privata nyckel användes korrekt eller att signerat innehåll förblev intakt.
Om nyckeln finns men signaturen misslyckas, undersök det fullständiga verifieringsresultatet. Innehållsförändringar, felaktiga eller inkompatibla nyckeldata, signaturtäckning, tidsrelaterade förhållanden och DNS observationer kan kräva olika åtgärder.
Om ingen nyckel hittas, kontrollera den exakta d= och s=, den auktoritativa zonen, CNAME -målet, historik för nyckelpensionering och lösarefel. Publicera inte en gissad väljare bara för att göra en rutig grön.
Om originalet inte har någon relevant DKIM signatur kan en väljarsökning inte tillverka signatur. Kontrollera om den faktiska avsändaren är konfigurerad att signera, om tjänsten stöder den nödvändiga identiteten och om en senare rutt ändrade bevisningen.
Hantera flera signaturer och nyckelrotation
Gör en separat rad för varje signatur och dess betrodda resultat. En tjänsts egen passerande signatur kan vara ojusterad, medan en kunddomänsignatur klarar anpassningen. Ett annat meddelande kan ha en misslyckad kunddomänsignatur och bara en icke-relaterad passerande.
För rotation, kontrollera vilken väljare det verkliga meddelandet använde, inte bara vilka två poster som är tillgängliga i DNS . Bevara förhållandet mellan konfigurationstillstånd, signeringsövergång och meddelanden som redan skickas. En gammal väljares pensionering kan påverka senare verifiering av sparade eller försenade meddelanden.
För Microsoft 365 , använd hyresgästspecifik installationsguide. För Workspace, använd installationsguide för vald domän. Ingendera leverantörens gemensamma väljarmönster bör ersätta att läsa de faktiska bevisen.
Bekräfta signering på den faktiska tjänsten
Om en leverantör säger att din domän har DKIM konfigurerat, be den att visa ett meddelande som skickats av det relevanta arbetsflödet och domänen som faktiskt signerade det. En offentligt synlig nyckel är ett konfigurationsberoende, inte bevis på livesignering.
Detta har betydelse när flera verktyg använder samma synliga varumärke. Anställdas e-post, supportbiljetter och kvitton kan ha olika väljare, signeringsdomäner och ägare. En lyckad kontroll av en kan inte stå för resten.
Håll koll på undertecknande av ägande och delegering
Håll ett väljarlager kopplat till tjänst, domän, nyckelhanteringsmodell och företagsägare. Skilj direkt kontroll av en nyckel från delegering till en leverantör. Granska delegationen när en tjänst är avstängd.
Begränsa åtkomst till privat nyckel och definiera svaret på en misstänkt kompromiss. Ett giltigt offentligt register är inte ett bevis på att nyckelförvaring är sund. På liknande sätt upprättar en giltig signatur ett påstående på domännivå över täckt innehåll; den godkänner inte en betalningsbegäran eller utesluter kontokompromettering.
Den användbara beviskedjan är meddelande, signaturidentitet, nyckelsökning, pålitlig verifiering och anpassning. Håll dessa observationer tillsammans så att nästa granskare kan återskapa diagnosen.
Den praktiska takeawayen
Behåll originalmeddelandet, signaturidentiteter, DNS observation och betrodd mottagarresultat tillsammans. Det beviset skiljer en saknad nyckel från ett osignerat meddelande, en misslyckad signatur eller en signatur som går igenom men inte stämmer överens.
Tillämpa distinktionen
Med två hypotetiska signaturer, d=example.com/s=mail2026 och d=service.example.net/s=outbound, fråga mail2026._domainkey.example.com och outbound._domainkey.service.example.net separat. Kombinera aldrig mail2026 med den andra d. Håll varje uppslagstid och pålitligt resultat vid sidan av sitt par. En senare saknad nyckel raderar inte en tidigare betrodd mottagarobservation.