Mailgodkendelse i Microsoft 365

• Gælder for:

  ✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

Tip

Vidste du, at du kan prøve funktionerne i Microsoft Defender XDR til Office 365 Plan 2 gratis? Brug den 90-dages Defender for Office 365 prøveversion på Microsoft Defender portalen med prøveversionshubben. Få mere at vide om, hvem der kan tilmelde dig og prøvevilkår i Prøv Microsoft Defender for Office 365.

Som Microsoft 365-organisation med postkasser i Exchange Online eller en separat EOP-organisation (Exchange Online Protection) uden Exchange Online postkasser er det vigtigt at beskytte integriteten af mails fra afsendere i dine domæner. Modtagerne skal være sikre på, at meddelelser fra afsendere i dit domæne virkelig kommer fra afsendere i dit domæne.

Mailgodkendelse (også kendt som mailvalidering) er en gruppe standarder, der identificerer og forhindrer levering af mailmeddelelser fra forfalskede afsendere (også kendt som spoofing). Spoofed afsendere bruges ofte i business email compromise (BEC), phishing og andre mailangreb. Disse standarder omfatter:

• SPF (Sender Policy Framework): Angiver de kildemailservere, der er godkendt til at sende mail til domænet.
• DomainKeys Identificeret mail (DKIM): Bruger et domæne til digitalt at signere vigtige elementer i meddelelsen for at sikre, at meddelelsen ikke er blevet ændret under overførslen.
• Domænebaseret meddelelsesgodkendelse, -rapportering og -overensstemmelse (DMARC): Angiver handlingen for meddelelser, der ikke udfører SPF- eller DKIM-kontrol for afsendere i domænet, og angiver, hvor DMARC-resultaterne skal sendes (rapportering).
• Godkendt modtaget kæde (ARC): Bevarer oprindelige godkendelsesoplysninger via mail af kendte tjenester, der ændrer meddelelser under overførsel. Destinationsmailserveren kan bruge disse oplysninger til at godkende meddelelser, der ellers ville mislykkes DMARC.

Det er vigtigt at indse, at disse standarder er indbyrdes afhængige byggesten , der arbejder sammen for at give den bedst mulige mailbeskyttelse mod spoofing- og phishing-angreb. Alt andet end alle godkendelsesmetoderne til mail resulterer i beskyttelse under standarden.

Hvis du vil konfigurere mailgodkendelse for mails, der er sendt fra Microsoft 365-organisationer med postkasser i Exchange Online eller enkeltstående Exchange Online Protection -organisationer (EOP) uden Exchange Online postkasser, skal du se følgende artikler:

• Konfigurer SPF for at forhindre forfalskning
• Brug DKIM til at validere udgående mails, der sendes fra dit brugerdefinerede domæne
• Brug DMARC til at validere mail

Hvis du vil forhindre godkendelsesfejl i mail på grund af tjenester, der ændrer indgående mails, der sendes til din Microsoft 365-organisation, skal du se Konfigurer ARC-sealere, der er tillid til.

I resten af denne artikel forklares:

• Hvorfor skal internetmailen godkendes?
• Sådan arbejder SPF, DKIM og DMARC sammen om at godkende afsendere af mails
• Sådan bruger Microsoft mailgodkendelse til at kontrollere indgående mails, der er sendt til Microsoft 365
• Sådan undgår du mailgodkendelsesfejl ved afsendelse af mail til Microsoft 365

Tip

Som ledsager til denne artikel kan du se vores konfigurationsvejledning til Microsoft Defender for Office 365 for at gennemse bedste praksis og for at beskytte mod mail-, link- og samarbejdstrusler. Funktionerne omfatter Sikre links, Vedhæftede filer og meget mere. Hvis du vil have en tilpasset oplevelse baseret på dit miljø, kan du få adgang til Microsoft Defender for Office 365 automatiserede konfigurationsvejledning i Microsoft 365 Administration.

Hvorfor skal internetmailen godkendes?

Smtp-mail (Simple Mail Transfer Protocol) på internettet gør som design ikke noget for at validere, at meddelelsens afsender er den, de hævder at være.

En standard-SMTP-mail består af en meddelelseskonvolut og meddelelsesindhold:

• Meddelelseskonvolutten indeholder oplysninger om afsendelse og modtagelse af meddelelsen mellem SMTP-servere. Meddelelseskonvolutten er beskrevet i RFC 5321. Modtagerne kan aldrig se meddelelseskonvolutten, fordi den genereres under meddelelsesoverførslen.
• Meddelelsesindholdet indeholder brevhovedfelter (samlet kaldet meddelelsesoverskriften) og meddelelsens brødtekst. Brevhovedet er beskrevet i RFC 5322.

På grund af dette design har en meddelelse flere afsenderværdier:

• MAIL FROM-adressen (også kendt som 5321.MailFrom adresse, P1-afsender eller konvolut afsender) er den mailadresse, der bruges til overførsel af meddelelsen mellem SMTP-mailservere. Denne adresse registreres typisk i overskriftsfeltet Return-Path i meddelelsesoverskriften (selvom kildemailserveren kan angive en anden mailadresse til returstien ). Denne mailadresse bruges i rapporter om manglende levering (også kendt som NDR'er eller meddelelser om manglende levering).
• Fra-adressen (også kendt som 5322.From adressen eller P2-afsenderen) er mailadressen i headerfeltet Fra og er afsenderens mailadresse, der vises i mailklienter.

I følgende eksempel vises den forenklede transskription af en gyldig meddelelsesoverførsel mellem to SMTP-mailservere:

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 dette eksempel:

• Kildemailserveren identificerer sig selv som woodgrovebank.com til destinationsmailserveren tailspintoys.com i HELO-kommandoen.
• Modtageren af meddelelsen er astobes@tailspintoys.com.
• MAIL FROM-adressen i meddelelseskonvolutten (bruges til at sende meddelelsen mellem SMTP-mailservere) er dubious@proseware.com.
• Fra-adressen, der vises i modtagerens mailklient, er security@woodgrovebank.com.

Selvom denne meddelelse er gyldig i henhold til SMTP, stemmer domænet for MAIL FROM-adressen (proseware.com) ikke overens med domænet i fra-adressen (woodgrovebank.com). Denne meddelelse er et klassisk eksempel på spoofing, hvor hensigten sandsynligvis vil bedrage modtageren ved at maskere den sande kilde til meddelelsen til brug i et phishing-angreb.

DET er klart, at SMTP-mail skal have hjælp til at bekræfte, at afsendere af meddelelser er dem, de hævder at være!

Sådan arbejder SPF, DKIM og DMARC sammen om at godkende afsendere af mails

I dette afsnit beskrives, hvorfor du har brug for SPF, DKIM og DMARC til domæner på internettet.

• SPF: Som forklaret i Konfigurer SPF til at identificere gyldige mailkilder for dit Microsoft 365-domæne, bruger SPF en TXT-post i DNS til at identificere gyldige mailkilder fra domænet MAIL FRA, og hvad du skal gøre, hvis destinationsmailserveren modtager mail fra en udefineret kilde ("mislykket" at afvise meddelelsen. "blød mislykket" til at acceptere og markere meddelelsen).

  SPF-problemer:

  • SPF validerer kun kilder for afsendere i domænet MAIL FROM. SPF tager ikke domænet i fra-adressen eller justeringen mellem domænerne MAIL FROM og From i betragtning:

    • En hacker kan sende mail, der består SPF-godkendelse (falsk negativ) ved at følge disse trin:
      • Registrer et domæne (f.eks. proseware.com), og konfigurer SPF for domænet.
      • Send mail fra en gyldig kilde for det registrerede domæne med mailadresserne Fra i et andet domæne (f.eks. woodgrovebank.com).
    • En legitim mailtjeneste, der sender mail på vegne af andre domæner, kan styre MAIL FROM-adressen. De andre domæner og domænet MAIL FROM stemmer ikke overens, så meddelelserne kan ikke bestå SPF-godkendelse (et falsk positivt).

  • SPF pauser, når meddelelser støder på serverbaseret videresendelse af mail, der omdirigerer eller videresender meddelelser.

    • Serverbaseret videresendelse af mail ændrer meddelelseskilden fra den oprindelige server til videresendelsesserveren.
    • Videresendelsesserveren har ikke tilladelse til at sende mail fra det oprindelige MAIL FROM-domæne, så meddelelsen kan ikke bestå SPF-godkendelse (falsk positiv).

  • Hvert domæne og eventuelle underdomæner kræver deres egne individuelle SPF-poster. Underdomæner nedarver ikke SPF-posten for det overordnede domæne. Denne funktionsmåde bliver problematisk, hvis du vil tillade mail fra definerede og brugte underdomæner, men forhindre, at mails ikke er defineret og ubrugte underdomæner.

• DKIM: Som forklaret i Konfigurer DKIM til at signere mails fra dit Microsoft 365-domæne, bruger DKIM et domæne til digitalt at signere vigtige elementer i meddelelsen (herunder Fra-adressen) og gemmer signaturen i meddelelsens header. Destinationsserveren kontrollerer, at de signerede elementer i meddelelsen ikke blev ændret.

  Sådan hjælper DKIM SPF: DKIM kan validere meddelelser, der mislykkes SPF. Det kan f.eks. være:

  • Meddelelser fra en mailværtstjeneste, hvor den samme MAIL FROM-adresse bruges til mail fra andre domæner.
  • Meddelelser, der støder på serverbaseret videresendelse af mail.

  Da DKIM-signaturen i meddelelsesheaderen ikke påvirkes eller ændres i disse scenarier, kan disse meddelelser bestå DKIM.

  DKIM-problemer: Det domæne, som DKIM bruger til at signere en meddelelse, behøver ikke at matche domænet i den Fra-adresse, der vises i mailklienter.

  På samme måde som SPF kan en hacker sende en mail, der består DKIM-godkendelse (falsk negativ) ved at følge disse trin:

  • Registrer et domæne (f.eks. proseware.com), og konfigurer DKIM for domænet.
  • Send mail med mailadresserne Fra i et andet domæne (f.eks. woodgrovebank.com).

• DMARC: Som forklaret i Konfigurer DMARC til at validere domænet From-adresse for afsendere i Microsoft 365 bruger DMARC SPF og DKIM til at kontrollere, om domænerne er justeret i MAIL FROM- og From-adresserne. DMARC angiver også den handling, som destinationens mailsystem skal udføre på meddelelser, der mislykkes DMARC, og identificerer, hvor DMARC-resultater skal sendes (både bestå og mislykkes).

  Sådan hjælper DMARC SPF og DKIM: Som tidligere beskrevet forsøger SPF ikke at matche domænet i MAIL FROM-domænet og Fra-adresserne. DKIM er ligeglad med, om det domæne, der har signeret meddelelsen, stemmer overens med domænet i Fra-adressen.

  DMARC afhjælper disse mangler ved at bruge SPF og DKIM til at bekræfte, at domænerne i MAIL FROM- og From-adresserne stemmer overens.

  DMARC spørgsmål: Legitime tjenester, der ændrer meddelelser i transit før levering pause SPF, DKIM, og derfor DMARC kontrol.

• ARC: Som forklaret i Konfigurer ARC-besegling, der er tillid til, kan legitime tjenester, der ændrer meddelelser under overførsel, bruge ARC til at bevare de oprindelige e-mail-godkendelsesoplysninger for ændrede meddelelser.

  Sådan hjælper ARC DMARC: Destinationsmailsystemet kan identificere tjenesten som en ARC-sealer, der er tillid til. ARC kan derefter bruge de bevarede godkendelsesoplysninger for mail til at validere meddelelsen.

Godkendelse af indgående mail for mails, der er sendt til Microsoft 365

På grund af phishing-bekymringer og mindre end fuldstændig indførelse af stærke politikker til godkendelse af mail af mail-afsendere på internettet, bruger Microsoft 365 implicit mailgodkendelse til at kontrollere indgående mail. Implicit mailgodkendelse udvider almindelige SPF-, DKIM- og DMARC-kontroller ved hjælp af signaler fra andre kilder til at evaluere indgående mail. Disse kilder omfatter:

• Afsenderens omdømme.
• Afsenderhistorik.
• Modtagerhistorik.
• Adfærdsanalyse.
• Andre avancerede teknikker.

Hvis du vil se Microsofts oprindelige meddelelse om implicit godkendelse, skal du se Et hav af Phish Part 2 – Enhanced Anti-spoofing i Microsoft 365.

Ved at bruge disse andre signaler kan meddelelser, der ellers mislykkes traditionelle kontrol af mailgodkendelse, overføre implicit godkendelse og tillades i Microsoft 365.

Sammensat godkendelse

Resultaterne af Microsoft 365s implicitte godkendelseskontrol kombineres og gemmes i en enkelt værdi med navnet sammensat godkendelse eller compauth kort sagt. Værdien compauth stemples i headeren Authentication-Results i brevhovederne. Headeren Godkendelsesresultater bruger følgende syntaks:

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

Disse værdier er forklaret i meddelelsens overskrift med godkendelsesresultater.

Administratorer og brugere kan undersøge brevhovederne for at finde ud af, hvordan Microsoft 365 identificerede afsenderen som en mistænkelig misvisende afsender eller legitim.

Tip

Det er vigtigt at forstå, at en sammensat godkendelsesfejl ikke direkte medfører, at en meddelelse blokeres. Vores system ved hjælp af en holistisk evalueringsstrategi, der tager den overordnede mistænkelige karakter af en meddelelse sammen med sammensatte godkendelsesresultater i betragtning. Denne metode er designet til at afhjælpe risikoen for fejlagtigt at blokere legitime mails fra domæner, der muligvis ikke strengt overholder protokoller til mailgodkendelse. Denne balancerede tilgang hjælper med at skelne virkelig ondsindede mails fra afsendere af meddelelser, der ganske enkelt ikke overholder standardpraksis for godkendelse af mail.

I følgende eksempler fokuseres der kun på resultaterne af mailgodkendelse ( compauth værdien og årsagen). Andre beskyttelsesteknologier i Microsoft 365 kan identificere meddelelser, der sender mailgodkendelse som spoofed, eller identificere meddelelser, der mislykkes med mailgodkendelse, som legitime.

• Scenarie: Domænet i SPF-posten eller DKIM-signaturen stemmer ikke overens med domænet i adressen Fra.

• Resultat: Meddelelsen kan mislykkes med sammensat godkendelse. På trods af den sammensatte godkendelsesfejl kan meddelelsen stadig være tilladt, hvis andre vurderinger ikke angiver en mistænkelig karakter:

  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
  

• Scenarie: Det fabrikam.com domæne har ingen SPF-, DKIM- eller DMARC-poster.

• Resultat: Meddelelser fra afsendere i det fabrikam.com domæne kan mislykkes med sammensat godkendelse:

  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
  

• Scenarie: Domænet fabrikam.com har en SPF-post og ingen DKIM-post. Domænerne i MAIL FROM- og From-adresserne stemmer overens.

• Resultat: Meddelelsen kan bestå sammensat godkendelse, fordi det domæne, der overførte SPF, svarer til domænet i fra-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
  

• Scenarie: Domænet fabrikam.com har en DKIM-post uden en SPF-post. Det domæne, som DKIM signerede meddelelsen for, stemmer overens med domænet i Fra-adressen.

• Resultat: Meddelelsen kan bestå sammensat godkendelse, fordi domænet i DKIM-signaturen stemmer overens med domænet i fra-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
  

• Scenarie: Domænet i SPF-posten eller DKIM-signaturen stemmer ikke overens med domænet i adressen Fra.

• Resultat: Meddelelsen kan mislykkes med sammensat godkendelse:

  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ådan undgår du mailgodkendelsesfejl ved afsendelse af mail til Microsoft 365

Tip

Microsoft 365-kunder kan bruge følgende metoder til at tillade meddelelser fra afsendere, der er identificeret som spoofing- eller godkendelsesfejl:

• Spoof intelligence-indsigt.
• Tillad poster for spoofede afsendere på listen over tilladte/blokerede lejere.
• Lister over afsendere, der er tillid til

• Konfigurer SPF-, DKIM- og DMARC-poster for dine domæner: Brug de konfigurationsoplysninger, der leveres af din domæneregistrator eller DNS-hostingtjeneste. Der er også tredjepartsfirmaer, der er dedikeret til at hjælpe med at konfigurere godkendelsesposter via mail.

  Mange firmaer publicerer ikke SPF-poster, fordi de ikke kender alle mailkilderne til meddelelser i deres domæne.

  1. Start med at publicere en SPF-post, der indeholder alle de mailkilder, du kender til (især hvor din virksomhedstrafik er placeret), og brug værdien "soft fail" (~all). Det kan f.eks. være:

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

     Hvis du opretter denne SPF-post, behandler Microsoft 365 indgående mails fra din virksomheds infrastruktur som godkendt, men mail fra uidentificerede kilder kan stadig markeres som spoof, hvis det ikke lykkes at godkende sammensat godkendelse. Denne funktionsmåde er dog stadig en forbedring i forhold til alle mails fra afsendere i domænet, der markeres som spoof af Microsoft 365. Destinationsmailsystemet accepterer typisk meddelelser fra afsendere i domænet fra uidentificerede kilder, når SPF er konfigureret med en regel for blød mislykket håndhævelse.

  2. Find og medtag flere mailkilder til dine meddelelser. Det kan f.eks. være:

     • Mailservere i det lokale miljø.
     • Mail sendt fra en SaaS-udbyder (software-as-a-service).
     • Mail sendt fra en cloudhostingtjeneste (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services osv.).

     Når du har identificeret alle mailkilder for dit domæne, kan du opdatere din SPF-post, så den bruger værdien "hard fail" (-all) for håndhævelsesreglen.

  3. Konfigurer DKIM til digitalt at signere meddelelser.

  4. Konfigurer DMARC for at validere, at domænerne i MAIL FROM- og From-adresserne stemmer overens, for at angive, hvad der skal gøres med meddelelser, der ikke udfører DMARC-kontroller (afvis eller sæt dem i karantæne), og for at identificere reporting services til overvågning af DMARC-resultater.

  5. Hvis du bruger masseafsendere til at sende mail på dine vegne, skal du kontrollere, at domænet i adressen Fra stemmer overens med det domæne, der passerer SPF eller DMARC.

• Du hoster et domænes mail eller leverer hostinginfrastruktur, der kan sende mail:

  • Sørg for, at dine kunder har dokumentation, der forklarer, hvordan de konfigurerer SPF for deres domæner.
  • Overvej AT SIGNERE DKIM-udgående mail, også selvom kunden ikke eksplicit konfigurerer DKIM på sit domæne (signer med et standarddomæne). Du kan endda dobbelttegne mailen med DKIM-signaturer (med dit virksomhedsdomæne og kundens domæne, hvis/når det er tilgængeligt).

  Levering til Microsoft garanteres ikke, selvom du godkender mails, der stammer fra din platform. Men godkendelse af mail sikrer, at Microsoft ikke automatisk uønsket mail fra dine kundedomæner, blot fordi den ikke er godkendt.