Bedöm den uppdaterade specifikationen, inte en ny versionssträng
“DMARCbis beredskap” är en användbar projektetikett endast om den identifierar de faktiska specifikationerna och implementeringarna som jämförs. RFC 9989 är den uppdaterade DMARC kärnspecifikation publicerad i maj 2026. RFC 9990 specificerar separat aggregerad rapportering. Dessa är publicerade standardspår-RFC:er, inte en anledning att uppfinna ett nytt DNS versionsvärde. Policyposten börjar fortfarande med v=DMARC1. RFC 9989 , avsnitt 4.7 och RFC 9990 , avsnitt 2.
En agent kan utarbeta ett standardkopplat gapregister och acceptplan. Det kan inte dra slutsatsen att varje mottagare, rapporteringsbibliotek eller EmailAuth distribution implementerar det uppdaterade beteendet. Den här artikeln beskriver en föreslagen bedömning, utan produktinspektion, DNS ändring eller utfört acceptanstest.
Inventera de komponenter som fattar beslutet
Lista avsändarens författaredomäner, policyposter, sändningsidentiteter, rapportdestinationer och relevanta programvaruversioner. Identifiera vilka komponenter som upptäcker policy, utvärdera inriktning, generera rapporter, analysera rapporter och visa resultat. En instrumentpanel kan använda en aktuell etikett medan ett underliggande bibliotek fortfarande följer äldre upptäcktsbeteende. Omvänt kan en mottagare implementera nyare utvärdering utan att producera den exakta rapporteringsdetalj som en analytiker förväntar sig.
Ge varje komponent en ägare och en beviskälla. Ett leverantörsuttalande, en konfigurationsexport och ett kontrollerat acceptansresultat etablerar olika saker. Anteckna vad som faktiskt inspekterades och vad som bara hävdas. Markera inte en hel organisation som klar eftersom en parser accepterar en ny exempelfil eller för att en domän redan publicerar v=DMARC1.
Jämför policy och beteende för domänupptäckt
RFC 9989 ersätter public Suffix List-baserad organisationsdomänbestämning med den angivna DNS Tree Walk, inklusive överväganden om Public Suffix Domain. Dess ändringssammanfattning noterar uttryckligen att äldre och uppdaterade implementeringar kan nå olika resultat. En beredskapsplan bör jämföra representativa domänhierarkier, explicita författare-domänpolicyer och relevanta underdomänfall under de avsedda implementeringarna. RFC 9989 , avsnitt 4.10 och bilaga C.3.
Minska inte detta till "agenten går uppåt tills den hittar ett rekord.” Algoritmen har definierade beslut och frågegränser. Bedömningen bör koppla varje förväntat resultat till den relevanta regeln och bevara det faktiska DNS svarskontext som används av testet. Hypotetiska domänträd kan hjälpa till att designa fall, men de är inte bevis på att en produktionsmottagare följer samma algoritm.
Stämma av taggändringar utan att gissa mottagaren
Den uppdaterade kärnan tar bort pct, rf och ri från dess policy-record-taggset och lägger till np, psd och t. t-taggen bär testande semantik; det är inte en ersättningsnummer för numerisk procentsats. En agent bör flagga äldre antaganden om partiell efterlevnad snarare än att automatiskt översätta en procentandel till en ny policy som inte stöds. RFC 9989 , Bilaga A.6 och C.5.
Det faktum att en tagg ändrats i specifikationen bevisar inte en viss leverantörs implementerade tolkning. Om ett leverantörsdokument beskriver äldre beteende, behåll dess datum och omfattning och begär aktuellt tillämplighetsbevis. Skriv inte om en liveskiva bara för att en checklista för efterlevnad ska se modern ut. Varje föreslagen taggändring kräver en konsekvensbedömning för den faktiska mottagande populationen och ett separat godkänt test eller utbyggnad.
Inkludera verksamhetspolitiska överväganden
Beredskap är inte synonymt med publicering p=reject överallt. RFC 9989 :s interoperabilitetsdiskussion tar upp legitima indirekta flöden, inklusive allmänna användare som deltar i e-postlistor, och beskriver mottagarens ansvar utöver den publicerade policyn. Inkludera dessa flöden i gapregistret istället för att behandla dem som obekväma misslyckanden att dölja. RFC 9989 , avsnitt 7.4 och bilaga C.6.
För en fiktiv organisation kan en underdomän för endast kvitton och en anställdkorrespondensdomän behöva olika acceptansfall och policybeslut. Bedömningen skulle identifiera både populationer och ägare som kan utvärdera deras avvägningar. Det skulle inte anta att ett resultat på kvittotflödet bevisar att korrespondensdomänen kan anta samma policy utan operativa konsekvenser.
Bedöm rapportering som ett separat implementeringsberoende
RFC 9990 definierar struktur för aggregerade rapporter, identifierare, dubbletthantering, rapportering av policyändringar och verifiering av externa destinationer. Testa rapportkonsumentens format och beteende mot lämpliga fixturer, inklusive felaktiga eller dubbla indata under en säker testplan. En XML-tolkare som accepterar en fil är inte ett bevis på att antal, identiteter och policyfält tolkas korrekt. RFC 9990 , avsnitt 3, 4 och 8.
Håll syntetiska armaturer märkta. En påhittad samlad rapport kan testa en parser men kan inte fastställa verkligt mottagarbeteende eller leveransresultat. Extern rapportdirigering kräver också organisatoriskt godkännande för destinationen, separat från protokollets tekniska behörighetskontroll. En beredskapsövning bör inte tyst omdirigera produktionsrapporter eller ge en ny processor tillgång till befintliga data.
Få varje lucka att leda till ett beslut och ett reproducerbart test
Det föreslagna registret bör innehålla krav, standardavsnitt, påverkad komponent, observerat beteende, förväntat beteende, osäkerhet, ägare och acceptansbevis. En lucka kan kräva en mjukvaruuppdatering, ett förtydligat leverantörsåtagande, en auktoriserad konfigurationsändring eller ingen åtgärd eftersom ärendet inte gäller. "Okänd" är att föredra framför ett pass som inte stöds.
För följdändringar, håll förberedelser åtskilda från utförande och låt handlingsvägen upprätthålla omfattning och godkännande. OWASP:s auktoriseringsvägledning betonar att kontrollera tillstånd för varje begäran; en agents övergripande projektuppdrag bör inte ersätta auktoritet över varje hyresgäst eller DNS post. OWASP auktorisation fuskblad.
Kräv godkännandebevis innan du hävdar beredskap
Kräv ett standardkopplat gapregister och reproducerbara acceptansresultat. Detta exakta driftsättningskrav förblir öppet. Kartan nedan är en dokumentär registermall. Aktuella EmailAuth funktioner, mottagareantagande, implementeringsversioner, godkända ändringar och reproducerbara resultat har inte fastställts. Standardforskning definierar vad som ska undersökas; det intygar inte att det är beredskap för driftsättning.