Kartlägg de beslut som postsystemen faktiskt fattar
En användbar e-postberoendekarta kopplar en företagssändande tjänst till de identiteter, DNS poster och transporttjänster som den använder. En lista över varje TXT post är inte tillräckligt. Kartan bör låta en ägare svara på vad som kan gå sönder om en leverantör, värdnamn, nyckel eller policy ändras, och identifiera de bevis som behövs innan ändringen godkänns.
Behåll utgående identitetsautentisering och inkommande transportpolicy som separata grenar. De kan dela administratörer och domäner, men de skyddar inte samma beslut. Kartan som föreslås här är en operativ modell som en organisation måste fylla i från sin egen auktoriserade inventering och meddelandebevis. Det är inte ett påstående att en DNS skanning kan upptäcka varje avsändare eller fastställa alla mottagarbeteende.
Starta varje utgående gren med en riktig sändningsrutt
Skapa en post för varje tjänst och materiellt distinkt väg, inklusive periodisk fakturering, supportsystem och externt hanterade kampanjer. Registrera dess företagsägare, tekniska ägare, synliga författaredomän, kuvertdomän, sändningsinfrastruktur och observerad DKIM signeringsdomän och väljare. Markera varje värde som observerat, dokumenterat av leverantören eller fortfarande okänt. Förvandla inte en leverantörs allmänna installationsguide till ett bevis på detta kontos konfiguration.
De SPF filial börjar med den utvärderade identiteten och följer de policyvillkor som faktiskt är relevanta för den vägen. Inkludera externa policyreferenser och de team som kontrollerar dem. RFC 7208 avsnitt 2.3 och 4.6.4 förklara identitetsutvärdering och DNS-beroende gränser. En beroendekarta kan visa var externa förändringar kan påverka utvärderingen, men ett statiskt antal noder fastställer inte resultatet för varje anslutande adress.
DKIM grenen börjar med signaturens d- och s-värden och leder till väljarens verifieringspost. Lägg till valfritt aliasmål, målzonsägare och nyckellivscykelägare. RFC 6376 avsnitt 3.6.2.1 definierar denna uppslagsnamnrymd. Håll privata nycklar borta från kartan; registrera säkert operativt ägande och referera till ett godkänt nyckelhanteringssystem istället.
Anslut autentisering till relevant DMARC beslut
Lägg till Author Domain, tillämpligt DMARC policydokument och bevis för hur policyn upptäcktes. Länk som skickar autentiserade identifierare till inriktning beslut, med strikt eller avslappnat läge identifierat. Under RFC 9989 avsnitt 4.4, en giltig justerad SPF eller DKIM identifierare kan uppfylla DMARC ; två orelaterade autentiseringspass kan inte upprätta justering.
Anteckna specifikations- och implementeringskontexten som används för bedömning av policyupptäckt. RFC 9989 beskriver en DNS -trädvandring, så ett ärvt kalkylarksantagande om upptäckt bör granskas snarare än att föras vidare i tysthet. Kartan bör bibehålla osäkerhet om mottagare vars implementering inte har verifierats. Inkludera rapporteringsdestinationer och deras ägande, men håll rapporteringen åtskild från bevis på att alla legitima avsändare har observerats.
Visa ägarens begärda policy och mottagarens observerade hantering i olika fält. Detta gör det svårare för en framtida granskare att missta en policysträng som bevis på att ett meddelande har avvisats, levererats eller placerats i en inkorg.
Lägg till den oberoende transportgrenen
För inkommande e-post ansluter du mottagardomänen till dess MX värdar och deras adressberoende. Om MTA-STS är distribuerad, lägg till upptäckts- TXT posten, HTTPS-policyvärd, certifikatunderhållsägare, publicerat läge, tillåtna MX namn och policylivslängd. RFC 8461 avsnitt 3 och 6 beskriv upptäckt och cachning. Policylivslängden är inte samma fält som DNS TTL, och att ändra den ena skrivs inte direkt om den andra.
Där DANE SMTP är utplacerad, kartlägg DNSSEC kedja, MX upplösning, TLSA poster och motsvarande TLS tjänst. RFC 7672 avsnitt 2 gör autentiserad DNS till ett centralt beroende. En TLSA-post som kopierats till inventariet utan dess validerings- och certifikatförhållande är ofullständiga operativa bevis.
Lägg till TLS -rapportering som en observationskanal, inte som en verkställighetsmekanism. RFC 8460 avsnitt 3 definierar upptäckt av rapporteringspolicy. Den rapporterande destinationen behöver en ägare och en översynsprocess, medan själva transportpolicyn förblir ett tydligt beroende.
Fiktivt fungerat exempel på en leverantörsmigrering
Den fiktiva organisationen Example Repairs planerar att flytta fakturapost till en ny leverantör. Dess föreslagna karta länkar fakturatjänst till billing.example.com som författaredomän, en separat kuvertdomän och en gammal DKIM väljare som är värd via ett alias. Migreringsägaren märker att den pensionerade leverantören fortfarande kontrollerar aliasmålet och att vissa meddelanden i kö kan ha den gamla signaturen.
Granskningen föreslår därför en etappvis skyltningsändring, verifiering av ersättningsvägen och ett särskilt godkänt pensionsbeslut. Under tiden förblir inkommande MX och MTA-STS -poster en annan gren och redigeras inte automatiskt som en del av en utgående leverantörsflytt. Detta exempel är uppfunnit; identiteter, godkännanden och meddelanderesultat har inte erhållits från ett riktigt konto.
Fördelen med kartan är frågan som den avslöjar: vilka bevis tillåter att det aliaset dras tillbaka utan att bryta verifieringen för legitima meddelanden? Kartan i sig svarar inte på det. Tjänsteägaren måste tillhandahålla kö- och signeringsinformation, och granskaren måste koppla dessa fakta till den föreslagna ändringen.
Upprätthåll bevis och ägande med kartan
Ge varje kant ett senast verifierat datum, bevisreferens, ägare och recensionsutlösare. Besök det igen efter en leverantörsmigrering, väljarrotation, delegeringsändring, transportpolicyredigering eller oförklarat autentiseringsfel. Okända ägare och overifierade kanter bör förbli synliga istället för att fyllas med gissningar.
Före lansering, bygg beredskapsmatrisen avsändare för avsändare, exakt policyskillnad och godkännandepost. Efter auktoriserad exekvering, bifoga relevant meddelande och DNS observationer. Det är katalogens nödvändiga originalföremål och förblir öppna här. Det här manuskriptet tillhandahåller en kartdesign och en fiktiv beslutsövning, inte en fylld hyresgästinventering eller verifierad utbyggnad.