Det mest pålidelige sted at finde en DKIM vælger er den DKIM-Signature overskriften på den meddelelse, du undersøger. Læs s=-værdien og par den med d=-signeringsdomænet fra den samme signatur.
Vælgeren identificerer, hvor verifikationsmateriale offentliggøres. Den identificerer ikke den synlige afsender eller beviser, at signaturen har bestået. Denne vejledning følger beviserne fra en modtaget besked til det korrekte DNS navn, og forklarer derefter, hvad opslaget kan og ikke kan fastslå.
Få den oprindelige modtagne besked
Brug en kontrolleret besked sendt gennem den aktuelle tjeneste til en separat modtager. Bevar den oprindelige meddelelse som modtaget der. Et videresendt skærmbillede eller en gengemt, redigeret besked kan udelade eller ændre beviser.
Find hver DKIM-Signature header. En besked kan indeholde mere end én. For hver signatur skal du registrere dens signeringsdomæne og vælger separat, og derefter korrelere den betroede modtagers bekræftelsesresultat.
- d: signering af domæne.
- s: vælger.
- a: signering/hash-algoritme.
- h: valgt underskrevet-header-liste.
- bh og b: kropshash og signaturværdier, ikke DNS public-key records.
Disse felter er defineret af RFC 6376 §3.5.
Erstat ikke det synlige Fra-domæne med d= når du bygger nøgleopslaget. Justering er en senere sammenligning mellem den forbigående signaturidentitet og den synlige From-identitet.
Konstruer og forespørg efter bekræftelsesnavnet
Under RFC 6376 §3.6.2.1, kombinerer bekræftelsesnavnet de to værdier fra den samme signatur:
<vælger>. _domainkey .<signeringsdomæne>
I dette syntetiske eksempel identificerer signaturen:
Den syntetiske signatur har d=example.com og s=mail2026.
Det tilsvarende opslag er:
dig TXT mail2026._domainkey.example.com +noall +svar
Hvis en udbyder uddelegerer nøglestyring gennem en CNAME, undersøg også den kæde:
dig CNAME mail2026._domainkey.example.com +noall +svar
Disse er illustrative DNS -tjek, ikke verifikation af en fanget rigtig besked. Brug de faktiske signaturværdier. Under RFC 1034 §3.6.2, for et offentliggjort alias, følg det tilsigtede mål og fastslå, at verifikationsdataene er tilgængelige gennem kæden.
Offentlig DNS indeholder verifikationsnøglematerialet eller den delegation, der fører til det. Den private signeringsnøgle hører hjemme i det autoriserede signeringssystem, ikke i en TXT post.
Fortolk opslaget sammen med bekræftelsesresultaterne
Et offentligt nøglesvar viser, at en resolver kan hente bestemt verifikationsmateriale på det tidspunkt. Det beviser ikke, at en meddelelse indeholder en signatur, at den tilsvarende private nøgle blev brugt korrekt, eller at signeret indhold forblev intakt.
Hvis nøglen findes, men signaturen mislykkes, skal du undersøge det komplette verifikationsresultat. Indholdsændringer, forkerte eller inkompatible nøgledata, signaturdækning, tidsrelaterede forhold og DNS observationer kan kræve forskellige løsninger.
Hvis der ikke findes nogen nøgle, skal du kontrollere den nøjagtige d= og s=, den autoritative zone, CNAME målet, nøgleudtrækningshistorik og resolverfejl. Udgiv ikke en gættet vælger blot for at gøre en ternet grøn.
Hvis originalen ikke har nogen relevant DKIM signatur, kan en vælgersøgning ikke fremstille signatur. Tjek, om den faktiske afsender er konfigureret til at underskrive, om tjenesten understøtter den nødvendige identitet, og om en senere rute ændrede beviserne.
Håndtere flere signaturer og nøglerotation
Lav en separat række for hver signatur og dens pålidelige resultat. En tjenestes egen passerende signatur kan være ujusteret, mens en kundedomænesignatur passerer tilpasningen. En anden besked kan have en mislykket kundedomænesignatur og kun en ikke-relateret videregivelse.
For rotation skal du kontrollere, hvilken vælger den rigtige besked brugte, ikke blot hvilke to poster der er tilgængelige i DNS . Bevar forholdet mellem konfigurationstilstand, signering cutover og meddelelser, der allerede er i transit. En gammel vælgers tilbagetrækning kan påvirke senere bekræftelse af gemte eller forsinkede beskeder.
Til Microsoft 365 skal du bruge lejerspecifik opsætningsvejledning. Til Workspace skal du bruge vejledning til opsætning af valgt domæne. Ingen af udbydernes fælles vælgermønster bør erstatte læsning af de faktiske beviser.
Bekræft tilmelding på den faktiske tjeneste
Hvis en leverandør siger, at dit domæne har DKIM konfigureret, skal du bede den om at vise en besked sendt af den relevante arbejdsgang og det domæne, der rent faktisk signerede den. En offentligt synlig nøgle er én konfigurationsafhængighed, ikke bevis for livesignering.
Dette har betydning, når flere værktøjer bruger det samme synlige mærke. Medarbejdermail, supportbilletter og kvitteringer kan have forskellige vælgere, signeringsdomæner og ejere. Et vellykket tjek på én kan ikke stå for resten.
Hold styr på underskrivelse af ejerskab og delegering
Hold en vælgerbeholdning knyttet til service, domæne, nøglestyringsmodel og virksomhedsejer. Skelne direkte kontrol af en nøgle fra delegation til en udbyder. Gennemgå delegationen, når en tjeneste er offboardet.
Begræns adgang til privat nøgle og definer svaret på et mistænkt kompromittering. En gyldig offentlig registrering er ikke et bevis på, at nøgledepotet er forsvarligt. På samme måde etablerer en gyldig signatur en påstand på domæneniveau over dækket indhold; den godkender ikke en betalingsanmodning eller udelukker kompromittering af kontoen.
Den nyttige beviskæde er besked, signaturidentitet, nøgleopslag, betroet verifikation og justering. Hold disse observationer sammen, så den næste anmelder kan gengive diagnosen.
Den praktiske takeaway
Hold den originale besked, signaturidentiteter, DNS observation og betroede modtagerresultater sammen. Dette bevis adskiller en manglende nøgle fra en usigneret meddelelse, en mislykket signatur eller en signatur, der passerer, men ikke justeres.
Anvend sondringen
Med to hypotetiske signaturer, d=example.com/s=mail2026 og d=service.example.net/s=outbound, forespørg mail2026._domainkey.example.com og outbound._domainkey.service.example.net separat. Kombiner aldrig mail2026 med den anden d. Hold hver opslagstid og et pålideligt resultat sammen med dets par. En senere manglende nøgle sletter ikke en tidligere betroet modtagerobservation.