E-postautentisering i Microsoft 365

Tips

Visste du att du kan prova funktionerna i Microsoft Defender XDR för Office 365 plan 2 kostnadsfritt? Använd den 90 dagar långa Defender för Office 365 utvärderingsversionen på Microsoft Defender portalens utvärderingshubb. Lär dig mer om vem som kan registrera dig och utvärderingsvillkoren här.

Som En Microsoft 365-organisation med postlådor i Exchange Online, eller en fristående Exchange Online Protection (EOP)-organisation utan Exchange Online postlådor, är det viktigt att skydda integriteten för e-postmeddelanden från avsändare i dina domäner. Mottagarna bör känna sig säkra på att meddelanden från avsändare i din domän verkligen kommer från avsändare i din domän.

Email autentisering (även kallat e-postvalidering) är en grupp standarder för att identifiera och förhindra leverans av e-postmeddelanden från förfalskade avsändare (även kallat förfalskning). Falska avsändare används ofta i kompromisser för affärsmeddelanden (BEC), nätfiske och andra e-postattacker. Dessa standarder omfattar:

  • SPF (Sender Policy Framework): Anger de e-postservrar för källan som har behörighet att skicka e-post för domänen.
  • DomainKeys Identified Mail (DKIM): Använder en domän för att digitalt signera viktiga element i meddelandet för att säkerställa att meddelandet inte har ändrats under överföringen.
  • Domänbaserad meddelandeautentisering, rapportering och överensstämmelse (DMARC): Anger åtgärden för meddelanden som inte klarar SPF- eller DKIM-kontroller efter avsändare i domänen och anger var DMARC-resultaten ska skickas (rapportering).
  • Autentiserad mottagen kedja (ARC): Bevarar ursprunglig e-postautentiseringsinformation av kända tjänster som ändrar meddelanden under överföring. Mål-e-postservern kan använda den här informationen för att autentisera meddelanden som annars skulle misslyckas med DMARC.

Det är viktigt att inse att dessa standarder är beroende av varandra ochfungerar tillsammans för att ge bästa möjliga e-postskydd mot förfalsknings- och nätfiskeattacker. Allt annat än alla e-postautentiseringsmetoder resulterar i undermåligt skydd.

Information om hur du konfigurerar e-postautentisering för e-post som skickas från Microsoft 365-organisationer med postlådor i Exchange Online eller fristående Exchange Online Protection organisationer (EOP) utan Exchange Online postlådor finns i följande artiklar:

Information om hur du förhindrar fel vid e-postautentisering på grund av tjänster som ändrar inkommande e-post som skickas till din Microsoft 365-organisation finns iKonfigurera betrodda ARC-förseglare.

Resten av den här artikeln förklarar:

Varför internet-e-post behöver autentisering

Smtp-e-post (Simple Mail Transfer Protocol) på Internet gör ingen ansträngning för att verifiera att meddelandesändaren är den som de påstår sig vara.

Ett STANDARD-SMTP-e-postmeddelande består av ett meddelandekuvert och meddelandeinnehåll:

  • Meddelandekuvertet innehåller information om hur du skickar och tar emot meddelandet mellan SMTP-servrar. Meddelandekuvertet beskrivs i RFC 5321. Mottagarna ser aldrig meddelandekuvertet eftersom det genereras under meddelandeöverföringsprocessen.
  • Meddelandeinnehållet innehåller meddelandehuvudfält (kallas gemensamt för meddelanderubriken) och meddelandetexten. Meddelandehuvudet beskrivs i RFC 5322.

På grund av den här designen har ett meddelande flera avsändarvärden:

  • MAIL FROM-adressen (kallas 5321.MailFrom även adress, P1-avsändare eller kuvertsändare) är den e-postadress som används vid överföring av meddelandet mellan SMTP-e-postservrar. Den här adressen registreras vanligtvis i fältet Return-Path-huvud i meddelandehuvudet (även om e-postservern för källan kan ange en annan e-postadress för returväg ). Den här e-postadressen används i icke-leveransrapporter (kallas även NDR eller studsande meddelanden).
  • Från-adressen (kallas 5322.From även adress eller P2-avsändare) är e-postadressen i fältet Från-huvud och är avsändarens e-postadress som visas i e-postklienter.

I följande exempel visas den förenklade avskriften av en giltig meddelandeöverföring mellan två SMTP-e-postservrar:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

I det här exemplet:

  • E-postservern för källan identifierar sig som woodgrovebank.com till mål-e-postservern tailspintoys.com i HELO-kommandot.
  • Meddelandemottagaren är astobes@tailspintoys.com.
  • MAIL FROM-adressen i meddelandekuvertet (används för att överföra meddelandet mellan SMTP-e-postservrar) är dubious@proseware.com.
  • Från-adressen som visas i mottagarens e-postklient är security@woodgrovebank.com.

Även om det här meddelandet är giltigt enligt SMTP matchar inte domänen för MAIL FROM-adressen (proseware.com) domänen i Från-adressen (woodgrovebank.com). Det här meddelandet är ett klassiskt exempel på förfalskning, där avsikten sannolikt kommer att lura mottagaren genom att maskera den sanna källan till meddelandet som ska användas i en nätfiskeattack.

SMTP-e-post behöver hjälp med att verifiera att meddelandeavsändare är de som de påstår sig vara!

Hur SPF, DKIM och DMARC fungerar tillsammans för att autentisera e-postavsändare

I det här avsnittet beskrivs varför du behöver SPF, DKIM och DMARC för domäner på Internet.

  • SPF: Enligt beskrivningen i Konfigurera SPF för att identifiera giltiga e-postkällor för din Microsoft 365-domän använder SPF en TXT-post i DNS för att identifiera giltiga e-postkällor från MAIL FROM-domänen och vad du ska göra om mål-e-postservern tar emot e-post från en odefinierad källa ("svårt misslyckas" med att avvisa meddelandet; "soft fail" för att acceptera och markera meddelandet).

    SPF-problem:

    • SPF validerar endast källor för avsändare i MAIL FROM-domänen. SPF tar inte hänsyn till domänen i från-adressen eller justeringen mellan domänerna MAIL FROM och From:

      • En angripare kan skicka e-post som klarar SPF-autentisering (en falsk negativ) genom att följa dessa steg:
        • Registrera en domän (till exempel proseware.com) och konfigurera SPF för domänen.
        • Skicka e-post från en giltig källa för den registrerade domänen med e-postadresserna Från i en annan domän (till exempel woodgrovebank.com).
      • En legitim e-posttjänst som skickar e-post åt andra domäner kan styra MAIL FROM-adressen. De andra domänerna och MAIL FROM-domänen matchar inte, så meddelandena kan inte klara SPF-autentisering (en falsk positiv identifiering).

    • SPF bryter efter att meddelanden påträffa serverbaserad vidarebefordran av e-post som omdirigerar eller vidarebefordrar meddelanden.

      • Serverbaserad e-postvidarebefordring ändrar meddelandekällan från den ursprungliga servern till vidarebefordrande servern.
      • Vidarebefordrande servern har inte behörighet att skicka e-post från den ursprungliga MAIL FROM-domänen, så meddelandet kan inte klara SPF-autentisering (en falsk positiv identifiering).

    • Varje domän och eventuella underdomäner kräver sina egna enskilda SPF-poster. Underdomäner ärver inte SPF-posten för den överordnade domänen. Det här beteendet blir problematiskt om du vill tillåta e-post från definierade och använda underdomäner, men förhindra e-post från odefinierade och oanvända underdomäner.

  • DKIM: Enligt beskrivningen i Konfigurera DKIM för att signera e-post från din Microsoft 365-domän använder DKIM en domän för att digitalt signera viktiga element i meddelandet (inklusive Från-adressen) och lagrar signaturen i meddelandehuvudet. Målservern verifierar att de signerade elementen i meddelandet inte har ändrats.

    Så här hjälper DKIM SPF: DKIM kan verifiera meddelanden som misslyckas med SPF. Till exempel:

    • Meddelanden från en e-postvärdtjänst där samma MAIL FROM-adress används för e-post från andra domäner.
    • Meddelanden som påträffar serverbaserad vidarebefordran av e-post.

    Eftersom DKIM-signaturen i meddelandehuvudet inte påverkas eller ändras i dessa scenarier kan dessa meddelanden skicka DKIM.

    DKIM-problem: Domänen som DKIM använder för att signera ett meddelande behöver inte matcha domänen i från-adressen som visas i e-postklienter.

    Precis som med SPF kan en angripare skicka e-post som klarar DKIM-autentisering (falskt negativt) genom att följa dessa steg:

    • Registrera en domän (till exempel proseware.com) och konfigurera DKIM för domänen.
    • Skicka e-post med e-postadresserna Från i en annan domän (till exempel woodgrovebank.com).

  • DMARC: Enligt beskrivningen i Konfigurera DMARC för att verifiera Från-adressdomänen för avsändare i Microsoft 365 använder DMARC SPF och DKIM för att söka efter justering mellan domänerna i MAIL FROM- och From-adresserna. DMARC anger också den åtgärd som mål-e-postsystemet ska vidta för meddelanden som inte klarar DMARC och identifierar var DMARC-resultat ska skickas (både pass och fail).

    Så här hjälper DMARC SPF och DKIM: Som tidigare beskrivits gör SPF inget försök att matcha domänen i MAIL FROM-domänen och Från-adresser. DKIM bryr sig inte om domänen som signerade meddelandet matchar domänen i Från-adressen.

    DMARC åtgärdar dessa brister med hjälp av SPF och DKIM för att bekräfta att domänerna i MAIL FROM- och From-adresserna matchar.

    DMARC-problem: Legitima tjänster som ändrar meddelanden under överföring före leverans bryter SPF, DKIM och därför DMARC-kontroller.

  • ARC: Som beskrivs i Konfigurera betrodda ARC-förseglare kan legitima tjänster som ändrar meddelanden under överföring använda ARC för att bevara den ursprungliga e-postautentiseringsinformationen för ändrade meddelanden.

    Så här hjälper ARC DMARC: Mål-e-postsystemet kan identifiera tjänsten som en betrodd ARC-förseglare. ARC kan sedan använda den bevarade e-postautentiseringsinformationen för att verifiera meddelandet.

Inkommande e-postautentisering för e-post som skickas till Microsoft 365

På grund av nätfiskeproblem och mindre än fullständigt införande av starka e-postautentiseringsprinciper av e-postavsändare på Internet använder Microsoft 365 implicit e-postautentisering för att kontrollera inkommande e-post. Implicit e-postautentisering utökar vanliga SPF-, DKIM- och DMARC-kontroller med hjälp av signaler från andra källor för att utvärdera inkommande e-post. Dessa källor omfattar:

  • Avsändarens rykte.
  • Avsändarhistorik.
  • Mottagarhistorik.
  • Beteendeanalys.
  • Andra avancerade tekniker.

Information om Microsofts ursprungliga meddelande om implicit autentisering finns i A Sea of Phish Part 2 – Enhanced Anti-spoofing in Microsoft 365 ( A Sea of Phish Part 2 – Enhanced Anti-spoofing in Microsoft 365).

Genom att använda dessa andra signaler kan meddelanden som annars skulle misslyckas med traditionella e-postautentiseringskontroller skicka implicit autentisering och tillåtas till Microsoft 365.

Sammansatt autentisering

Resultatet av Microsoft 365:s implicita autentiseringskontroller kombineras och lagras i ett enda värde med namnet sammansatt autentisering eller compauth för kort. compauth värdet stämplas i verifierings resultat rubriken i meddelande rubrikerna. Rubriken Authentication-Results använder följande syntax:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Dessa värden förklaras i Meddelanderubriken Authentication-results.

Administratörer och användare kan undersöka meddelandehuvudena för att se hur Microsoft 365 identifierade avsändaren som en misstänkt falsk avsändare eller legitim.

Tips

Det är viktigt att förstå att ett sammansatt autentiseringsfel inte direkt resulterar i att ett meddelande blockeras. Vårt system använder en holistisk utvärderingsstrategi som tar hänsyn till den övergripande misstänkta karaktären hos ett meddelande tillsammans med sammansatta autentiseringsresultat. Den här metoden är utformad för att minska risken för att legitim e-post blockeras felaktigt från domäner som kanske inte strikt följer protokoll för e-postautentisering. Den här balanserade metoden hjälper till att skilja verkligt skadlig e-post från meddelandeavsändare som helt enkelt inte uppfyller standardmetoderna för e-postautentisering.

Följande exempel fokuserar på resultatet av endast e-postautentisering ( compauth värdet och orsaken). Andra Microsoft 365-skyddstekniker kan identifiera meddelanden som skickar e-postautentisering som falska eller identifiera meddelanden som misslyckas med e-postautentisering som legitima.

  • Scenario: Domänen i SPF-posten eller DKIM-signaturen matchar inte domänen i Från-adressen.

  • Resultat: Meddelandet kan misslyckas med sammansatt autentisering. Trots det sammansatta autentiseringsfelet kan meddelandet fortfarande tillåtas om andra utvärderingar inte indikerar en misstänkt natur:

    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

  • Scenario: Den fabrikam.com domänen har inga SPF-, DKIM- eller DMARC-poster.

  • Resultat: Meddelanden från avsändare i fabrikam.com domänen kan misslyckas med sammansatt autentisering:

    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

  • Scenario: Den fabrikam.com domänen har en SPF-post och ingen DKIM-post. Domänerna i MAIL FROM- och From-adresserna matchar.

  • Resultat: Meddelandet kan skicka sammansatt autentisering eftersom domänen som skickade SPF matchar 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

  • Scenario: Fabrikam.com domänen har en DKIM-post utan en SPF-post. Domänen som DKIM signerade meddelandet matchar domänen i Från-adressen.

  • Resultat: Meddelandet kan skicka sammansatt autentisering eftersom domänen i DKIM-signaturen matchar 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

  • Scenario: Domänen i SPF-posten eller DKIM-signaturen matchar inte domänen i Från-adressen.

  • Resultat: Meddelandet kan 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

Så här undviker du e-postautentiseringsfel när du skickar e-post till Microsoft 365

Tips

Microsoft 365-kunder kan använda följande metoder för att tillåta meddelanden från avsändare som identifieras som förfalsknings- eller autentiseringsfel:

  • Konfigurera SPF-, DKIM- och DMARC-poster för dina domäner: Använd konfigurationsinformationen som tillhandahålls av din domänregistrator eller DNS-värdtjänst. Det finns även företag från tredje part som är dedikerade till att konfigurera e-postautentiseringsposter.

    Många företag publicerar inte SPF-poster eftersom de inte känner till alla e-postkällor för meddelanden i sin domän.

    1. Börja med att publicera en SPF-post som innehåller alla e-postkällor som du känner till (särskilt var företagets trafik finns) och använd tvingande regelvärdet "soft fail" (~all). Till exempel:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Om du skapar den här SPF-posten behandlar Microsoft 365 inkommande e-post från företagets infrastruktur som autentiserad, men e-post från oidentifierade källor kan fortfarande markeras som förfalskning om den misslyckas med sammansatt autentisering. Det här beteendet är dock fortfarande en förbättring jämfört med alla e-postmeddelanden från avsändare i domänen som markeras som falska av Microsoft 365. Vanligtvis accepterar mål-e-postsystemet meddelanden från avsändare i domänen från oidentifierade källor när SPF har konfigurerats med en regel för tillämpning av mjuk växling vid fel.

    2. Identifiera och inkludera fler e-postkällor för dina meddelanden. Till exempel:

      • 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.).

      När du har identifierat alla e-postkällor för din domän kan du uppdatera SPF-posten så att den använder tvingande regelvärdet "hard fail" (-all).

    3. Konfigurera DKIM för att signera meddelanden digitalt.

    4. Konfigurera DMARC för att verifiera att domänerna i MAIL FROM- och From-adresserna matchar, för att ange vad du ska göra med meddelanden som inte klarar DMARC-kontroller (avvisa eller sätta i karantän) och identifiera reporting services för att övervaka DMARC-resultat.

    5. Om du använder massutskick för att skicka e-post åt dig kontrollerar du att domänen i Från-adressen matchar domänen som passerar SPF eller DMARC.

  • Du är värd för en domäns e-post eller tillhandahåller en värdinfrastruktur som kan skicka e-post:

    • Se till att dina kunder har dokumentation som förklarar hur du konfigurerar SPF för deras domäner.
    • Överväg att DKIM signerar utgående DKIM-e-post, även om kunden inte uttryckligen konfigurerar DKIM i sin domän (logga in med en standarddomän). Du kan även dubbelsignera e-postmeddelandet med DKIM-signaturer (med din företagsdomän och kundens domän om/när den är tillgänglig).

    Leverans till Microsoft är inte garanterad, även om du autentiserar e-post från din plattform. Men e-postautentisering säkerställer att Microsoft inte automatiskt skräppost från dina kunddomäner bara för att den inte autentiseras.