Under RFC 9989 §5.4, kan ett meddelande misslyckas DMARC och fortfarande accepteras. En annan kan passera DMARC och bli avvisad. Dessa observationer räcker inte för att dra slutsatsen att mottagaren ignorerade autentisering eller att domänens DNS post är bruten.
DMARC ger mottagaren domänautentiseringsbevis och en domänägarpolicy att överväga. Mottagaren styr även sin egen posthantering. En utredning måste separera dessa lager innan den föreslår en lösning.
Använd tre kolumner istället för en status
Anteckna den publicerade policyn, meddelandets DMARC valideringsresultat och den faktiska mottagaråtgärden separat. Var och en svarar på en annan fråga.
- Lager: Ägarpolicy; Fråga den besvarar: Vilken bedömning begärde den tillämpliga domänregistreringen?; Användbara bevis: Exakt policypost och upptäcktsväg vid relevant tidpunkt
- Lager: Validering; Fråga som den besvarar: Stämde en passerande autentiserad identitet med From?; Användbara bevis: Mottagarens autentiseringsresultat och relevanta identiteter
- Lager: Hantering; Fråga den besvarar: Vad gjorde den här mottagaren med detta meddelande?; Användbara bevis: SMTP svar, leveransbevis eller mottagarloggar
En politik för ingen betyder inte det SPF, DKIM och annan filtrering stängs av. Ett pass tvingar inte in inkorgsplacering. En avvisningspolicy tar inte bort mottagarens analys av legitima indirekta rutter eller andra relevanta bevis.
Till exempel kan en avsändare fixa DKIM korrekt och ändå få ett avslag orsakat av en separat mottagarregel. Att upprepade gånger ändra DMARC DNS i den situationen skapar förändringsrisk utan att ta itu med den returnerade orsaken.
Arbeta igenom ett accepterat misslyckande
Överväg ett syntetiskt meddelande med From notices@accounts.example . Dess tillämpliga policybegäranden avvisas, men den slutliga mottagaren registrerar DMARC fel efter en indirekt rutt. Meddelandet accepteras under mottagarens lokala hantering.
Den första undersökningen är om meddelandet var en legitim indirekt leverans, ett konfigurationsfel eller otillåten användning. Bevara den anslutande källan, SPF identiteten, DKIM domäner och -resultat, relevant vidarebefordran eller listbeteende och alla tillgängliga skäl för policy-åsidosättning.
RFC 9989 RFC 9989 §7.4 diskuterar mottagaranalys bortom avvisande, inklusive interoperabilitet med indirekt e-post. Acceptans är därför inte ett bevis på en framgångsrik DMARC validering. Det faktum att mottagaren accepterade meddelandet bevisar inte heller att meddelandet var godartat.
Kontrollägaren bör lösa den legitima vägen om en sådan finns, dokumentera mottagarspecifika fynd och undvika att hävda att policyn garanterar samma åtgärd överallt. Genomgången av sammanlagd rapport hjälper till att hålla autentiserings- och dispositionsfält åtskilda.
Arbeta igenom ett avvisat pass
Tänk nu på ett annat syntetiskt budskap. Det är justerat DKIM signatur passerar och mottagaren registrerar DMARC pass, men SMTP svaret identifierar en annan policy eller missbruksproblem.
DMARC har svarat på frågan om domänautentisering. Nästa uppgift är att granska det faktiska avslaget, inklusive den fullständiga svarstexten och avsändarens relevanta tjänstebevis. Ett innehåll, mottagare, rykte eller annan lokal regel kan påverka hanteringen utan att det DMARC resultatet ändras.
Lägg inte till icke-relaterad sändningsinfrastruktur till SPF bara för att göra alla visade mekanismer gröna. Fastställ först vilken identitet och rutt mottagaren utvärderade och vilket skäl som förhindrade leverans. En bred behörighetsändring kan skapa ett nytt problem samtidigt som avslaget lämnas oförändrat.
Behandla saknade och felresultat noggrant
Inte alla meddelanden ger ett vanligt godkänt eller underkänt. En tillämplig post som saknas skiljer sig från ett misslyckande att autentisera under en befintlig post. Ett problem med DNS -tillgänglighet skiljer sig från en permanent felaktig policy.
RFC 9989 RFC 9989 §9.2 skiljer dessa resultatvillkor åt. Under RFC 9989 §5.3.6, om DNS fel förhindrar nödvändig DMARC validering, kan ett normalt godkänt eller misslyckande inte fastställas och hanteringen faller på mottagarens andra beslut. Fånga felet och den berörda frågan, snarare än att behandla det som ett bevis på att avsändaren är skadlig.
Ett tillfälligt avslag kan bjuda in ytterligare ett leveransförsök; ett senare försök kan se ett annat DNS tillstånd. Det är därför en skärmdump av dagens rekord är ett svagt bevis på ett meddelande som behandlades i går.
Be om bevis som kan lösa skillnaden
För varje omtvistat meddelande, samla en liten ärendepost:
- Meddelande- och sändningsförsöksidentifierare, med känsliga data redigerade på lämpligt sätt för triage. Håll ett omodifierat original kontrollerat separat om DKIM -återverifiering behövs, eftersom ändring av signerat innehåll kan påverka verifiering enligt RFC 6376 §3.7.
- Tidsstämpel och mottagare, inklusive hela SMTP svaret om tillgängligt.
- Synlig från domän, SPF-utvärderad domän och alla relevanta DKIM signeringsdomäner.
- Betrodda mottagarautentiseringsresultat, där ett meddelande levererades eller loggar är tillgängliga.
- Tillämplig policy och DNS svar kopplade till det bearbetningsfönstret.
- Känd indirekt rutt och eventuell tillgänglig åsidosättning eller lokal regelförklaring.
En avvisad transaktion kan ge någon leverans meddelanderubriker alls. Använd avsändarens försöksloggar, svar och mottagarhjälp istället för att kräva ett huvudexempel som inte kan existera för det försöket. Under RFC 8601 §7.1, undvik att behandla opålitliga rubriker som lagts till före mottagningsgränsen som mottagarens egen slutsats.
Stäng höljet med den minsta ändringen som stöds
Lösningen kan vara att korrigera en avsändaridentitet, åtgärda ett DNS defekt, reparera en rapportinsamlare eller åtgärda ett mottagarspecifikt problem. Det kan också vara ett dokumenterat interoperabilitetsbeslut för en viss legitim rutt.
Testa om det påverkade flödet efter ändringen och bevara de nya bevisen. Om resultatet fortfarande skiljer sig åt mellan mottagare, registrera vad var och en faktiskt observerade och vilken skillnad i implementering eller lokal policy som förblir obekräftad. Generalisera inte från en mottagares svar till hela ekosystemet.
En användbar förklaring identifierar ägarpolicyn, valideringsresultatet och hanteringsbeslutet separat, och pekar sedan på bevis som kopplar dem. Det räcker för att vända en uppenbar motsägelse till en utredning med en ägare och en nästa åtgärd.
Anteckna ett beslut som kan omprövas
För fallet med accepterat misslyckande, skriv p=reject, dmarc=fail och accepteras som separata observationer. För fallet med avvisat godkänt, behåll dmarc=pass och den faktiska returnerade orsaken till avvisningen; tillverka inte en DMARC reparation. RFC 9990 §3.1.1 och RFC 9990 §3.1.6 likaså separat aggregerad utvärdering, disposition och åsidosättande information. Båda fallen är hypotetiska, inte infångade mottagarloggar.