Et grønt ternresultat og en mislykket meddelelse kan begge være nøjagtige. Checkeren kan have inspiceret en aktuel DNS politik for ét navn, mens modtageren har evalueret et andet Fra-domæne, brugt et tidligere cachelagret svar eller modtaget en besked uden den tilsigtede tilpassede signatur.
Begynd med at gøre de to observationer sammenlignelige. Bevar de originale resultater, før du ændrer konfigurationen. Spørg derefter præcis, hvad hvert system undersøgte og hvornår.
Skriv ned, hvad brikken rent faktisk har tjekket
Registrer det indtastede domæne, det nøjagtige forespørgselsnavn, forespørgselstype, tidsstempel, resolver og returnerede postsæt. Gem den viste forklaring samt resultatfarven. Bestem, om værktøjet kun undersøgte DNS eller faktisk evaluerede en leveret meddelelse.
For en politik offentliggjort på _dmarc.example.com etablerer et positivt opslag en observeret politik ved det navn. Det fastslår ikke SPF eller DKIM identiteter på en applikations besked. Det beviser heller ikke, at værktøjet fulgte de samme opdagelsesregler som modtageren.
Hold specifikationsantagelserne synlige. Strøm RFC 9989 §4.10 bruger DNS -trævandringsregler til opdagelse og organisatoriske domæner. En ældre implementering kan bruge forskellige antagelser, især for afslappet justering. Beskriv ikke en uenighed som en DNS fejl, før sammenligningen understøtter denne konklusion.
Start modtagerundersøgelsen fra beskeden
For et leveret eksempel skal du beholde den oprindelige modtagne besked og identificere det betroede modtagesystem Authentication-Results. Registrer den synlige Fra-domæne, evaluerede SPF identitet, hver DKIM d og s værdi, godkendelsesresultater, justering og gældende politik.
Under RFC 8601 §7.1, behandle en upålidelig godkendelsespåstand som beskedindhold, ikke en erstatning for det modtagende systems arbejde. Et udbydernavn i en overskrift fastslår heller ikke, at din organisation har godkendt kontoen ved hjælp af den.
For en afvisning er der muligvis ingen leveret besked at inspicere. Behold den fulde returnerede SMTP tekst, besked eller transaktionsreference, afsenderkonto, modtagerdomæne og tidsstempel. Kombiner dem med afsendersystemets hændelsesregistrering og tilgængelige originale indsendte besked.
Saml en DNS sammenligning med kontekst
En undersøgelsespakke skal indeholde:
- Observation: Komplet autoritativt svar for det nøjagtige ejernavn; Hvorfor beholde det: Viser serveringszonens data på indsamlingstidspunktet
- Observation: Relevant rekursivt svar, herunder status og TTL; Hvorfor beholde det: Viser en resolvervisning og mulig cachetilstand
- Observation: Enhver alias eller delegationssti; Hvorfor beholde det: Forklarer hvilken myndighed og hvilke navne der var involveret
- Observation: Fuld TXT post grænser; Hvorfor beholde den: Adskiller én multi-streng-record fra flere politikkandidater
- Observation: UTC-indsamlingstid og seneste ændringshistorik; Hvorfor beholde det: Relaterer aktuelle data til meddelelsens evalueringstid
Undgå kun at beholde +kort output, når svarkoder, myndighedsoplysninger eller fravær har betydning. Bruge guiden til manglende registrering at spore navn og autoritet.
Et aktuelt autoritativt svar er værdifuldt bevis, men det kan ikke rekonstruere en fjernmodtagers historiske cache. Angiv dette hul i stedet for at erklære, at modtageren skal have brugt dagens svar.
Arbejd igennem en syntetisk mismatch
Denne fiktive sag viser, hvorfor matchning af omfang er vigtig:
- Punkt: Checker kl. 14:10 UTC; Fanget observation: En gyldig politik for example.com
- Punkt: Mislykket besked kl. 14:04 UTC; Fanget observation: Fra er alerts@notices.example.com
- Emne: Afsender signatur; Fanget observation: d=mailer.example.net verificerer
- Punkt: Kildepolitikbevis; Fanget observation: Applikationen bruger et udbyderkontrolleret konvolutdomæne
- Punkt: Underdomænekonfiguration; Fanget observation: Der findes en eksplicit politik for notices.example.com
Roddomænekontrollen har ikke etableret politikken eller justeringen for den meddelelse. Den beståede udbydersignatur er heller ikke relateret til From-domænet i dette eksempel. Undersøg underdomænepolitikken og applikationens understøttede tilpassede konfiguration.
En anden sag kan afsløre, at de korrekte identiteter blev justeret, men det påkrævede politikopslag fik timeout; RFC 9989 §5.3.6 klassificerer ikke den ufuldstændige kontrol som bestået eller ikke. Den samme ternfarve ville så føre til en anden reparation.
Hold DNS svarkategorier adskilte
Et vellykket svar, der indeholder relevante data, adskiller sig fra NXDOMAIN , et komplet svar uden data, SERVFAIL , AFVISET og en timeout. Disse observationer betyder ikke alle "nej DMARC rekord”. RFC 1035 §4.1.1 definerer DNS svarkoder; RFC 2308 §2.1 og RFC 2308 §2.2 skelne mellem NXDOMAIN og NODATA .
Tjek det forespurgte navn, før du fortolker fravær. NXDOMAIN for _dmarc.example.com , uden en alias-komplikation, beskriver det forespurgte ejernavn; det fastslår ikke i sig selv, at example.com ikke eksisterer.
Under RFC 2308 §5, negativ caching kan bevare et tidligere fravær efter en rekord er tilføjet. Positiv caching kan bevare en tidligere værdi efter en redigering. Bevar svarkontekst og indsamlingstid, så forklaringen kan vurderes.
Vælg reparationen fra de matchede beviser
Hvis værktøjet og modtageren undersøgte forskellige navne, skal du rette undersøgelsesomfanget. Hvis meddelelsen mangler en tilpasset sti, skal du rette den understøttede afsendelseskonfiguration. Hvis svarene er forskellige blandt autoritative servere, skal du undersøge zonekonsistensen. Hvis rekursiv løsning mislykkes, skal du inspicere resolveren, delegeringen, valideringen og transportstien.
En politikredigering er ikke den automatiske reparation for hver uoverensstemmelse. Skift den mindste relevante konfiguration og behold årsagen. Bruge justeringsguiden når rå godkendelse passerer for et domæne, der ikke justeres.
Gentag en kontrolleret test og afslut sammenligningen
Efter reparationen skal du fange nye DNS observationer og en repræsentativ besked via den samme applikationskonto og rute. Sammenlign det nye resultat med den tidligere pakke og forklar de ændrede beviser.
Et vellykket genforsøg viser dette forsøg. Fortsæt de definerede tjek på serviceniveau, når hændelsen involverede flere ruter eller modtagere.
Den nyttige konklusion er en afstemt redegørelse for uenigheden: hvad der blev kontrolleret, hvad modtageren vurderede, hvilken forskel betød, og hvilken reparation ændrede resultatet.
Gør den næste beslutning eksplicit
For 14:10-kontrollen og 14:04-meddelelsesopstillingen skal du først justere det forespurgte forfatterdomæne og rekonstruere meddelelsens identiteter; tilskriv ikke de seks minutters forskel til caching uden beviser. Nødvendige DNS fejl og manglende justering er forskellige resultater. Kvalificerende uaktuelle svar kan strække sig ud over TTL-udløb under RFC 8767 §4. De illustrerede observationer er fiktive, ikke indfangede logfiler.