En plausibel DMARC streng kan mislykkes fordi den ble publisert med feil navn, delt inn i separate poster eller endret av en redaktør. Den kan også inneholde en ugyldig policyverdi som har en spesifikk reserve i stedet for den generiske feilen en operatør forventer.
Gjennomgå den nøyaktige returnerte verdien i trinn. Bevar DNS representasjonen og registrer grensene først, inspiser deretter identifikasjon, grammatikk og policy-semantikk. Denne tilnærmingen gjør at rettelsen kan gjennomgås og unngår unødvendige policyendringer.
Bekreft eieren og registrer grensene
Spør etter det aktuelle _dmarc navnet for det faktiske From-domenet. Lagre hele TXT post sett, autoritet, tid og TTL. En verdi ved domeneroten tilfredsstiller ikke det forventede publiseringsnavnet.
En TXT ressurspost kan inneholde flere tegnstrenger. DMARC kobler sammen strenger innenfor den posten i rekkefølge før den analyseres under RFC 9989 §4.5. Den slår ikke sammen separate ressursposter i én policy.
For eksempel er dette en syntetisk sonestil-post:
_dmarc.example.com. 300 IN TXT "v=DMARC1; " "p=none"Sitatene avgrenser sonefilrepresentasjonen. Inspiser hva DNS leverandøren faktisk lagrer og returnerer før du bestemmer deg for at sitater er bokstavelig postinnhold.
Identifiser versjonen først
Under RFC 9989 §4.7 og de arvede RFC 6376 §3.2 syntaks, bruk de registrerte tagnavnene med små bokstaver og nøyaktig versjonsverdi DMARC1 . V-taggen må vises først. En manglende versjon, en annen verdi eller en versjon som vises bare etter en annen kode fører til at posten ignoreres under RFC 9989.
Ikke stol på å endre størrelsen på etikettnavn for å produsere en tilsvarende anerkjent etikett. Verdier har også tag-spesifikke krav; versjonsverdien skiller eksplisitt mellom store og små bokstaver.
Dette er forskjellig fra saksoppførselen til DNS navn. Unngå å utvide en generell DNS-navnregel til teksten i en DMARC -policy.
Inspiser skilletegn og mellomrom nøyaktig
Tag-verdi-par bruker semikolon som skilletegn. Kommaer har en annen rolle i en rapporteringsdestinasjonsliste og kan ikke erstatte hvert semikolon i posten.
Whitespace er ikke universelt forbudt. Den arvede RFC 6376 §3.2 tag-value grammatikk tillater mellomrom rundt tag-syntaks, men det autoriserer ikke mellomrom inne i et token hvis egen verdi grammatikk forbyr dem.
En kopier-og-lim-operasjon kan introdusere typografiske anførselstegn, ikke-standard tegnsetting eller et utilsiktet linjeskift. Sammenlign de nøyaktige lagrede tegnene mot grammatikken i stedet for å reparere verdien ved synet. Behold både det opprinnelige og foreslåtte korrigerte skjemaet.
Bruk inventar som navngir behandlingsstadiet
Følgende syntetiske armaturer illustrerer distinkte problemer og avgjørelser. De er ikke live testresultater eller et løfte om identiske diagnostiske etiketter fra hver implementering.
- Armatur ved ett eiernavn: v=DMARC1; p=none; rua=mailto:reports@example.com; Gjennomgå funn: Eksplisitt ingen policy og rapporteringsforespørsel
- Armatur ved ett eiernavn: p=none; v=DMARC1; Gjennomgangsfunn: Versjonen er ikke først; ignorer denne posten
- Armatur ved ett eiernavn: v=DMARC2; p=none; Gjennomgå funn: Ikke den gjeldende definerte versjonen; ignorer denne posten
- Armatur ved ett eiernavn: v=DMARC1; p=invalid; rua=mailto:reports@example.com; Gjennomgå funn: Bruk den gjeldende betingede tilbakestillingen
- Armatur ved ett eiernavn: v=DMARC1; p=invalid; Gjennomgå funn: Ingen kvalifiserende rua URI for den reserven
- Armatur ved ett eiernavn: v=DMARC1; p=none; p=reject; Gjennomgå funn: Duplikat tagnavn; reparer den ugyldige tag-listen i stedet for å velge én verdi
- Feste med ett eiernavn: To separate poster som hver starter v=DMARC1; Gjennomgå funn: Flere politikkkandidater; inspisere post-sett filtrering og oppdagelse
- Armatur ved ett eiernavn: v=DMARC1; p=none; xnote=example; Gjennomgå funn: Ukjent tag ignoreres under gjeldende regler
En tilpasset ukjent tag skal ikke bli en del av driftspolicykontrakten bare fordi en parser ignorerer den. Bruk dokumenterte felt og hold administrative notater i endringsposten.
Skille dupliserte navn fra flere poster
En duplikat-tag er et gjentatt navn i én tag-liste. Den arvede RFC 6376 §3.2 DKIM tag-verdi-syntaks forbyr dupliserte navn og behandler den listen som ugyldig. Ikke anta at den siste p-verdien overstyrer den første eller kombiner to rua-tagger uten en planlagt korreksjon.
Flere policyoppføringer er et annet lag. Under RFC 9989 §4.10, nåværende DNS -trevandringsbehandling forkaster flere DMARC -policyposter på ett mål. Discovery kan da finne en annen gjeldende policy. En armatur som kun tester fornavnet har ikke etablert det fullstendige mottakerresultatet.
Hold disse funnene atskilt i en feilrapport: nøyaktig antall poster, sammenkoblet enkeltpostverdi, dupliserte navn og påfølgende oppdagelse.
Bruk gjeldende tilbakefallspolitikk uten å overgeneralisere den
Under RFC 9989 §4.10.1, en manglende eller ugyldig p, eller ugyldig sp eller np, forårsaker fortsatt behandling som p=none bare hvis rua inneholder minst én syntaktisk gyldig rapporterings-URI. Ellers gjelder ingen DMARC -behandling for den meldingen under disse reglene.
Denne betingelsen validerer ikke alle vilkårlig brutte tag-lister. En rekord ignorert ved versjonsidentifikasjon blir ikke brukbar bare fordi den inneholder en adresse senere. Bruk reglene på det stadiet de hører hjemme.
Under RFC 9990 §4, en syntaktisk gyldig rapporterings-URI beviser heller ikke ekstern destinasjonsautorisasjon, tilgjengelighet eller faktisk innsamling. Ingen-rapporteringsveiledningen dekker disse separate avhengighetene.
Bekreft den godkjente korrigeringen
Lag en sammenhengende tiltenkt post satt til det eksakte eiernavnet. Se gjennom de definerte tagreglene i RFC 9989 §4.7, registerreferansen i RFC 9989 §9.3 og den fullstendige semantiske endringen. Ikke legg til en annen policypost som overstyring.
Lagre konfigurasjonsforskjellen og den gamle verdien for undersøkelse og gjenoppretting. Sjekk autoritative svar etter endringen, sammenlign relevante rekursive visninger og ta hensyn til bufrede tidligere data. Rekordarbeidsflyten kobler disse sjekkene til representativ posttesting.
Send til slutt en kontrollert melding gjennom selve søknadsruten. En syntaktisk gyldig policy beviser ikke det SPF eller DKIM er på linje med Fra. Hold DNS korreksjonen og avsenderens autentiseringsbevis sammen, med separate funn der det er nødvendig.
Det nyttige resultatet er en nøyaktig forklaring av defekten, dens behandlingsstadium, den korrigerte verdien og det bekreftede postutfallet. Det er mer holdbart enn å erklære hver streng som ser feil ut som en permanent feil.
Hold avgjørelsen og bevisene atskilt
For v=DMARC1; p=invalid med en gyldig rua URI, bruk den oppgitte betingede reserven først etter at posten når det relevante stadiet. Ikke bruk den reparasjonsregelen på en liste over versjoner som er avvist eller duplikatetiketter. Behold policyhensikten og den faktiske meldingstesten som separate godkjenningsbevis. RFC 8767 §4 tillater kvalifiserende foreldede svar etter TTL-utløp; endring av syntaks erstatter ikke hver cache umiddelbart. Ingen parser-, DNS eller e-posttest ble utført.