Ett grönt kontrollresultat och ett misslyckat meddelande kan båda vara korrekta. Checkaren kan ha inspekterat en aktuell DNS policy för ett namn, medan mottagaren utvärderade en annan Från-domän, använt ett tidigare cachat svar eller tagit emot ett meddelande utan den avsedda justerade signaturen.
Börja med att göra de två observationerna jämförbara. Bevara de ursprungliga resultaten innan du ändrar konfigurationen. Fråga sedan exakt vad varje system undersökte och när.
Skriv ner vad kontrollen faktiskt kontrollerade
Registrera den angivna domänen, det exakta frågenamnet, frågetyp, tidsstämpel, resolver och returnerad postuppsättning. Spara den visade förklaringen samt resultatfärgen. Bestäm om verktyget endast undersökte DNS eller faktiskt utvärderade ett tillhandahållet meddelande.
För en policy som publiceras på _dmarc.example.com upprättar en positiv sökning en observerad policy för det namnet. Det fastställer inte SPF eller DKIM identiteter på ett programs meddelande. Det bevisar inte heller att verktyget följde samma upptäcktsregler som mottagaren.
Håll specifikationsantagandena synliga. Nuvarande RFC 9989 §4.10 använder DNS -trädvandringsregler för upptäckts- och organisationsdomäner. En äldre implementering kan använda olika antaganden, särskilt för avslappnad inriktning. Beskriv inte en oenighet som ett DNS fel förrän jämförelsen stöder den slutsatsen.
Starta mottagarens undersökning från meddelandet
För ett levererat exempel, behåll det mottagna originalmeddelandet och identifiera det betrodda mottagande systemet Authentication-Results. Registrera den synliga From-domänen, utvärderad SPF identitet, varje DKIM d och s värde, autentiseringsresultat, anpassning och tillämplig policy.
Under RFC 8601 §7.1, behandla en otillförlitlig autentiseringspåstående som meddelandeinnehåll, inte en ersättning för det mottagande systemets arbete. Ett leverantörsnamn i en rubrik bekräftar inte heller att din organisation har godkänt kontot som använder det.
För ett avslag kanske det inte finns något levererat meddelande att inspektera. Behåll den fullständiga returnerade SMTP texten, meddelandet eller transaktionsreferensen, sändningskontot, mottagardomänen och tidsstämpeln. Kombinera dessa med det sändande systemets händelsepost och tillgängligt originalmeddelande.
Samla en DNS jämförelse med sammanhang
Ett utredningspaket bör innehålla:
- Observation: Fullständigt auktoritativt svar för det exakta ägarens namn; Varför behålla det: Visar serveringszonens data vid insamlingstidpunkten
- Observation: Relevant rekursivt svar, inklusive status och TTL; Varför behålla det: Visar en resolvervy och eventuellt cachelagrat tillstånd
- Observation: Alla alias eller delegeringsvägar; Varför behålla den: Förklarar vilken myndighet och vilka namn som var inblandade
- Observation: Full TXT post gränser; Varför behålla den: Skiljer en flersträngspost från flera policykandidater
- Observation: UTC-insamlingstid och senaste ändringshistorik; Varför behålla det: Relaterar aktuell data till meddelandets utvärderingstid
Undvik att spara endast +kort utdata när svarskoder, myndighetsinformation eller frånvaro har betydelse. Använda guiden för saknade rekord att spåra namn och auktoritet.
Ett aktuellt auktoritativt svar är värdefullt bevis, men det kan inte rekonstruera en fjärrmottagares historiska cache. Ange det gapet istället för att förklara att mottagaren måste ha använt dagens svar.
Arbeta igenom en syntetisk missmatchning
Detta fiktiva fall visar varför matchning av omfattning är viktig:
- Objekt: Checker kl. 14:10 UTC; Fångad observation: En giltig policy för example.com
- Objekt: Misslyckat meddelande kl. 14:04 UTC; Fångad observation: Från är alerts@notices.example.com
- Objekt: Avsändarens signatur; Fångad observation: d=mailer.example.net verifierar
- Objekt: Källpolicybevis; Fångad observation: Applikationen använder en leverantörskontrollerad kuvertdomän
- Objekt: Underdomänkonfiguration; Fångad observation: Det finns en explicit policy för notices.example.com
Rotdomänkontrollen har inte upprättat policyn eller justeringen för det meddelandet. Den passerande leverantörens signatur är inte heller relaterad till From-domänen i det här exemplet. Undersök underdomänpolicyn och programmets anpassade konfiguration som stöds.
Ett annat fall kan avslöja att de korrekta identiteterna överensstämde men den nödvändiga policysökningen tog timeout; RFC 9989 §5.3.6 klassificerar inte den ofullständiga kontrollen som godkänd eller underkänd. Samma rutfärg skulle då leda till en annan reparation.
Håll DNS svarskategorier åtskilda
Ett lyckat svar som innehåller relevanta data skiljer sig från NXDOMAIN , ett komplett svar utan data, SERVFAIL , REFUSED och en timeout. Dessa observationer betyder inte alla "nej DMARC -post”. RFC 1035 §4.1.1 definierar DNS svarskoder; RFC 2308 §2.1 och RFC 2308 §2.2 särskilj NXDOMAIN och NODATA .
Kontrollera det efterfrågade namnet innan du tolkar frånvaro. NXDOMAIN för _dmarc.example.com , utan en aliaskomplikation, beskriver det efterfrågade ägarnamnet; det bekräftar inte i sig att example.com inte existerar.
Under RFC 2308 §5, negativ cachelagring kan bevara en tidigare frånvaro efter ett rekord läggs till. Positiv cachning kan bevara ett tidigare värde efter en redigering. Behåll svarskontext och insamlingstid så att förklaringen kan bedömas.
Välj reparationen från de matchade bevisen
Om verktyget och mottagaren undersökte olika namn, korrigera undersökningens omfattning. Om meddelandet saknar en justerad sökväg, korrigera den sändningskonfiguration som stöds. Om svaren skiljer sig åt mellan auktoritativa servrar, undersök zonens konsistens. Om rekursiv upplösning misslyckas, inspektera resolver, delegering, validering och transportväg.
En policyredigering är inte den automatiska reparationen för varje avvikelse. Ändra den minsta relevanta konfigurationen och behåll orsaken. Använda inriktningsguiden när rå autentisering passerar för en domän som inte justeras.
Upprepa ett kontrollerat test och avsluta jämförelsen
Efter reparationen, fånga nya DNS observationer och ett representativt meddelande via samma programkonto och rutt. Jämför det nya resultatet med det tidigare paketet och förklara de ändrade bevisen.
Ett lyckat nytt försök visar det försöket. Fortsätt de definierade servicenivåkontrollerna när incidenten involverade flera rutter eller mottagare.
Den användbara slutsatsen är en matchad redogörelse för oenigheten: vad som kontrollerades, vad mottagaren utvärderade, vilken skillnad som spelade roll och vilken reparation ändrade resultatet.
Gör nästa beslut tydligt
För 14:10-kontrollen och 14:04-meddelandefixturen, anpassa först den efterfrågade Author Domain och rekonstruera meddelandets identiteter; Tillskriv inte sexminutersskillnaden till cachning utan bevis. Nödvändiga DNS fel och bristande anpassning är olika upptäckter. Kvalificerande inaktuella svar kan sträcka sig längre än att TTL löper ut under RFC 8767 §4. De illustrerade observationerna är fiktiva, inte fångade loggar.