En förälder DMARC policy kan fastställa hur mottagare ska hantera viss underdomänpost som misslyckas med autentisering. Den kan inte berätta vilken applikation som skickar det e-postmeddelandet, vem som har godkänt det eller om en viktig aviseringstjänst fortfarande fungerar. Dessa frågor kräver en avsändarinventering kopplad till mottagna meddelandebevis.
Distinktionen har betydelse under verkställigheten. En DNS kontroll kan visa en skyddspolicy på organisationens huvuddomän medan en gammal kampanjplattform använder en explicit underordnad policy, ett dotterbolag kontrollerar sitt eget namnområde eller en lösenordsåterställningstjänst autentiserar med en icke-relaterad leverantörsidentitet. Journalen och inventeringen svarar på olika frågor.
Börja med den domän som mottagaren ser
För varje arbetsflöde, fånga domänen i meddelandets Från-adress. Byt inte ut webbplatsdomänen, kontots inloggningsdomän eller e-postleverantörens varumärke. Identifiera sedan tillämplig policy, den SPF-utvärderade identiteten och DKIM signeringsdomän eller domäner.
Under nuvarande DMARC upptäckt har en tillämplig post som hittas specifikt för författarens domän företräde framför reserv till organisatorisk domän eller offentligt suffix. Den nuvarande specifikationen använder en DNS -trädvandring. En närmaste förälder är inte automatiskt den tillämpliga organisationsgränsen. Se RFC 9989 §4.10.1.
Ditt lager bör därför registrera den upptäckta policydomänen, inte bara en kryssruta märkt "omfattas av förälder". Anteckna också vilken mottagare eller utvärderare som används och testdatum. Äldre implementeringar kan använda äldre upptäcktsbeteende, så en dokumentär beräkning etablerar inte universell distribution.
Jämför tre subdomänfall
Följande är en syntetisk illustration, inte en observerad kundkonfiguration. Antag example.com är organisationsdomänen väljer discovery sin post när det inte finns någon underordnad post och dess post innehåller p=reject; sp=quarantine; np=reject. Versionstaggen utelämnas från denna mening endast för läsbarheten; ett verkligt policyregister måste börja med v=DMARC1.
- Författare Domänfall: Befintlig
billing.example.com, utan explicit DMARC -post; Tillämplig policy i detta exempel: Föräldersp=quarantineför misslyckad post; Vad inventeringen fortfarande måste fastställa: Vilket faktureringsarbetsflöde som skickar, dess ägare och ett mottaget meddelandes anpassade autentiseringsresultat - Författare Domänfall: Ej existerande
unused.example.com, utan uttrycklig policy; Tillämplig policy i detta exempel: Föräldernp=rejectför misslyckad post; Vad inventeringen fortfarande måste fastställa: om det verkligen inte finns i DNS och om något legitimt arbetsflöde oväntat använder det - Författare Domänfall: Befintlig
news.example.com, med sin egenv=DMARC1; p=nonespela in; Tillämplig policy i detta exempel: Det explicita barnetp=nonepolitik; Vad inventeringen fortfarande måste fastställa: Vem äger det undantaget, varför det finns och när det kommer att omvärderas
I alla tre fallen kan en passerande anpassad identitet producera DMARC pass. Policykolumnen beskriver begärd hantering av fel, inte ett kommando för att avvisa varje meddelande från domänen. Mottagarens beslut förblir separata under RFC 9989 §5.4. De sp och np urvalsreglerna specificeras i RFC 9989 , avsnitt 4.10.1.
En delegerad DNS zon är ett annat inventeringsobjekt, inte bevis på en explicit DMARC -policy. Registrera vem som kontrollerar den och testa upptäckten från dess faktiska författardomäner. Dra inte slutledning av organisatoriska gränser från ditt företagsdiagram.
Koppla varje avsändare till en företagsägare
Bygg en rad per meningsfullt sändningsarbetsflöde. En enskild applikation kan behöva separata rader för kampanjer, transaktionsmeddelanden och medarbetarutlösta meddelanden om de använder olika identiteter eller rutter.
Behåll åtminstone arbetsflödet, ansvarig ägare, författaredomän, kuvertdomän, signeringsdomän och väljare, sändningstjänst, tillämplig policy, senaste test och pensionsvillkor. Lägg till bevisplatsen och eventuella olösta problem. En namngiven leverantör utan ett identifierat kundkonto eller företagsägare förblir en utredningsledare, inte godkänd sändande myndighet.
Använda samlade rapporter för att hitta observerad trafik och jämföra den med det registret. Under RFC 9990 §3.1 och RFC 9989 §5.3.8, rapporter beskriver trafik som ses av deltagande mottagare; frånvaro från en rapport är inte ett bevis på att ett månatligt eller sällan använt arbetsflöde inte existerar. Be applikationsägare att använda lösenordsåterställningar, kvitton, varningar och schemalagda jobb medvetet.
Ändra policy mot inventeringen
Innan du ändrar den överordnade policyn, identifiera raderna som kommer att ärva ändringen och raderna med oberoende underordnad policy. Tilldela testning till sina ägare. En säker granskning frågar om legitim e-post förblir autentiserad och justerad, om undantag är motiverade och om återställning kan begränsas till det berörda arbetsflödet.
Undvik att försvaga den överordnade policyn bara för att en applikations konfiguration är ofullständig. Fastställ först om tjänsten kan använda en anpassad signeringsdomän som stöds. Om ett undantag är nödvändigt, dokumentera dess omfattning, godkännare, utgångsdatum och verifieringsplan. Behandla det som ett explicit riskbeslut snarare än att tyst dölja avsändaren från inventeringen.
Efter ändringen jämför du nya meddelanderesultat och rapporter med raderna före ändringen. Håll policydiff och bevis tillsammans. Stäng ändringen endast när de berörda företagsägarna bekräftar sina verkliga arbetsflöden och olösta avsändare har en namngiven nästa åtgärd.
Håll försäkringsskyddet och avsändartäckningen åtskilda
En användbar instrumentpanel har två mått: domäner med en verifierad tillämplig policy, och företag som skickar arbetsflöden med en nuvarande ägare och testad anpassad rutt. Att förbättra det ena förbättrar inte automatiskt det andra. Använd avsändarens inventeringsguide för verksamhetsregistret och den guide för underdomänpolicy för upptäcktsdetaljer.
Gör nästa beslut tydligt
För fixturen med tre domäner, gruppfakturering enligt den ärvda sp-policyn, oanvänd enligt den antagna tillämpliga np-policyn, och nyheter enligt dess explicita p-policy. En förändring av föräldra-sp ska inte beskrivas som att ändra den explicita nyhetspolicyn. Håll varje arbetsflödesägare och bevisgap åtskilda. Detta är en konsekvens av de angivna upptäcktsantagandena, inte en levande trädvandring eller godkännande att ändra policy.