Kortlæg de beslutninger, som mailsystemer rent faktisk træffer
Et nyttigt e-mail-afhængighedskort forbinder en virksomhedssendetjeneste med de identiteter, DNS poster og transporttjenester, den bruger. En liste over hver TXT post er ikke nok. Kortet skal lade en ejer svare på, hvad der kan gå i stykker, hvis en udbyder, værtsnavn, nøgle eller politik ændres, og identificere de nødvendige beviser, før denne ændring godkendes.
Behold udgående identitetsgodkendelse og indgående transportpolitik som separate filialer. De kan dele administratorer og domæner, men de beskytter ikke den samme beslutning. Kortet, der foreslås her, er en operationel model, som en organisation skal udfylde fra sin egen autoriserede opgørelse og meddelelsesbevis. Det er ikke en påstand, at en DNS scanning kan opdage hver afsender eller bestemme al modtageradfærd.
Start hver udgående filial med en rigtig afsendelsesrute
Opret én indgang for hver tjeneste og væsentligt adskilt rute, inklusive periodisk fakturering, supportsystemer og eksternt administrerede kampagner. Registrer dens virksomhedsejer, tekniske ejer, synlige forfatterdomæne, kuvertdomæne, afsendelsesinfrastruktur og observeret DKIM underskrive domæne og vælger. Marker hver værdi som observeret, dokumenteret af udbyderen eller stadig ukendt. Gør ikke en leverandørs generiske opsætningsvejledning til bevis for denne kontos konfiguration.
De SPF filial begynder med den evaluerede identitet og følger de politiske vilkår, der faktisk er relevante for den rute. Medtag eksterne politikreferencer og de teams, der kontrollerer dem. RFC 7208 afsnit 2.3 og 4.6.4 forklare identitetsevaluering og DNS-afhængige grænser. Et afhængighedskort kan vise, hvor eksterne ændringer kan påvirke evalueringen, men en statisk optælling af noder etablerer ikke resultatet for hver forbindelsesadresse.
DKIM grenen begynder med signaturens d- og s-værdier og fører til vælgerens verifikationspost. Tilføj ethvert alias-mål, mål-zone-ejer og nøgle-livscyklus-ejer. RFC 6376 afsnit 3.6.2.1 definerer dette opslagsnavneområde. Hold private nøgler væk fra kortet; registrere sikkert operationelt ejerskab og henvise til et godkendt nøglestyringssystem i stedet.
Tilslut godkendelse til den relevante DMARC beslutning
Tilføj Author Domain, relevant DMARC politikregistrering og beviserne for, hvordan politik blev opdaget. Link videregivelse af godkendte identifikatorer til justering beslutning, med streng eller afslappet tilstand identificeret. Under RFC 9989 afsnit 4.4, kan en gyldig justeret SPF eller DKIM identifikator opfylde DMARC ; to ikke-relaterede godkendelsesgennemgange kan ikke etablere justering.
Registrer specifikations- og implementeringskonteksten, der bruges til vurdering af politikopdagelse. RFC 9989 beskriver en DNS trævandring, så en nedarvet regnearksantagelse om opdagelse bør gennemgås i stedet for stille videreføres. Kortet bør bevare usikkerhed om modtagere, hvis implementering ikke er blevet verificeret. Inkluder rapporteringsdestinationer og deres ejerskab, men hold rapportering tilgængelighed adskilt fra beviser på, at hver legitim afsender er blevet observeret.
Vis ejerens ønskede politik og modtagerens observerede håndtering i forskellige felter. Dette gør det sværere for en fremtidig anmelder at forveksle en politikstreng som bevis på, at en meddelelse er blevet afvist, leveret eller placeret i en indbakke.
Tilføj den uafhængige transportgren
For indgående mail skal du forbinde modtagerdomænet til dets MX værter og deres adresseafhængigheder. Hvis MTA-STS er implementeret, skal du tilføje Discovery TXT posten, HTTPS-politikværten, certifikatvedligeholdelsesejeren, offentliggjort tilstand, tilladte MX navne og politiklevetid. RFC 8461 afsnit 3 og 6 beskrive opdagelse og caching. Politikens levetid er ikke det samme felt som DNS TTL, og ændring af den ene omskriver ikke direkte den anden.
Hvor DANE SMTP er implementeret, kortlæg DNSSEC kæde, MX opløsning, TLSA optegnelser og den tilsvarende TLS tjeneste. RFC 7672 afsnit 2 gør autentificeret DNS til en central afhængighed. En TLSA-post, der er kopieret til inventaret uden dens validering og certifikatforhold, er ufuldstændig operationel dokumentation.
Tilføj TLS -rapportering som en observationskanal, ikke som en håndhævelsesmekanisme. RFC 8460 afsnit 3 definerer opdagelse af rapporteringspolitik. Rapporteringsdestinationen har brug for en ejer og en gennemgangsproces, mens den faktiske transportpolitik forbliver en udpræget afhængighed.
Fiktivt udført eksempel på en udbydermigrering
Den fiktive organisation Example Repairs planlægger at flytte fakturapost til en ny leverandør. Dets foreslåede kort linker fakturaservice til billing.example.com som forfatterdomænet, et separat kuvertdomæne og en gammel DKIM vælger hostet gennem et alias. Migrationsejeren bemærker, at den pensionerede udbyder stadig kontrollerer alias-målet, og at nogle meddelelser i kø kan bære den gamle signatur.
Gennemgangen foreslår derfor en etapevis skiltningsforandring, verifikation af erstatningsruten og en særskilt godkendt tilbagetrækningsbeslutning. I mellemtiden forbliver indgående MX og MTA-STS -poster en anden gren og redigeres ikke automatisk som en del af en udgående leverandørflytning. Dette eksempel er opfundet; identiteterne, godkendelserne og beskedresultaterne er ikke hentet fra en rigtig konto.
Fordelen ved kortet er spørgsmålet, det afslører: hvilke beviser tillader tilbagetrækning af dette alias uden at bryde bekræftelsen af legitime beskeder? Selve kortet svarer ikke på det. Tjenesteejeren skal levere kø- og underskriftsoplysninger, og anmelderen skal forbinde disse fakta med den foreslåede ændring.
Oprethold beviser og ejerskab med kortet
Giv hver kant en sidste verificeret dato, bevisreference, ejer og anmeldelsesudløser. Besøg det igen efter en leverandørmigrering, vælgerrotation, ændring af delegation, redigering af transportpolitik eller uforklarlig godkendelsesfejl. Ukendte ejere og ubekræftede kanter bør forblive synlige i stedet for at være fyldt med gæt.
Inden udrulning skal du opbygge afsender-for-sender-beredskabsmatrix, nøjagtige politikforskelle og godkendelsesregistrering. Efter autoriseret udførelse skal du vedhæfte den relevante meddelelse og DNS observationer. Det er katalogets påkrævede originale artefakter og forbliver åbne her. Dette manuskript giver et kortdesign og en fiktiv beslutningsøvelse, ikke en udfyldt lejerbeholdning eller verificeret udrulning.