Implementera Domain-based Message Authentication, Reporting and Conformance (DMARC)
Syftet med det här dokumentet är att ge läsaren ytterligare information om e-postautentiseringsmetoden, DMARC. Genom att förklara hur DMARC fungerar och dess olika policyalternativ kan läsarna bättre förstå DMARC påverkan på e-postleveransen.
Vad är DMARC? about
Domain-based Message Authentication, Reporting and Conformance är en autentiseringsmetod för e-post som gör att domänägare kan skydda sin domän från obehörig användning. DMARC ger också feedback om e-postautentiseringsstatus och låter avsändare styra vad som händer med e-postmeddelanden som inte kan autentiseras. Detta inkluderar alternativ för att övervaka, sätta i karantän eller avvisa e-post beroende på vilken DMARC-policy som har implementerats.
DMARC har tre policyalternativ:
- Monitor (p=none): Instruerar postlådeprovidern/ISP att göra vad de normalt skulle göra med meddelandet.
- Karantän (p=karantän): Instruerar postlådeprovidern/ISP att leverera e-post som inte skickar DMARC till mottagarens skräppostmapp.
- Avvisa (p=avvisa): Instruerar postlådeprovidern/ISP att blockera e-post som inte godkänns av DMARC, vilket resulterar i ett studs.
Hur fungerar DMARC? how
SPF och DKIM används båda för att associera ett e-postmeddelande med en domän och fungerar tillsammans för att autentisera e-post. DMARC tar detta steg längre och hjälper till att förhindra förfalskning genom att matcha domänen som kontrolleras av DKIM och SPF. För att skicka DMARC måste ett meddelande skicka SPF eller DKIM. Om båda dessa inte kan autentiseras kommer DMARC att misslyckas och e-postmeddelandet levereras enligt din valda DMARC-policy.
Varför ska DMARC implementeras? why
DMARC är valfritt, och även om det inte krävs är det kostnadsfritt och gör det möjligt för e-postmottagare att enkelt identifiera autentiseringen av e-postmeddelanden, vilket kan förbättra leveransen. En av de största fördelarna med DMARC är att det ger rapporter om vilka meddelanden som inte godkänns i SPF och/eller DKIM. Det ger också avsändarna en viss kontroll över vad som händer med e-post som inte godkänns på någon av dessa autentiseringsmetoder. Genom DMARC rapportering får avsändarna insyn i vilka meddelanden som inte fungerar i DMARC, vilket gör det möjligt att vidta åtgärder för att minska antalet ytterligare fel.
Metodtips för att implementera DMARC best-practice
Eftersom DMARC är valfritt kommer det inte att konfigureras som standard på någon ESP:s plattform. En DMARC-post måste skapas i DNS för din domän för att den ska fungera. Du måste dessutom ange en e-postadress där du vill ange var DMARC rapporter ska finnas inom organisationen. Det är en god praxis att
Vi rekommenderar att du långsamt implementerar DMARC genom att eskalera din DMARC-policy från p=none till p=karantän, till p=reject när du får DMARC insikt om DMARC potentiella effekt.
-
Analysera den feedback du får och använder (p=none), som instruerar mottagaren att inte utföra några åtgärder mot meddelanden som inte kan autentiseras, men ändå skicka e-postrapporter till avsändaren. Granska och åtgärda problem med SPF/DKIM om legitimt meddelande inte kan autentiseras.
-
Kontrollera om SPF och DKIM är justerade och skickar autentisering för alla giltiga e-postmeddelanden och flytta sedan principen till (p=karantän), vilket innebär att den mottagande e-postservern ska skicka e-postmeddelanden som inte kan autentiseras (detta innebär vanligtvis att meddelandena placeras i skräppostmappen).
-
Justera princip till (p=avvisa). p= avvisningsprincipen innebär att mottagaren helt nekar (studsar) alla e-postmeddelanden för domänen som inte kan autentiseras. När den här principen är aktiverad har bara e-post som verifieras som 100 % autentiserad av din domän en chans att skickas till Inkorgen.
note NOTE Använd denna policy med försiktighet och fastställ om den är lämplig för din organisation.
DMARC Reporting reporting
DMARC erbjuder möjlighet att få rapporter om e-postmeddelanden som inte godkänns i SPF/DKIM. Det finns två olika rapporter som genereras av ISP-tjänstleverantörer som en del av autentiseringsprocessen och som avsändare kan ta emot via RUA/RUF-taggarna i sin DMARC-policy:
- Aggregate Reports (RUA): innehåller inte någon PII (Personally Identiitable Information) som skulle vara GDPR-känslig.
- Forensiska rapporter (RUF): Innehåller e-postadresser som är GDPR-känsliga. Innan informationen används är det bäst att kontrollera internt hur man hanterar information som måste uppfylla GDPR.
Det viktigaste användningsområdet för dessa rapporter är att få en översikt över e-postmeddelanden som försöker förfalskas. Det här är mycket tekniska rapporter som är bäst sammanställda via ett verktyg från tredje part. Några företag som specialiserar sig på DMARC övervakning är:
Exempel på DMARC Record example
v=DMARC1; p=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf@emaildefense.proofpoint.co
DMARC-taggar och vad de gör tags
DMARC-poster har flera komponenter som kallas DMARC-taggar. Varje tagg har ett värde som anger en viss aspekt av DMARC.
1: Generera en rapport om något misslyckas
d: Generera en rapport om DKIM misslyckas
s: Generera rapport om SPF misslyckas
rua=mailto:aggrep@example.comruf=mailto:authfail@example.comDMARC & ADOBE CAMPAIGN campaign
En vanlig orsak till DMARC-fel är felpassning mellan adressen"Från" och"Fel till" eller"Retursökväg". För att undvika detta bör du kontrollera adressinställningarna"Från" och"Fel till" i leveransmallarna när du konfigurerar DMARC.
-
Granska i leveransmallen vilken adress som är angiven som din"Från"-adress.
-
Här väljer du Egenskaper som gör att du kan redigera leveransmallen ytterligare. I det här fönstret väljer du SMTP och avmarkerar Använd standardfeladressen som definierats för plattformen om det är markerat. Leveransmallar i Adobe Campaign markerar den här kryssrutan som standard. Standardfeladressen får inte vara den adress som är associerad med Från adress i den här leveransmallen.
-
När den här rutan är avmarkerad visas ett textfält där du kan ange en unik feladress som använder samma domän som anges i Från adress.
När dessa ändringar har sparats kan du gå vidare med din DMARC-implementering med korrekt domänjustering.