E-postautentisering i EOP
Viktigt
Den förbättrade Microsoft 365 Defender-portalen är nu tillgänglig. Med den här nya upplevelsen kommer Defender för Endpoint, Defender för Office 365, 365 Microsoft 365 Defender och annat till Microsoft Defender for Cloud Apps. Läs om de senaste.
Gäller för
- Exchange Online Protection
- Microsoft Defender för Office 365 Abonnemang 1 och Abonnemang 2
- Microsoft 365 Defender
E-postautentisering (kallas även för e-postverifiering) är en grupp standarder som försöker sluta förfalskning (e-postmeddelanden från falska avsändare). I alla Microsoft 365-organisationer använder EOP dessa standarder för att verifiera inkommande e-post:
E-postautentisering verifierar att e-postmeddelanden från en avsändare (till exempel laura@contoso.com) är giltiga och kommer från förväntade källor för den e-postdomänen (till exempel contoso.com.)
Resten av den här artikeln förklarar hur dessa tekniker fungerar och hur EOP använder dem för att kontrollera inkommande e-post.
Använda e-postautentisering för att förhindra förfalskning
DMARC förhindrar förfalskning genom att granska från adress i meddelanden. Från Adress är avsändarens e-postadress som användarna ser i sina e-postklienter. Destinationens e-postorganisationer kan också verifiera att e-postdomänen har passerat SPF eller DKIM. Med andra ord har domänen verifierats och därför skickas inte avsändarens e-postadress.
DNS-poster för SPF, DKIM och DMARC (gemensamt känd som e-autentiseringspolicy) är valfria. Domäner med starka e-autentiseringsprinciper som microsoft.com och skype.com är skyddade mot falskt fel. Men domäner med svagare e-autentiseringspolicy, eller ingen politik alls, är främsta mål för att bli förfalskade.
Till och med mars 2018 har endast 9 % av företag på Fortune 500-listan publicerat starka principer för e-postautentisering. De återstående 91% av företagen kan bli förfalskade av en angripare. Om du inte har en annan funktion för e-postfiltrering på plats kan e-post från falska avsändare i dessa domäner levereras till användare.

Antalet små till medelstora företag som publicerar starka principer för e-postautentisering är mindre. Och antalet är ännu mindre för e-postdomäner utanför Nordamerika och västra Europa.
Brist på starka e-autentiseringsprinciper är ett stort problem. Medan organisationer kanske inte förstår hur e-autentisering fungerar, förstår angriparna fullt ut och de drar fördel. På grund av phishing-problem och det begränsade införandet av principer för stark e-postautentisering använder Microsoft implicit e-postautentisering för att kontrollera inkommande e-post.
Implicit e-autentisering är en förlängning av vanliga policyer för e-autentisering. Dessa tillägg inkluderar avsändarens rykte, avsändarhistorik, mottagarhistorik, beteendeanalys och annan avancerad teknik. I avsaknad av andra signaler från dessa tillägg markeras meddelanden som skickas från domäner som inte använder e-autentiseringspolicyer som falsk.
Du kan läsa Microsofts allmänna meddelande i Ett hav av nätfiskare, del 2 – förbättrat skydd mot förfalskning i Microsoft 365.
Sammansatt autentisering
Om det inte finns traditionella SPF-, DKIM-och DMARC-poster i en domän, överförs inte tillräcklig information om autentiserings status vid de post kontrollerna. Därför har Microsoft utvecklat en algoritm för implicit e-autentisering. Med den här algoritmen kombineras flera signaler till ett enda värde som kallas oseparerad autentisering eller compauth för kort. compauth värdet stämplas i verifierings resultat rubriken i meddelande rubrikerna.
Authentication-Results:
compauth=<fail | pass | softpass | none> reason=<yyy>
Dessa värden förklaras i Meddelanderubriken Authentication-results.
Genom att granska meddelandehuvudena kan administratörer eller slutanvändare fastställa hur Microsoft 365 upptäckte att avsändaren är falsk.
Varför e-postautentisering inte alltid är tillräckligt för att stoppa förfalskning
Att bara förlita sig på e-postautentisering för att avgöra om ett inkommande meddelande har manipulerats har följande begränsningar:
Den sändande domänen kanske saknar de nödvändiga DNS-posterna eller så är posterna felaktigt konfigurerade.
Källdomänen har konfigurerat DNS-poster som har konfigurerats korrekt men domänen stämmer inte överens med domänen i från-adressen. SPF och DKIM kräver inte att domänen används i från-adressen. Angripare eller legitima tjänster kan registrera en domän, konfigurera SPF och DKIM för domänen och använda en helt annan domän i Från-adressen. Meddelanden från avsändare inom den här domänen kommer att skicka SPF och DKIM.
Sammansatt autentisering kan lösa de här begränsningarna genom att godkänna meddelanden som annars skulle ha misslyckat e-postverifiering.
För enkelhetens skull ska följande exempel koncentrera sig på resultat av e-postverifiering. Andra backend-intelligensfaktorer kan identifiera oseriösa meddelanden som klarar sig förbi e-postautentiseringen eller meddelanden som inte bedöms vara legitima av e-postautentiseringen.
Exempel: fabrikam.com-domänen har inga SPF-, DKIM- eller DMARC-poster. Meddelanden från avsändare i fabrikam.com-domänen kan misslyckas sammansatt autentisering (Observera compauth värde och anledning):
Authentication-Results: spf=none (sender IP is 10.2.3.4)
smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
(message not signed) header.d=none; contoso.com; dmarc=none
action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com
Om fabrikam.com konfigurerar en SPF utan en DKIM-post kan meddelandet klara sammansatt autentisering. Domänen som har passerat SPF-kontroller är justerad mot domänen i Från-adressen:
Authentication-Results: spf=pass (sender IP is 10.2.3.4)
smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
(message not signed) header.d=none; contoso.com; dmarc=bestguesspass
action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com
Om fabrikam.com konfigurerar en DKIM-post utan en SPF-post kan meddelandet klara sammansatt autentisering. Domänen i DKIM-signaturen är justerad mot domänen i Från-adressen:
Authentication-Results: spf=none (sender IP is 10.2.3.4)
smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
(signature was verified) header.d=outbound.fabrikam.com;
contoso.com; dmarc=bestguesspass action=none
header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com
Om domänen i SPF eller DKIM-signaturen inte överensstämmer med domänen i från-adressen kan meddelandet misslyckas med sammansatt autentisering:
Authentication-Results: spf=none (sender IP is 192.168.1.8)
smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
(signature was verified) header.d=maliciousdomain.com;
contoso.com; dmarc=none action=none header.from=contoso.com;
compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com
Lösning för legitima avsändare som skickar icke-autentiserade e-postmeddelanden
Microsoft 365 håller reda på vilka som skickar icke-autentiserad e-post till organisationen. Om tjänsten tycker att avsändaren inte är legitim kommer den att markera meddelanden från den här avsändaren som ett sammansatt autentiseringsfel. För att undvika denna dom kan du använda rekommendationerna i detta avsnitt.
Konfigurera e-postautentisering för domäner som du äger
Du kan själv använda den här metoden till att lösa förfalskning inom organisationen och förfalskning mellan domäner i fall där du äger eller interagerar med flera klientorganisationer. Det hjälper också till att lösa förfalskning mellan domäner där du skickar till andra kunder inom Microsoft 365 och också tredje parter med andra värdar.
- Konfigurerar SPF-poster för dina domäner.
- Konfigurera DKIM poster för dina primära domäner.
- Överväg att konfigurera DMARC-poster för att fastställa dina legitima avsändare.
Microsoft tillhandahåller inte detaljerade implementeringsriktlinjer för SPF, DKIM eller DMARC. Det finns dock många information online. Det finns också tredjepartsföretag som är dedikerade till att hjälpa din organisation att ställa in autentiseringsposter via e-post.
Du vet inte för alla källor för din e-post
Många domäner publicerar inte SPF-poster eftersom de inte vet alla e-postkällor för meddelanden i sina domäner. Börja med att publicera en SPF-post som innehåller alla e-postkällor som du vet om (särskilt där din företagstrafik finns), och publicera den neutrala SPF-principen ?all. Till exempel:
fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ?all"
Det här exemplet innebär att e-post från din företagsinfrastruktur ska skicka e-postautentisering, men e-post från okända källor kommer att gå tillbaka till neutrala.
Microsoft 365 behandlar inkommande e-post från din företagsinfrastruktur som autentiserad. E-post från oidentifierade källor kan fortfarande markeras som falsk om det misslyckas med implicit autentisering. Men det här är ändå en förbättring jämfört med att all e-post markeras som falsk av Microsoft 365.
När du har börjat med en SPF fallback-princip för ?all kan du gradvis upptäcka och ta med fler e-postkällor för dina meddelanden och sedan uppdatera SPF-posten med en striktare policy.
Konfigurera tillåtna avsändare av icke-autentiserad e-post
Du kan även använda insikt om förfalskningsinformation och Lista över Tillåt/Blockera för klientorganisation för att tillåta avsändare att skicka icke-autentiserade meddelanden till organisationen.
För externa domäner är den falska användaren domänen i från-adressen, medan den sändande infrastrukturen är antingen käll-IP-adressen (indelad i/24 CIDR-intervall), eller organisationsdomänen för PTR-posten.
Skapa en tillåta-post för avsändare/mottagare-paret
I Skapa listor över betrodda avsändare i Microsoft 365 finns information om hur du kringgår skräppostfiltrering, t.ex. vissa delar av nätfiskefiltrering, men inte filter för skadlig kod för vissa avsändare.
Be avsändaren att konfigurera e-postautentisering för domäner som du inte äger
På grund av problem med skräppost och nätfiske rekommenderar Microsoft att alla avsändare konfigurerar e-postautentisering. I stället för att konfigurera manuella åsidosättningar i din organisation kan du be en administratör i den sändande domänen att konfigurera sina poster för e-postverifiering.
Även om de inte har behövt publicera poster för e-postautentisering tidigare ska de göra det om de skickar e-post till Microsoft.
Konfigurera SPF för att publicera domänens avsändande IP-adresser och konfigurera DKIM (om tillgängligt) för att signera meddelanden digitalt. De bör även överväga att konfigurera DMARC-poster.
Om användarna massutskick för att skicka e-post åt dem, ska du kontrollera att domänen i från-adressen (om den tillhör dem) stämmer överens med den domän som beviljar SPF- eller DMARC.
Kontrollera att följande platser (om de använder dem) ingår i SPF-posten:
- Lokala e-postservrar.
- E-post som skickas från en SaaS-leverantör (Software as-as-service).
- E-post som skickas från en molnvärdtjänst (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services osv.).
För små domäner som är värd för en ISP konfigurerar du SPF-posten enligt anvisningarna från leverantören.
Det kan till en början vara svårt att få avsändardomäner att autentisera men med tiden, när allt fler e-postfilter markerar deras e-post som skräppost eller till och med avvisar dem så kommer de att konfigurera korrekta poster för att säkerställa bättre leverans. Deltagande i kampen mot nätfiske, och det kan minska risken för nätfiske i organisationer och organisationer som de skickar e-post till.
Information för leverantörer av infrastruktur (ISP:er, ESP:er eller molnvärdtjänster)
Om du är värd för en domäns e-post eller tillhandahåller infrastruktur som kan skicka e-post, ska du göra följande steg:
Se till att dina kunder har dokumentation som förklarar hur kunderna ska konfigurera sina SPF-poster
Överväg att signera DKIM-signaturer på utgående e-post även om kunden inte uttryckligen konfigurerar det (signera med en standarddomän). Du kan till och med dubbelsignera e-postmeddelandet med DKIM-signaturer (en gång med kundens domän om det har konfigurerats och en andra gång med företagets DKIM-signatur)
Leveransen till Microsoft garanteras inte även om du autentiserar e-post som kommer från din plattform men det ser åtminstone till att Microsoft inte markerar din e-post som skräppost för att den inte autentiseras.
Relaterade länkar
Mer information om bästa praxis för tjänsteleverantörer finns i M3AAWG Mobile Messaging Best Practices för tjänsteleverantörer.
Lär dig hur Office 365 använder SPF och stöder DKIM-validering: