En melding med flere DKIM signaturer trenger en vurdering per signatur. Å telle signaturene eller velge det første beståtte resultatet kan feilidentifisere domenet som autentiserte den synlige forfatteren. Under RFC 9989 §4.4.1, kan enhver bestått DKIM-autentisert identifikator som er på linje med forfatterdomenet levere DKIM banen til DMARC pass.
Bevar identiteten til hvert resultat
Eksporter råmeldingen gjennom en godkjent prosess. Ta opp det synlige Fra-domenet og, for hver signatur, dets d= signering av domene, s= velger, a= algoritme og relevant kanonisering innstillinger. Knytt det pålitelige mottakssystemets resultat til den signaturen. To signaturer kan bruke samme domene, men forskjellige velgere eller algoritmer, slik at domenet alene ikke kan skille dem.
Ikke stol på en vilkårlig Authentication-Results feltet bare fordi det vises i meldingen. RFC 8601 §1.2 forklarer tillitsgrensen for disse feltene. Bruk resultater som kan tilskrives mottakssystemet hvis vurdering du undersøker, og bevar denne kilden når du eksporterer bevis. En avsender kan sette inn villedende overskriftstekst; en kopiert statusetikett er ikke en uavhengig bekreftelse.
Behold verifisering og justering som separate avgjørelser
Verifikasjon fastslår om en signatur validerer for signeringsdomenet. Justering sammenligner det autentiserte domenet med forfatterdomenet under gjeldende DMARC regel. En ikke-relatert leverandørs signatur kan være helt gyldig uten å autentisere forfatterens synlige domene for DMARC .
For streng DKIM justering må domenene samsvare nøyaktig, med sammenligning av domenenavn-tilfeller RFC 1035 §2.3.3. Avslappet justering bruker deres organisasjon-domene-forhold som bestemt av den gjeldende DMARC prosessen. RFC 9989 §4.10.2 definerer DNS Tree Walks for denne bestemmelsen. Ikke avgjør justering fra et vanlig ord i to domenenavn, og ikke anta stille at hver mottaker har tatt i bruk den nyeste oppdagelsesimplementeringen.
Arbeid gjennom en syntetisk melding
Anta en gyldig gjeldende DMARC policy, et forfatterdomene til example.com og ikke justert SPF pass. Signatur A bruker d=example.net, verifiserer vellykket og justerer ikke. Signatur B bruker d=example.com men mislykkes verifiseringen etter en nedstrøms innholdsendring. Ingen av dem gir en justert bestått DKIM identitet, så denne kombinasjonen produserer ikke DMARC pass.
Legg nå til signatur C med d=example.com som bekrefter vellykket. Den justeres nøyaktig, så den leverer DKIM banen til DMARC passet. Det urelaterte passet og den mislykkede signaturen kansellerer ikke automatisk C. Dette er en illustrerende evaluering, ikke en påstand om en fanget kundemelding eller garantert postboksplassering.
Skriv eksemplet i separate kolonner i undersøkelsesposten din: signaturidentifikator, verifiseringsresultat, justeringsresultat og bidrag til DMARC . Kombiner aldri signatur A sitt pass med signatur B sitt justerte domene for å produsere et resultat ingen individuell signatur oppnådd.
Forklar hvorfor det er flere signaturer
Parallelle algoritmer, en leverandørs operasjonelle signatur og en mellommanns senere signatur kan alle skape flere resultater. Dette er hypoteser inntil ruten og signerkonfigurasjonen fastslår årsaken. RFC 8463 §6 beskriver distinkte velgere for RSA og Ed25519 overgangssignaturer; resultatene deres bør spores individuelt.
Hvis en gateway signerer modifisert e-post på nytt, inspiser det nye domenet. En passerende gateway-signatur reparerer ikke automatisk den opprinnelige forfatterens autentisering. Der organisasjonen kontrollerer det siste signeringsstadiet, verifiser at den signerer det tiltenkte etterbehandlingsinnholdet under en godkjent identitet. Ikke fjern en tilsynelatende overflødig signatur uten å sjekke dens operasjonelle formål.
Avslutt med konklusjonen på meldingsnivå
Etter å ha vurdert alle relevante DKIM signaturer, evaluer SPF autentiserte identifikator og justering separat. Hvis ingen gjeldende DMARC policy blir oppdaget, må du ikke ommerke situasjonen som en normal DMARC feil. Skille autentiseringsresultater fra mottakerens endelige disposisjon, som kan gjenspeile ytterligere policy eller filtrering.
Behold den opprinnelige meldingen, pålitelig resultatkilde, per-signaturanalyse og årsaken til den endelige konklusjonen. Hvis rapporteringsverktøy aggregerer signaturer annerledes, sammenligne deres råbevis før du behandler ulike sammendrag som en protokollmotsigelse. Det nyttige resultatet er en forklarbar identitetsvei, ikke bare et større antall grønne indikatorer.
Ta opp eksemplet uten å blande identiteter
For den syntetiske meldingen ovenfor, behold én rad per signatur:
- A: example.net ; verifisering pass; justering nr; DKIM bidrag til DMARC nr.
- B: example.com ; verifisering mislykkes; domene vil samsvare, men er ikke autentisert; DKIM bidrag nr.
- C: example.com ; verifisering pass; justering ja; DKIM bidrag ja.
Før C er tilstede, etterlater det oppgitte fraværet av justert SPF ingen passeringsbane. Med C til stede, går DMARC under de antatt gjeldende retningslinjene. Ingen faktiske mottakerresultater eller resultat av innboksplassering gjøres krav på.
Relatert lesing
DKIM justering: sammenlign d= med det synlige Fra-domenet · RSA og Ed25519 DKIM -signaturer: distribusjonsspørsmål og interoperabilitet.