DMARCbis ändrar hur delar av DMARC specificeras och genomförs. Den ber dig inte att byta namn på din post till DMARC2. Kärnspecifikationen, RFC 9989, publicerades i maj 2026, medan RFC 9990 och RFC 9991 täcka sammanlagd rapportering och felrapportering separat.
Den praktiska uppgiften är att ta reda på vilka ändringar som påverkar din domän, dina sändningstjänster och programvaran som behandlar din autentiseringsdata. Det börjar med att förstå de nuvarande specifikationerna och sedan jämföra dem med konfigurationen och processerna som redan används. Resultatet ska bli ett tydligt beredskapsregister med bevis, ägare och beslut för varje fynd.
Mappa de tre specifikationerna till dina system
Använd de aktuella dokumenten för sina respektive jobb:
| Dokumentera | Vad ska granskas |
|---|---|
| RFC 9989 | Grundläggande DMARC -utvärdering, policyupptäckt, inriktning och spela in semantik |
| RFC 9990 | Aggregat rapporteringsformat, generering och bearbetning |
| RFC 9991 | Felanmälan och dess hanteringsöverväganden |
Börja med den befintliga posten och konfigurationshistoriken. Ta inte bort en driftpost bara för att en äldre guide citerar RFC 7489. Identifiera instruktionerna som ändrades och programvaran som implementerar dem.
De viktigaste granskningsområdena inkluderar följande:
- Domän upptäckt: RFC 9989 avsnitt 4.10 definierar DNS trädvandring. Granska system som antar en äldre upptäcktsmodell med offentlig suffixlista.
- Policytaggar: Kontrollera det aktuella IANA registret. De
pct,rfochritaggar är historiska. Bedömat,npochpsdav deras faktiska omfattning snarare än att lägga till dem som en checklista för uppgradering. - Testning: Fastställ hur den relevanta utvärderaren implementerar binären
tsignal. Ett deklarerat testläge och en mottagares slutliga disposition är olika observationer. - Rapportering: Bekräfta att samlare och analyserare hanterar de rapportformat och fält som du förväntar dig att få, utan att förlora relevanta äldre observationer.
Versionsmarkören finns kvar v=DMARC1. Ersätt inte DMARC2 eller mekaniskt ersätta en gammal procentsats med en testflagga.
Översätt de ändrade taggarna till tester
De t flaggan är som standard n, och begär tillämpning av den deklarerade bedömningen på DMARC fel. Miljö t=y signalerar att ägaren testar snarare än att begära att den deklarerade bedömningen ska tillämpas direkt. RFC 9989 avsnitt 4.7 definierar en minskning på en nivå för misslyckade meddelanden: avvisa blir karantän och karantän blir ingen. Implementeringar kan också ha relevant specialhantering.
Flaggan ändrar inte ett misslyckat autentiseringsresultat till ett godkänt, ändrar rapportgenerering eller påverkar inte en none-policy. Det är binärt, inte en begäran om att ta prov på en godtycklig procentandel av posten. Upprätta implementeringsstöd innan du litar på det för verklig trafik, och håll mottagarens lokala filtrering åtskild från testresultatet på policynivå.
Två andra taggar påverkar omfattningen av bedömningen:
- np: Anger bedömningen för icke-existerande underdomäner av den rådande organisatorisk domän. Om den saknas är den tillämpliga reservfunktionen sp när den finns, annars sid. En saknad MX post ensam etablerar inte icke-existens.
- psd: Markerar domängränsinformation som används under upptäckten. Standardvärdet u lämnar gränsbestämningen till upptäcktsreglerna; y identifierar ett offentligt suffix, medan n identifierar en icke-offentligt suffix organisationsgräns för sig själv och dess underdomäner. Ställ inte in något av de explicita gränsvärdena utan att fastställa att det beskriver domänen korrekt.
En vanlig organisation bör inte märka sin domän som ett offentligt suffix bara för att hävda beredskap. Granska faktiska upptäcktsantaganden och delegerade namnutrymmen. De guide för underdomänpolicy täcker den snävare arvsfrågan.
Identifiera posten som måste fortsätta fungera
En domän kan representera mycket mer än anställdas e-post. Det kan visas på fakturor, inloggningslänkar, kundvarningar och meddelanden som skickas av externa byråer. En standarduppdatering är en möjlighet att kontrollera dessa beroenden innan en förhastad konfigurationsändring stör dem.
Be om tre leveranser: en inventering av tjänsterna som använder din identitet, en förklaring av de specifika förändringar som påverkar dig och en testplan för viktiga meddelanden. Svaret bör skilja en publicerad specifikation från en funktion som redan används av en viss mottagare eller mjukvarutjänst.
Fördela ägande samt budget. En rapportbearbetningsändring behöver någon som är ansvarig för rapporteringspipelinen. En avsändare som inte kan autentisera korrekt behöver sin företagare involverad. Att kalla båda objekten för en DNS uppgradering döljer arbetet.
Bygg ett beredskapsregister
Följande är ett illustrativt planeringsregister, inte en bedömning av en verklig domän:
| Fynd | Arbete krävs | Bevis på färdigställande |
|---|---|---|
| Instruktioner för utrullning förutsätter procentuellt urval | Testa den binära flaggan med de kontrollerade fixturerna nedan | Inspelad deklarerad bedömning, bedömning efter testflaggan och oberoende mottagarbeslut |
| Rapportparsern antar ett äldre schema | Granska accepterade format, fält och felhantering | Versionerade giltiga, äldre och felaktiga fixturer |
| Kritisk applikation har ingen känd ägare | Etablera företagstjänsten och stödda identiteter | Namngiven ägare och verifierat prov på mottagna meddelanden |
| DNS redigeraren kontrolleras av ett utkontrakterat team | Kom överens om godkännande och återställningsansvar | Exakt ändringsförhandsgranskning, godkännande och återställningsmaterial |
Följande syntetiska fixturer anger förväntade resultat för en kontrollerad utvärderare som implementerar RFC 9989 . De är testingångar, inte produktionspostmallar eller redan utförda tester. Anta att en giltig tillämplig policy har upptäckts och att testmeddelandet misslyckas med DMARC .
| Fixtur | Input | Förväntad observation på policynivå |
|---|---|---|
| Testar flaggan | p=reject; t=y | Valideringsrester misslyckas; bedömning efter t=y är karantän, snarare än det deklarerade avslaget |
| Flagga vid ingen | p=none; t=y | Flaggan lämnar ingen bedömning och rapportgenereringsbeteende oförändrat |
| Ett obefintligt barn | En rådande policy för organisationsdomän har p=none; sp=quarantine; np=reject, med standard t=n; barnet är etablerat som icke-existerande och har ingen direkt policy | Den tillämpliga underordnade bedömningen avvisas, snarare än värdet för befintligt barn sp |
Fånga utvärderarversionen, input, observerad validering, vald bedömning och eventuell slutlig hantering separat. En kontrollerad fixtur fastställer det testade beteendet; det bevisar inte att alla internetmottagare implementerar samma regler. En karantänobservation på policynivå är inte ett universellt löfte om placering av skräppostmapp.
Granska policyns lämplighet också. RFC 9989 avsnitt 7.4 avråder från avslag för allmänna e-postdomäner eftersom legitima indirekta rutter, inklusive e-postlistor, kan gå sönder. En beredskapsöversyn bör identifiera dessa rutter och bedöma tillämpliga interoperabilitetsriktlinjer innan man föreslår en starkare policy.
Håll konfigurationsändringar åtskilda från mjukvaru- eller processändringar. Vissa resultat behöver ingen omedelbar DNS redigering. Andra kräver en leverantörsuppdatering, en parserfix eller ett kontrollerat implementeringstest.
Kontrollera interoperabilitet och gränserna för ett beredskapsanspråk
Ett beredskapsanspråk bör ange dess omfattning. Täcker det domänportföljen, policyutvärderaren, rapportbehandlaren eller bara ett rekord kontrollera? Det är olika bedömningar.
Använd registret för att spåra implementeringsversioner och olösta skillnader. Välj tillämpliga fall från befintliga och obefintliga underdomäner, justeringslägen, indirekt mail och DNS fel.
Behandla mottagarens diskretion som en del av driftmodellen. Publicering av en specifikation får inte alla mottagare att bete sig identiskt. En publicerad avvisningspreferens är inte heller ett bevis på att varje mottagare avvisade varje misslyckat meddelande.
Upprätthåll oberoende kontroller för intrång i konton, vilseledande visningsnamn, lookalike-domäner och känsliga företagsgodkännanden. DMARC beredskap gör inte domänautentisering till en bedömning av säkerheten för ett meddelandes innehåll.
Gör och verifiera de nödvändiga ändringarna
Innan en produktionsändring bevaras det tidigare tillståndet, identifiera påverkade flöden, erhålla lämpligt godkännande och definiera återvinningsvillkor. Verifiera sedan både den publicerade konfigurationen och representativa meddelanden genom hela sändningsvägen.
Om ett resultat inte stämmer överens med det förväntade beteendet, pausa expansionen till andra domäner och åtgärda eller uttryckligen acceptera kompatibilitetsresultatet.
För de underliggande identiteterna, använd guide för inriktningsdiagnos. För en första konfiguration, följ arbetsflödet för skapande och verifiering av DMARC. För rapporteringslagret, använd genomgången av sammanlagd rapport.
Den praktiska takeawayen
Stäng bedömningen när varje tillämpligt fynd har en ägare, ett underbyggt beslut och reproducerbara bevis. Håll olösta implementeringsskillnader synliga, verifiera viktiga meddelanden och rapportbearbetning och behåll de godkända återställningsvillkoren. En beredskapsetikett ska peka på den posten, inte ersätta den.