A DMARC resultatet er en diagnosekategori, ikke en instruktion om at ændre den offentliggjorte politik. svigte, ingen, temperror og permerror pege på forskellige undersøgelser. At behandle dem som udskiftelige kan efterlade den virkelige fejl uløst og svække beskyttelsen unødigt.
Start med det modtagende systems pålidelige beviser. An Authentication-Results header registrerer et systems påstand; dens tilstedeværelse alene beviser ikke, at påstanden er pålidelig. Identificer, hvilken modtagende tjeneste, der genererede den, og hvilke overskrifter, den tjeneste har tillid til. Denne grænse er forklaret i RFC 8601 §1.2 og RFC 8601 §7.1.
Læs metode og resultat sammen
I en overskrift, der indeholder spf=pass; dkim=pass; dmarc=fail, tilhører de tre resultatord forskellige metoder. De SPF og DKIM pass kan godkende domæner, der ikke stemmer overens med det synlige Fra-domæne. Omvendt kan en DMARC -pas eksistere side om side med en fejl i en underliggende metode, hvis en anden passerende sti justeres.
Brug følgende diagnostiske kort. Resultatbetydningerne kommer fra RFC 9989 , afsnit 9.2; de næste handlinger er operationelle anbefalinger.
- Resultat:
dmarc=none; Fortolkning: Der blev ikke fundet nogen gældende politik for forfatterdomænet; Første nyttige handling: Rekonstruer politikopdagelse for det faktiske From-domæne - Resultat:
dmarc=pass; Fortolkning: Der findes en gældende politik, og en bestået autentificeret identitet stemmer overens; Første nyttige handling: Identificer den vellykkede vej og undersøg ethvert separat leveringsproblem - Resultat:
dmarc=fail; Fortolkning: Der eksisterer en gældende politik, men der blev ikke etableret nogen passerende identitet; Første nyttige handling: Sammenlign SPF og alle relevante DKIM resultater med From - Resultat:
dmarc=temperror; Fortolkning: Evalueringen stødte på en tilsyneladende forbigående fejl; Første nyttige handling: Fang DNS eller servicefejlen og sammenlign et senere kontrolleret forsøg - Resultat:
dmarc=permerror; Fortolkning: Evalueringen stødte på en fejl, som usandsynligt ville løse sig blot ved at prøve igen; Første nyttige handling: Undersøg de nøjagtige politikdata og modtagerdiagnostik for et vedvarende konfigurationsproblem
Udled ikke årsagen fra resultatordet alene. En midlertidig DNS fejl og en forkert udformet politik kan begge forhindre en normal konklusion, men de kræver forskellige ejere og forskelligt korrigerende arbejde. Bevar enhver diagnostisk kommentar i stedet for at reducere beviserne til en dashboardfarve.
Adskil dmarc=none fra p=none
dmarc=none er et rapporteret evalueringsresultat. p=none er en værdi i en offentliggjort politik. En gyldig overvågningspolitik kan stadig producere enten dmarc=pass eller dmarc=fail på individuelle beskeder.
Overvej to syntetiske sager. I den første, example.com udgiver en gyldig overvågningspost, og en meddelelse har en tilpasset beståelse DKIM signatur. Den forventede DMARC evaluering er bestået, selvom politikken ikke siger noget. I den anden kan der ikke findes nogen gældende politik for meddelelsens forfatterdomæne. Modtageren kan indberette dmarc=none; der er ikke noget overvågningspolitisk løfte at udlede af det ord.
Hvis en kollega siger " DMARC er indstillet til ingen", så spørg, om de mener DNS politikken, beskedresultatet eller den endelige disposition. Optag alle tre separat. Den korte afklaring forhindrer ofte en DNS ændring rettet mod det forkerte problem.
Undersøg fejl gennem identiteterne
Få den oprindelige modtagne besked. Registrer det synlige From-domæne, SPF identiteten og -resultatet og d= domæne og resultat for hver relevant DKIM signatur. Anvend det konfigurerede justering måde at videregive identiteter. EN vælger er en nøglelocator, ikke det domæne, der bruges til DKIM justering.
Hvis SPF passerer til et leverandørdomæne, og DKIM passerer til et andet leverandørdomæne, må ingen af dem passe med dit Fra-domæne. Redigering af roden SPF rekord er ikke automatisk rettelsen. Angiv, hvilken identitet tjenesten faktisk evaluerer, og hvilke kundedomænegodkendelsesmuligheder den understøtter. De guide til justeringsfejl gennemgår den sammenligning.
Undersøg fejl uden at gætte
For temperror, optag beskedtiden, modtageren, det forespurgte navn, fejlen og resolverkonteksten, hvis tilgængelig. Sammenlign autoritative DNS og rekursive resultater. Et senere vellykket opslag understøtter en forbigående forklaring, men beviser ikke, hvad modtageren så tidligere. Spørg den modtagende operatør om logfiler, når denne skelnen er vigtig.
For permerror, hente den komplette relevante TXT post sæt. Tjek udgivelsens navn, versionsplacering, dublerede politikregistreringer og forkerte værdier. Lov ikke, at hver misdannede plade producerer den samme etiket: nuværende DMARC in RFC 9989 §4.10 og RFC 9989 §4.10.1 definerer specifik gendannelse og standardadfærd for nogle syntaks- og politikværdiproblemer, og implementeringer kan variere. Match diagnosticeringen med den gældende regel, før du ændrer den.
Opbevar en før-og-efter prøve. Hvis det nye forsøg lykkes, skal du holde den nøjagtige reparation og det vellykkede resultat sammen. Undgå at lukke en hændelse, blot fordi en offentlig checker nu giver et grønt resultat.
Hold evaluering adskilt fra levering
Under RFC 9989 §5.4, kan en modtager levere en DMARC-fejlmeddelelse i henhold til dens lokale håndteringsregler, og den kan blokere en forbigående meddelelse af spam, malware eller andre årsager. Indsaml SMTP svaret eller leveringsdispositionen separat fra godkendelsesresultatet.
Din sidste hændelsesnotat skal sige, hvad der blev evalueret, af hvilken betroet modtager, hvornår, hvorfor resultatet opstod, og hvad der ændrede sig. En præcis konklusion såsom "faktureringstjenesten producerer nu en tilpasset DKIM passage gennem sin produktionsrute" er mere nyttig end " DMARC fast". For manglende forsikringssager, fortsæt med Ingen DMARC -post fundet.
Gør den næste beslutning eksplicit
Optag i overvågningspolitikken p=none, dmarc=pass og faktisk disposition som tre separate felter. Hvis der eksisterer en gyldig politik, men begge identiteter for videregivelsesmekanismer ikke er tilpasset, mislykkes den gennemførte evaluering. Hvis påkrævede DNS forespørgsler ikke fuldføres, RFC 9989 §5.3.6 forhindrer en normal bestået/ikke-bestået konklusion. Disse er analytiske klassifikationer, ikke modtagerlogfiler.