DKIM inriktning är en identitetsjämförelse efter framgångsrik signaturverifiering. Frågan är om domänen som tar ansvar genom DKIM motsvarar den domän som visas i meddelandets Från-fält. En giltig signatur från en icke-relaterad tjänst kan lämna den frågan obesvarad.
Extrahera rätt domänpar
Använd Author Domain från RFC5322 .Från fältet och d= domän från en framgångsrikt verifierad DKIM signatur. Ersätt inte Reply-To, Return-Path, den väljare eller det valfria i= identitet för signeringsdomänen i denna jämförelse. Bevara det råa budskapet och använd en betrodda mottagarens verifieringsresultat, snarare än att anta att en signatur är giltig eftersom den finns.
Till exempel ett meddelande som visas som Fakturering < billing@example.com > har example.com som dess författardomän i detta enkla enförfattarfall. En förbigående signatur med d=example.net autentiserar undertecknaren example.net; ordet Fakturering, en välbekant logotyp eller en identisk postlåda lokal del gör det inte anpassat till example.com.
Tillämpa den konfigurerade justeringsregeln
RFC 9989 avsnitt 4.4 definierar strikt anpassning som identiska domäner. Dess avslappnade regel jämför organisatoriska domäner som bestäms av tillämplig upptäcktsprocedure. DKIM justeringsläget väljs igenom adkim; relaxed är standard när den taggen saknas i en annars tillämplig policy.
En exakt d=example.com matcha med Author Domain example.com uppfyller strikt anpassning och undviker också tvetydigheter om deras förhållande. En signatur från mail.example.com är inte en strikt matchning till example.com. Dess avslappnade status kräver beslutsamhet inom organisationsdomänen; behandla inte varje överordnad-underdomän-relation som automatiskt tillräcklig under alla möjliga policykonfigurationer.
RFC 9989 avsnitt 4.10 ersätter RFC 7489s upptäcktsmodell med DNS Tree Walks för upptäckt av organisationsdomäner. Äldre implementeringar kan fortfarande använda den tidigare offentliga suffix-baserade processen. Registrera vilken specifikation och mottagarbeteende din diagnos adresserar. En avvikelse från en övergångsera kräver bevis om upptäckt och policy, inte ett generellt påstående om att en DNS skärmdump beskriver varje mottagare.
Arbeta igenom ett explicit avslappnat exempel
Antag att den tillämpliga regeln är lättad och mottagaren bestämmer organisatorisk domän av båda mail.example.com och example.com att vara example.com. En förbigående signatur med d=mail.example.com överensstämmer sedan med en Author Domain of example.com. Under strikt läge skulle samma par inte passa.
Ändra endast signaturresultatet till att misslyckas. Domänrelationen har inte ändrats, men den tillhandahåller inte längre en DKIM-autentiserad identifierare. Meddelandet har därför inget DKIM -passbidrag från den signaturen. En separat anpassad SPF pass kunde fortfarande ge en DMARC sökväg, så dra inte slutsatsen att hela meddelandet misslyckas utan att utvärdera det.
Det är syntetiska fall med uttalade antaganden. I en liveundersökning, registrera den upptäckta policyn, anpassningsläget, relevant DNS bevis och mottagarresultat. Detta gör slutsatsen reproducerbar istället för att minska justeringen till en suffixmatchande genväg.
Korrigera avsändarkonfigurationen vid dess källa
Om tjänsten endast signerar med sin egen orelaterade domän, avgör om dess nuvarande produkt stöder en lämplig kundsigneringsidentitet. Skaffa de genererade posterna och aktivera signering genom den process som stöds. Publicering av a DMARC -post ändrar inte tjänstens d= värde, och att lägga till en leverantör till SPF ändrar inte en DKIM signatur.
När strikt läge är avsett, verifiera exakt domänsignering för varje relevant rutt innan du ändrar policyn. Försvaga inte anpassningen bara för att dölja en ohanterad sändningstjänst. Anta inte heller att strikt läge är kostnadsfritt: dokumentera vilka legitima underdomänsigneringsrutter som det utesluter och det operativa beslutet bakom den begränsningen.
Verifiera den korrigerade rutten
Skicka igenom själva applikationen och fånga sedan den godkända signaturen, dess domän och den betrodda mottagarens DMARC bedömning. Granska alla signaturer om det finns fler än en; RFC 9989 avsnitt 4.4.1 accepterar alla passerade justerade DKIM identifierare. Ett test från en annan postlåda eller hyresgäst kan använda en annan identitet och kan inte stänga problemet med det berörda programmet.
Håll anpassning och leveransresultat åtskilda. Korrigeringen är bevisad när den avsedda avsändaren producerar en giltig anpassad identitet enligt tillämplig policy. Placeringen av inkorgen beror fortfarande på mottagarens bredare beslut.
Jämför tre syntetiska resultat
Anta Author Domain example.com och en tillämplig policy. En passerande signatur med d=example.com justeras i båda lägena. En godkänd signatur med d=mail.example.com misslyckas med strikt justering; den justeras i avslappnat läge endast under det angivna antagandet att båda organisationsdomänerna är example.com . En passerande signatur med d=vendor.example.net justeras inte i något av lägena när dess organisationsdomän är example.net . I varje fall, utvärdera andra signaturer och SPF innan du bestämmer det övergripande DMARC resultatet. Dessa är exempel på domänjämförelse, inte fångade mottagarresultat.
Håll en kompakt utredningsjournal
Använd detta föreslagna arbetsblad för rutten som granskas. Det är ett planeringshjälp, inte bevis på ett utfört test.
- Meddelande: applikationsväg, referens för råmeddelanden och betrodd verifierande mottagare.
- Identitet: Författardomän och varje passerande DKIM d-domän.
- Policy: upptäckt DMARC policy, adkim och mottagarens upptäcktsmodell.
- Slutsats: strikt eller avslappnad matchning, andra DKIM / SPF -vägar och separat registrerat leveransresultat.
Relaterad läsning
Flera DKIM signaturer: hitta den justerade passerande signaturen · DKIM TXT och CNAME publicering: följ leverantörens nyckelhanteringsmodell.