En besked med flere DKIM underskrifter kræver en per-signatur vurdering. At tælle signaturerne eller vælge det første beståede resultat kan fejlidentificere det domæne, der autentificerede den synlige forfatter. Under RFC 9989 §4.4.1, kan enhver DKIM-godkendt identifikator, der passerer med forfatterdomænet, levere DKIM stien til DMARC passere.
Bevar identiteten af hvert resultat
Eksporter den rå besked gennem en godkendt proces. Optag det synlige Fra-domæne og, for hver signatur, dets d= signering af domæne, s= vælger, a= algoritme og relevant kanonisering indstillinger. Knyt det betroede modtagende systems resultat til den signatur. To signaturer kan bruge det samme domæne, men forskellige vælgere eller algoritmer, så domænet alene kan ikke skelne dem.
Stol ikke på en vilkårlig Authentication-Results felt, blot fordi det vises i meddelelsen. RFC 8601 §1.2 forklarer tillidsgrænsen for disse felter. Brug resultater, der kan henføres til det modtagende system, hvis vurdering du undersøger, og bevar denne kilde, når du eksporterer bevis. En afsender kan indsætte vildledende overskriftstekst; en kopieret statuslabel er ikke en uafhængig verifikation.
Behold verifikation og tilpasning som separate beslutninger
Verifikation fastslår, om en signatur validerer for sit signeringsdomæne. Justering sammenligner det autentificerede domæne med forfatterdomænet i henhold til den gældende DMARC regel. En ikke-relateret udbyders signatur kan være fuldkommen gyldig uden at godkende forfatterens synlige domæne for DMARC .
For streng DKIM tilpasning skal domænerne matche nøjagtigt, med sammenligning af domænenavne efter tilfælde RFC 1035 §2.3.3. Afslappet justering bruger deres organisation-domæne-forhold som bestemt af den gældende DMARC proces. RFC 9989 §4.10.2 definerer DNS Tree Walks for denne bestemmelse. Beslut ikke justering fra et almindeligt ord i to domænenavne, og antag ikke stille og roligt, at hver modtager har taget den nyeste opdagelsesimplementering til sig.
Arbejd igennem et syntetisk budskab
Antag en gyldig gældende DMARC politik, et forfatterdomæne af example.com og ikke justeret SPF passere. Signatur A bruger d=example.net, verificerer med succes og justerer ikke. Signatur B bruger d=example.com men mislykkes verifikationen efter en downstream-indholdsændring. Ingen af dem leverer en tilpasset DKIM identitet, så denne kombination producerer ikke DMARC -pas.
Tilføj nu signatur C med d=example.com der verificeres med succes. Den justeres nøjagtigt, så den leverer DKIM stien til DMARC passet. Det ikke-relaterede pass og mislykkede signatur annullerer ikke automatisk C. Dette er en illustrativ evaluering, ikke en påstand om en fanget kundebesked eller garanteret postkasseplacering.
Skriv eksemplet i separate kolonner i din undersøgelsespost: signaturidentifikator, verifikationsresultat, tilpasningsresultat og bidrag til DMARC . Kombiner aldrig signatur A's pass med signatur B's tilpassede domæne for at fremstille et resultat, som ingen individuel signatur opnåede.
Forklar hvorfor der er flere signaturer
Parallelle algoritmer, en udbyders operationelle signatur og en mellemmands senere signatur kan alle skabe flere resultater. Disse er hypoteser, indtil ruten og underskriverkonfigurationen fastslår årsagen. RFC 8463 §6 beskriver forskellige vælgere for RSA og Ed25519 overgangssignaturer; deres resultater skal spores individuelt.
Hvis en gateway signerer ændret e-mail igen, skal du inspicere dets nye domæne. En passerende gateway-signatur reparerer ikke automatisk den originale forfatters godkendelse. Hvis organisationen kontrollerer det sidste underskriftstrin, skal du kontrollere, at den underskriver det tilsigtede efterbehandlingsindhold under en godkendt identitet. Fjern ikke en tilsyneladende overflødig signatur uden at kontrollere dens operationelle formål.
Afslut med konklusionen på meddelelsesniveau
Efter at have vurderet alle relevante DKIM signaturer, skal du evaluere SPF 's autentificerede identifikator og justering separat. Hvis der ikke opdages en relevant DMARC politik, skal du ikke ommærke situationen som en normal DMARC fejl. Skelne godkendelsesresultater fra modtagerens endelige disposition, som kan afspejle yderligere politik eller filtrering.
Behold den originale meddelelse, pålidelig resultatkilde, per-signaturanalyse og årsagen til den endelige konklusion. Hvis rapporteringsværktøjer samler signaturer forskelligt, skal du sammenligne deres rå bevis, før du behandler forskellige resuméer som en protokolmodsigelse. Det nyttige resultat er en forklarlig identitetssti, ikke blot et større antal grønne indikatorer.
Optag eksemplet uden at blande identiteter
For den syntetiske meddelelse ovenfor, behold en række pr. signatur:
- A: example.net ; verifikation pass; linjeføring nr; DKIM bidrag til DMARC nr.
- B: example.com ; verifikation mislykkes; domæne ville matche, men er ikke godkendt; DKIM bidrag nr.
- C: example.com ; verifikation pass; justering ja; DKIM bidrag ja.
Før C er til stede, efterlader det angivne fravær af justeret SPF ingen gennemløbsvej. Med C til stede passerer DMARC under den formodede gældende politik. Der gøres ingen krav på faktiske modtagerresultater eller indbakkeplacering.
Relateret læsning
DKIM justering: sammenlign d= med det synlige From-domæne · RSA og Ed25519 DKIM signaturer: implementeringsspørgsmål og interoperabilitet.