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 politiska alternativ kommer läsarna att få en bättre förståelse för DMARC:s påverkan på e-postleveransen.
Vad är DMARC? about
Domänbaserad meddelandeautentisering, rapportering och överensstämmelse är en e-postautentiseringsmetod 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 tillåter avsändare att 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 politiska alternativ:
- 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 den domän som kontrolleras av DKIM och SPF. För att skicka DMARC måste ett meddelande skicka SPF eller DKIM. Om båda dessa misslyckas 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 erbjuder rapportering 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 misslyckas med DMARC, vilket gör det möjligt att vidta åtgärder för att minska ytterligare fel.
Bästa metoder 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. Dessutom krävs en e-postadress som du väljer för att ange var DMARC-rapporter ska finnas inom organisationen. Det är en god praxis att
Vi rekommenderar att du långsamt implementerar DMARC genom att trahera din DMARC-policy från p=none till p=karantän, till p=reject när du får DMARC-förståelse för DMARC:s 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 även problem med SPF/DKIM om giltiga meddelanden 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 anger att den mottagande e-postservern ska placera e-postmeddelanden som inte kan autentiseras (detta innebär vanligtvis att meddelandena placeras i skräppostmappen).
-
Justera princip till (p=avvisa). Principen p=reject om att avvisa 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 är det bara e-postmeddelanden som verifieras som 100 % autentiserade av din domän som har en chans att skickas till Inkorgen.
note note NOTE Använd denna policy med försiktighet och fastställ om den är lämplig för din organisation.
DMARC-rapportering reporting
DMARC kan ta emot rapporter om e-postmeddelanden som saknar 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 deras 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-post 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 en 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.