En udgående sikkerhedsgateway eller firmasignaturtjeneste kan inspicere og ændre e-mail, efter at applikationen allerede har underskrevet den. En stald DKIM design placerer det endelige autoriserede signeringstrin efter nødvendige indholdsændringer og verificerer hele ruten. Det vigtige spørgsmål er, hvilken komponent der udsender den endelige besked, ikke hvilket produkt der først viser en aktiveret DKIM indstilling.
Tegn den faktiske behandlingsrækkefølge
Kortindsendelse, indholdsinspektion, ansvarsfraskrivelse eller signaturindsættelse, MIME serialisering, DKIM signering og ekstern levering. Inkluder alternative ruter, der bruges af applikationer og nød-failover. Antag ikke medarbejder-postkasse-mail og ansøgnings-mail tager samme vej.
For hver komponent skal du registrere, om den ændrer brødteksten, valgte overskrifter, kuvertidentitet eller kun routing-metadata. En virksomheds e-mailsignaturblok er kropsindhold; det er ikke relateret til det kryptografiske DKIM-Signature header på trods af det delte ord "signatur". URL-omskrivning, håndtering af vedhæftede filer og HTML-genopbygning kan også påvirke dækket indhold.
RFC 6376 §5.3 og RFC 6376 §5.5 kræve, at underskriveren opererer på den tilsigtede overførte repræsentation og ændrer underskrivere til at foretage ændringer, før de genunderskriver. Designet skal gøre denne sekventering synlig og testbar.
Vælg domæne og nøgleejer
En gateway kan tilføje en gyldig signatur under sit eget domæne. Det tilfredsstiller ikke automatisk DKIM justering for dit forfatterdomæne under RFC 9989 §4.4.1. Hvis det påkrævede design bruger brugerdefineret domænesignering, skal du kontrollere produktets dokumenterede kapacitet, genererede DNS værdier og opbevaring af den private nøgle. Må ikke opfinde vælger navngive eller kopiere en anden lejers konfiguration.
Beslut hvem der kan ændre signeringskonfiguration, rotere nøgler og ændre den endelige indholdspipeline. Beskyt private nøgler mod eksport til hændelsesnotater eller testpakker. Udgivelse af en offentlig nøgle er kun en del af opsætningen; reelle udgående meddelelser skal have en matchende signatur oprettet efter den endelige behandling.
Test rørledningen med to kontroller
Illustrativt design A tegner først og tilføjer derefter en virksomhedskontaktblok. Den originale helkropssignatur kan fejle. Design B indsætter blokken, fuldfører MIME serialisering og signerer derefter med et autoriseret tilpasset domæne. Den tilsigtede signatur kan overleve, hvis senere behandling efterlader dækkede data intakte. Disse er testforventninger, ikke en påstand om en navngiven leverandør.
Send almindelig tekst, HTML, ikke-ASCII-indhold og en vedhæftet fil gennem den tilsigtede rute. Inkluder applikationsgenererede meddelelser og en understøttet failover-rute, hvor det er relevant. Indfang meddelelsen efter den sidste processor og på en betroet ekstern modtager. Knyt hvert resultat til d og s i stedet for at acceptere en udifferentieret beståelsesetiket.
Hold sikkerhedskontrol i designet
Flytning af signering senere bør ikke stille flytte inspektion uden for den beskyttede arbejdsgang eller omgå påkrævet scanning. Hvis den endelige underskriver ikke kan køre efter en obligatorisk omskrivningstjeneste, skal du evaluere understøttede integrationer eller en anden autoriseret signeringsgrænse. Undgå at bruge l til at udelukke senere indhold blot for at producere et antal beståelser; RFC 6376 §8.2 forklarer risici med usigneret indhold.
En nedstrøms ny signatur kan eksistere side om side med en tidligere mislykket signatur. Bekræft, hvilken signatur der giver den tilsigtede justering, og hvordan den modtagende service rapporterer det. Slet ikke beviser for den tidligere fejl fra testregistreringer.
Betjen grænsen som en forandringsstyret tjeneste
Bevar rutediagrammet, ansvarlige ejere, nøglebevaringsplan og formattestsuite. Gentest efter gateway-opgraderinger, branding-skabelonændringer, routingændringer og failover-aktivering. Succes kræver det tilsigtede indhold, en gyldig tilpasset godkendelsessti og korrekt levering, med menneskelig godkendelse stadig adskilt fra det tekniske resultat.
Optag den næste beslutning
For en hypotetisk meddelelse, optag processorrækkefølge, forventede indholdsændringer, hvert d/s-par, modtagerbedømmelse og justering. Hvis gatewayen kun signerer som et ikke-relateret leverandørdomæne, skal du markere justeret DKIM som uløst, selvom dens signatur godkendes. Hvis flytning af underskriveren ville omgå inspektionen, skal du stoppe denne designændring og søge en understøttet integration. Disse er planlægningskriterier, ikke udførte rutetest.