DMARCbis endrer hvordan deler av DMARC er spesifisert og implementert. Den ber deg ikke om å gi nytt navn til posten din til DMARC2. Kjernespesifikasjonen, RFC 9989, ble publisert i mai 2026, mens RFC 9990 og RFC 9991 dekke samlet og feilrapportering separat.
Den praktiske oppgaven er å finne ut hvilke endringer som påvirker ditt domene, dine sendetjenester og programvaren som behandler autentiseringsdataene dine. Det starter med å forstå gjeldende spesifikasjoner, og deretter sammenligne dem med konfigurasjonen og prosessene som allerede er i bruk. Resultatet bør være et oversiktlig beredskapsregister med bevis, eiere og vedtak for hvert funn.
Tilordne de tre spesifikasjonene til systemene dine
Bruk de gjeldende dokumentene for sine respektive jobber:
| Dokument | Hva du skal vurdere |
|---|---|
| RFC 9989 | Kjerne DMARC -evaluering, policy-oppdagelse, justering og registrere semantikk |
| RFC 9990 | Samlet rapporteringsformat, generering og behandling |
| RFC 9991 | Feilrapportering og håndteringshensyn |
Start med den eksisterende posten og konfigurasjonshistorikken. Ikke slett en driftsoppføring bare fordi en eldre guide siterer RFC 7489. Identifiser instruksjonene som ble endret og programvaren som implementerer dem.
De viktigste gjennomgangsområdene inkluderer følgende:
- Domeneoppdagelse: RFC 9989 avsnitt 4.10 definerer DNS -trevandring. Gjennomgå systemer som antar en eldre oppdagelsesmodell med offentlig suffiksliste.
- Retningslinjer: Sjekk gjeldende IANA register. De
pct,rfogritaggene er historiske. Vurdert,npogpsdetter deres faktiske omfang i stedet for å legge dem til som en oppgraderingssjekkliste. - Testing: Etablere hvordan den relevante evaluatoren implementerer binæren
tsignal. En erklært testtilstand og en mottakers endelige disposisjon er forskjellige observasjoner. - Rapportering: Bekreft at samlere og analysere håndterer rapportformatene og feltene du forventer å motta, uten å miste relevante eldre observasjoner.
Versjonsmarkøren gjenstår v=DMARC1. Ikke erstatt DMARC2 eller mekanisk erstatte en gammel prosentandel med et testflagg.
Oversett de endrede kodene til tester
De t flagget er som standard n, ber om anvendelse av den erklærte vurderingen på DMARC feil. Innstilling t=y signaliserer at eieren tester i stedet for å be om at den deklarerte vurderingen brukes direkte. RFC 9989 avsnitt 4.7 definerer en reduksjon på ett nivå for mislykkede meldinger: avvisning blir karantene, og karantene blir ingen. Implementeringer kan også ha relevant spesialhåndtering.
Flagget endrer ikke et mislykket autentiseringsresultat til et bestått, endrer rapportgenerering eller påvirker en ingen-policy. Det er binært, ikke en forespørsel om å prøve en vilkårlig prosentandel av posten. Etabler implementeringsstøtte før du stoler på den for ekte trafikk, og hold mottakerlokalfiltrering atskilt fra testresultatet på policynivå.
To andre tagger påvirker omfanget av vurderingen:
- np: Spesifiserer vurderingen for ikke-eksisterende underdomener av gjeldende organisasjonsdomene. Hvis fraværende, er den aktuelle reserven sp når tilstede, ellers s. En savnet MX post alene etablerer ikke ikke-eksistens.
- psd: Markerer domenegrenseinformasjon brukt under oppdagelse. Standard u overlater grensebestemmelse til oppdagelsesreglene; y identifiserer et offentlig suffiks, mens n identifiserer en ikke-offentlig suffiks organisasjonsgrense for seg selv og dets underdomener. Ikke angi noen eksplisitte grenseverdier uten å fastslå at den beskriver domenet riktig.
En vanlig organisasjon bør ikke merke sitt domene som et offentlig suffiks bare for å kreve beredskap. Gjennomgå faktiske oppdagelsesforutsetninger og delegerte navnerom. De retningslinjer for underdomene dekker det snevrere arvespørsmålet.
Identifiser posten som må fortsette å fungere
Et domene kan representere mye mer enn ansattes e-post. Det kan vises på fakturaer, påloggingslenker, kundevarsler og meldinger sendt av eksterne byråer. En standardoppdatering er en mulighet til å sjekke disse avhengighetene før en forhastet konfigurasjonsendring forstyrrer dem.
Be om tre leveranser: en oversikt over tjenestene som bruker identiteten din, en forklaring på de spesifikke endringene som påvirker deg, og en testplan for kritiske meldinger. Svaret bør skille en publisert spesifikasjon fra en funksjon som allerede er distribuert av en bestemt mottaker eller programvaretjeneste.
Tildel eierskap samt budsjett. En endring i rapportbehandling trenger noen som er ansvarlig for rapporteringsrørledningen. En avsender som ikke kan autentisere riktig, trenger bedriftseieren involvert. Å kalle begge elementene for en DNS oppgradering skjuler arbeidet.
Bygg et beredskapsregister
Følgende er et illustrativt planregister, ikke en vurdering av et reelt domene:
| Finne | Arbeid påkrevd | Bevis på fullføring |
|---|---|---|
| Utrullingsinstruksjoner forutsetter prosentvis prøvetaking | Test det binære flagget ved å bruke de kontrollerte armaturene nedenfor | Registrert erklært vurdering, vurdering etter testflagget og uavhengig mottakerbeslutning |
| Rapportparser antar ett eldre skjema | Gjennomgå aksepterte formater, felt og feilhåndtering | Versjonert gyldige, eldre og misformede armaturer |
| Kritisk applikasjon har ingen kjent eier | Etabler bedriftstjenesten og støttede identiteter | Navngitt eier og verifisert eksempel på mottatt melding |
| DNS editor styres av et utkontraktert team | Enig godkjennings- og gjenopprettingsansvar | Eksakt endringsmateriale, forhåndsvisning, godkjenning og restaurering |
Følgende syntetiske inventar spesifiserer forventede resultater for en kontrollert evaluator som implementerer RFC 9989 . De er testinndata, ikke produksjonspostmaler eller tester som allerede er utført. Anta at en gyldig gjeldende policy blir oppdaget og testmeldingen mislykkes DMARC .
| Armatur | Inndata | Forventet observasjon på policynivå |
|---|---|---|
| Tester flagg | p=reject; t=y | Valideringsrester mislykkes; vurdering etter t=y er karantene, i stedet for det erklærte avslaget |
| Flagg på ingen | p=none; t=y | Flagget forlater ingen vurdering og rapportgenereringsatferd uendret |
| Ikke-eksisterende barn | En rådende organisasjonsdomenepolicy har p=none; sp=quarantine; np=reject, med standard t=n; barnet er etablert som ikke-eksisterende og har ingen direkte policy | Den gjeldende barnevurderingen avvises, i stedet for den eksisterende barnets sp-verdien |
Fang evaluatorversjon, input, observert validering, valgt vurdering og eventuell endelig håndtering separat. En kontrollert armatur fastslår atferden som testes; det beviser ikke at alle Internett-mottakere implementerer de samme reglene. En karanteneobservasjon på policynivå er ikke et universelt løfte om plassering av søppelpostmapper.
Vurder også policyens egnethet. RFC 9989 avsnitt 7.4 fraråder avvisning for generelle e-postdomener fordi legitime indirekte ruter, inkludert e-postlister, kan gå i stykker. En beredskapsgjennomgang bør identifisere disse rutene og vurdere gjeldende interoperabilitetsveiledning før det foreslås sterkere politikk.
Hold konfigurasjonsendringer atskilt fra programvare- eller prosessendringer. Noen funn trenger ingen umiddelbar DNS redigering. Andre krever en leverandøroppdatering, en parserfiks eller en kontrollert implementeringstest.
Sjekk interoperabilitet og grensene for et beredskapskrav
Et krav om beredskap bør angi omfanget. Dekker det domeneporteføljen, policy-evaluatoren, rapportbehandleren eller bare en rekord sjekke? Dette er ulike vurderinger.
Bruk registeret til å spore implementeringsversjoner og uløste forskjeller. Velg aktuelle saker fra eksisterende og ikke-eksisterende underdomener, justeringsmoduser, indirekte post og DNS feil.
Behandle mottakerens skjønn som en del av driftsmodellen. Publisering av en spesifikasjon får ikke alle mottakere til å oppføre seg identisk. En publisert avvisningspreferanse er heller ikke bevis på at hver mottaker avviste hver feilmelding.
Oppretthold uavhengige kontroller for kompromitterte kontoer, villedende visningsnavn, lookalike-domener og sensitive bedriftsgodkjenninger. DMARC beredskap gjør ikke domeneautentisering til en dom om sikkerheten til en meldings innhold.
Gjør og bekreft de nødvendige endringene
Før en produksjonsendring, bevar den forrige tilstanden, identifiser berørte strømmer, innhent passende godkjenning og definer utvinningsbetingelser. Bekreft deretter både den publiserte konfigurasjonen og representative meldinger gjennom hele senderruten.
Hvis et resultat ikke stemmer overens med den forventede oppførselen, stans utvidelsen til andre domener og løs eller aksepter kompatibilitetsfunnet eksplisitt.
For de underliggende identitetene, bruk alignment diagnose guide. For en innledende konfigurasjon, følg arbeidsflyten for opprettelse og verifisering DMARC. For rapporteringslaget, bruk gjennomgangen for samlet rapport.
Den praktiske takeawayen
Avslutt vurderingen når hvert gjeldende funn har en eier, en støttet avgjørelse og reproduserbare bevis. Hold uløste implementeringsforskjeller synlige, verifiser kritiske meldinger og rapportbehandling, og behold de godkjente gjenopprettingsbetingelsene. En beredskapsetikett skal peke på den posten, ikke erstatte den.