A DKIM signatur kan verificere med succes for en udbyders domæne uden at autentificere domænet, som en læser ser i Fra. Samlede rapporter bevare begge lag. Læs den rå signaturidentitet og resultat, før du fortolker det DKIM-relaterede DMARC resultat.
Start med hver indberettet signatur
Referencer: RFC 9990 §3.1.1.12, RFC 9990 §3.1.3.
Under auth_results/dkim, RFC 9990 identificerer signeringsdomænet, vælger og verifikationsresultat. Domænet svarer til d i DKIM-Signature og vælgeren til s. Hverken et venligt visningsnavn eller vælgeretiketten erstatter det domæne, der logger ind justering.
Beskeder kan bære flere signaturer. Man kan fejle efter indholdsændring, mens en anden verificerer, eller begge kan verificere under forskellige domæner. Undersøg de individuelle resultater i stedet for at vælge den første signatur, din grænseflade viser. Rapporter kan begrænse de signaturer, de inkluderer, så fravær fra en samlet post er ikke altid et bevis på, at en signatur aldrig har eksisteret.
Sammenlign signeringsdomænet med From
Referencer: RFC 9989 §4.4.1, RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
DMARC bruger forfatterdomænet fra det synlige Fra-felt og domænet for en vellykket verificeret DKIM signatur. Streng justering kræver et nøjagtigt domænematch. Afslappet justering bruger forholdet, der er defineret af organisationsdomæneopdagelse under de gældende regler. i-identiteten i en signatur erstatter ikke d for denne sammenligning.
En signatur, hvis domæne justeres, men hvis kryptografiske kontrol mislykkes, giver ikke en beståelse DKIM sti. Omvendt forbliver en gyldig signatur fra et ikke-relateret domæne ujusteret. Feltet policy_evaluated/dkim repræsenterer den DMARC-relaterede evaluering, ikke blot om nogen signatur er verificeret.
Gengiv resultatet i et syntetisk eksempel
Referencer: RFC 9989 §5.3.5.
Antag en gældende gyldig politik, gennemførte kontroller, urelaterede brand.example / vendor.example organisatoriske domæner og header_from= brand.example . Signatur man bruger d=vendor.example og verificerer. Signatur to bruger d=brand.example og mislykkes i sin body-hash-kontrol. Der er ingen vellykket justeret DKIM sti i dette eksempel, så en DKIM-relateret politikfejl er i overensstemmelse med den rå pass on signatur en.
Skift nu signatur tos resultat til at bestå, mens identiteterne bevares. Denne signatur giver nøjagtig justering, så DKIM stien kan opfylde DMARC uanset resultatet af den ikke-relaterede signatur. Disse er konstruerede tilfælde, ikke rigtige modtagermålinger. Inspicere SPF samt før fastlæggelse af det samlede DMARC resultat i det første tilfælde.
Reparer verifikation og justering separat
Referencer: RFC 6376 §6.1, RFC 9989 §5.4.
For en verifikationsfejl skal du undersøge den rapporterede signaturs nøgle, indholdsdækning og faktiske beskedbehandling. En body-hash-fejl repareres ikke blot ved at ændre Fra-adressen. For en verificeret, men ikke-justeret udbydersignatur, skal du fastslå, om tjenesten understøtter et tilpasset signeringsdomæne eller en anden tilpasset sti.
Gå ikke ud fra, at tilføjelse af en ekstra signatur reparerer en tidligere. Det skaber en anden uafhængigt evalueret vej. Det nyttige spørgsmål er, om mindst én understøttet, gyldig signatur justeres, ikke om enhver mulig signatur passerer.
Bevar råprøver og betroede modtagerresultater, når du løser tvetydige samlede beviser. Registrer d-domænet, vælgeren, verifikationsresultatet, justeringstilstanden og forfatterdomænet for hver testet rute. Hold disposition adskilt: Godkendelsessucces garanterer ikke levering, og en undtagelse for modtagerhåndtering gør ikke en mislykket signatur til en gyldig.
Behold sammenligningen med flere signaturer
To delvise syntetiske kort bruger header_from= brand.example , policy p=reject, afslappet justering og epokeinterval 1704067200–1704153600. Begge har rå SPF -pas for ikke-relateret vendor.example , så ingen af dem har justeret SPF . Den første har vendor.example /v1 DKIM pass plus brand.example /b1 DKIM fail. Dets afstemte DKIM resultat og det samlede DMARC resultat mislykkes. Den anden har vendor.example /v1 fail plus brand.example /b1 pass. Dets afstemte DKIM og overordnede DMARC resultater bestå.
Den medfølgende lokale identitetsøvelse gengiver disse resultater og holder vælgere knyttet til hver signatur. Modellen antager de leverede verifikationsresultater; den genberegner ikke signaturer eller tester DNS . Begge kort repræsenterer hver 25 observationer, ikke en målt trafikprøve. Deres dispositionsfelt forbliver leveret rapporteringskontekst snarere end en beregnet leveringsgaranti. Brug faktiske råmeddelelser til at validere denne kæde for en produktionsrute.
Hold øvelsen inden for rammerne
Eksemplerne er delvise feltprojektioner, ikke skemavalide rapporter eller målt trafik. Lokale kontroller bruger eksplicit leverede autentificeringsresultater og organisatoriske relationer; de udfører ikke DNS opdagelse, SPF evaluering, kryptografisk verifikation, rapportindtagelse eller test af modtagerlevering. Bevar den originale rapport og pålidelige meddelelsesbeviser, før du foretager en produktionsændring.