Den snabbaste användbara DMARC Bevisbegäran frågar efter ett representativt meddelande, rutten som producerade det och det mottagande systemets resultat. En skärmdump som säger "SPF godkänd" eller "domän verifierad" utelämnar vanligtvis de identiteter som behövs för att förklara felet.
Begär den minsta bevisuppsättningen som kan särskilja ett autentiseringsproblem, en inriktning problem, ett DNS problem och ett leveransproblem. Utöka begäran endast när en specifik osäkerhet kvarstår. Detta minskar onödig exponering av kundinnehåll och ger avsändaren en uppgift de faktiskt kan utföra.
Be om en säker reproduktion först
Låt applikationsägaren där det är praktiskt möjligt skicka ett icke-känsligt testmeddelande genom det berörda produktionsarbetsflödet till en auktoriserad testmottagare. Arbetsflödet är viktigt: en testknapp i leverantörskonsolen kan använda en annan avsändare eller rutt från fakturor, lösenordsåterställningar eller schemalagda aviseringar.
Registrera applikationen, kundkontot eller hyresgästreferensen som används internt, utlösande åtgärd, UTC-sändningstid, avsett mottagarsystem och om vidarebefordran eller en gateway är inblandad. En meddelandeidentifierare kan hjälpa till att korrelera loggar, men dela den endast via den överenskomna supportkanalen. Begär inte lösenord, privata signeringsnycklar, API-uppgifter eller icke-relaterade postlådeexporter.
Håll den första begäran fokuserad på det tekniska problemet. Om felet involverar en verklig kunds meddelande, använd godkänd hantering och åtkomstkontroll innan du delar dess innehåll med en annan part.
Bevara bevisen som särskiljer identiteterna
Be om det ursprungliga meddelandet som mottagits på den berörda destinationen, eller en diagnostisk export på mottagarsidan som behåller de relevanta rubrikerna. De användbara fälten inkluderar den synliga Från-domänen, kuvertidentitet där tillgängligt, relevant DKIM signaturer och det mottagande systemets Authentication-Results.
Den mottagande operatören måste identifiera vilket resultat som är pålitligt. Enbart rubriktext kan förfalskas eller bäras från en opålitlig källa; RFC 8601 §1.2 och RFC 8601 §7.1 förklara kravet på förtroendegräns. Om flera fält Authentication-Results finns, anta inte att det översta passet är automatiskt auktoritativt.
För initial triage kan en administratör extrahera relevanta identitets- och resultatfält samtidigt som originalet behålls på ett säkert sätt. Det skiljer sig från att kryptografiskt omverifiera DKIM . Redigering av signerade rubriker eller brödtexten kan ogiltigförklara en signatur, så en redigerad kopia kan inte nödvändigtvis återge den ursprungliga valideringen. Om oberoende återverifiering är nödvändig, ordna kontrollerad åtkomst till ett omodifierat prov eller generera ett säkert nytt test. Den signaturkänsliga hanteringen följer RFC 6376 §3.4 och RFC 6376 §3.7.
En minimal begäran du kan anpassa
Använd följande som en operativ mall, inte som en begäran om att avslöja autentiseringsuppgifter:
"Skicka ett icke-känsligt test genom det berörda arbetsflödet och ange:
- Applikationen och det exakta arbetsflödet, sändningstiden i UTC och om rutten inkluderar vidarebefordran eller en gateway.
- Det ursprungliga mottagna meddelandet via vår godkända supportkanal, eller mottagaradministratörens extraherade från domän, SPF-utvärderade identitet och resultat, varje relevant DKIM
d=ochs=värde och resultat och betrodda DMARC resultat. - Det exakta avslagssvaret om leveransen misslyckades, inklusive vilket system som returnerade det. Om det inte finns något mottagarmeddelande, ange spårningsinformation på avsändaren istället.
- Autentiseringsinställningarna som används av detta specifika arbetsflöde och leverantörens aktuella instruktioner för dess kunddomänkonfiguration som stöds.
- Alla senaste ändringar DNS , nyckel, gateway eller avsändaradress och dess tidsstämpel.
Inkludera inte kontolösenord, API-nycklar, privata DKIM nycklar eller orelaterade kundregister. Behåll det ursprungliga provet oförändrat om signaturverifiering kan behövas."
Denna begäran skapar en gemensam referenspunkt. Det förutsätter inte att leverantörens delade infrastruktur eller en välbekant käll-IP bevisar att din organisation har auktoriserat avsändaren.
Matcha varje svar till en diagnostisk fråga
Bygg ett litet bevisark innan du föreslår ändringar.
- Bevis: Från domän; Fråga den besvarar: Vilken författardomän utvärderar DMARC ?
- Bevis: SPF resultat och utvärderad domän; Frågan den besvarar: Har SPF godkänt en identitet som är relevant för denna rutt?
- Bevis: DKIM resultat,
d=ochs=; Fråga den besvarar: Vilka signeringsidentiteter har verifierats och vilka nycklar användes? - Bevis: Tillämplig policy och anpassningssätt; Fråga den besvarar: Överensstämmer en passerande identitet under den relevanta regeln?
- Bevis: SMTP svar eller slutlig disposition; Fråga den besvarar: Vad hände egentligen med leveransen?
- Bevis: Ändra tidsstämplar och aktuella DNS -observationer; Fråga den besvarar: Kan konfigurationstidpunkten förklara olika observationer?
Identitets- och anpassningskontrollerna följer RFC 9989 §5.3.3, RFC 9989 §5.3.4 och RFC 9989 §5.3.5. Arbetsbladet och förfrågningsformatet är praktiska rekommendationer.
Hantera saknade bevis explicit
Om avsändaren bara anger sin konsolstatus, be om ett mottaget prov från det faktiska arbetsflödet. Om en mottagare avvisade innan han accepterade meddelandet, bekräfta att det kanske inte finns någon slutlig postlådekopia. Använd avsändarens utgående spårning, avvisningssvar och den mottagande operatörens loggar där sådana finns.
Om nuvarande DNS skiljer sig från meddelandets tidsstämpel, gör inte anspråk på att det bevisar vad den tidigare mottagaren såg. Be om ändringshistoriken eller en ny kontrollerad reproduktion. Om leverantören inte kan erbjuda en anpassad identitet som stöds, registrera det kapacitetsgapet och det påverkade arbetsflödet istället för att uppfinna DNS värden.
Avsluta undersökningen med en identitetsjämförelse före och efter, den exakta förändringen och ett nytt pålitligt resultat. Länka det beviset till avsändarens inventering. De guide för uppriktningsfel hjälper till att tolka det, medan Sekretessguide för rapportering stöder beslut om bevarade bevis.
Gör nästa beslut tydligt
Om det bara finns en skärmdump av konsolen, markera den utvärderade SPF domänen, justerad DKIM identitet och mottagarens förtroendegräns som saknad. Be om dessa fält istället för att deklarera en DNS fix. Om avslag förhindrade postlådeleverans, använd istället SMTP svaret och avsändarspårningen. Spela in varje observations tidsstämpel separat från senare DNS inspektion; inget originalmeddelande har samlats in eller verifierats här.