Del via

E-postgodkjenning i Microsoft 365

Tips

Visste du at du kan prøve funksjonene i Microsoft Defender XDR for Office 365 Plan 2 gratis? Bruk den 90-dagers prøveversjonen av Defender for Office 365 på Microsoft Defender portalens prøvehub. Lær om hvem som kan registrere deg og prøveabonnementer på Prøv Microsoft Defender for Office 365.

Som en Microsoft 365-organisasjon med postbokser i Exchange Online, eller en frittstående Exchange Online Protection (EOP)-organisasjon uten Exchange Online postbokser, er det viktig å beskytte integriteten til e-postmeldinger fra avsendere i domenene dine. Mottakerne skal føle seg trygge på at meldinger fra avsendere i domenet virkelig kom fra avsendere i domenet ditt.

E-postgodkjenning (også kjent som e-postvalidering) er en gruppe standarder for å identifisere og forhindre levering av e-postmeldinger fra forfalskede avsendere (også kjent som forfalskning). Falske avsendere brukes vanligvis i forretnings-e-postkompromisser (BEC), phishing og andre e-postangrep. Disse standardene inkluderer:

  • Struktur for avsenderpolicy (SPF): Angir kilde-e-postservere som er autorisert til å sende e-post for domenet.
  • DomainKeys Identified Mail (DKIM): Bruker et domene til å signere viktige elementer i meldingen digitalt for å sikre at meldingen ikke er endret under overføring.
  • Domenebasert meldingsgodkjenning, rapportering og samsvar (DMARC): Angir handlingen for meldinger som mislykkes SPF- eller DKIM-kontroller for avsendere i domenet, og angir hvor DMARC-resultatene skal sendes (rapportering).
  • Godkjent mottatt kjede (ARC): Bevarer opprinnelig informasjon om e-postgodkjenning av kjente tjenester som endrer meldinger under overføring. Mål-e-postserveren kan bruke denne informasjonen til å godkjenne meldinger som ellers ville sviktet DMARC.

Det er viktig å innse at disse standardene er gjensidig avhengige byggeblokker som arbeider sammen for å gi best mulig e-postbeskyttelse mot forfalskning og phishing-angrep. Noe mindre enn alle godkjenningsmetodene for e-post resulterer i substandard beskyttelse.

Hvis du vil konfigurere e-postgodkjenning for e-post sendt fra Microsoft 365-organisasjoner med postbokser i Exchange Online eller frittstående Exchange Online Protection (EOP)-organisasjoner uten Exchange Online postbokser, kan du se følgende artikler:

Hvis du vil forhindre feil med e-postgodkjenning på grunn av tjenester som endrer inngående e-post som sendes til Microsoft 365-organisasjonen, kan du se Konfigurere klarerte ARC-tetninger.

Resten av denne artikkelen forklarer:

Tips

Som en følge av denne artikkelen kan du se vår Microsoft Defender for Office 365 konfigurasjonsveiledning for å gjennomgå anbefalte fremgangsmåter og beskytte mot trusler om e-post, kobling og samarbeid. Funksjonene omfatter klarerte koblinger, klarerte vedlegg og mer. Hvis du vil ha en tilpasset opplevelse basert på miljøet ditt, kan du få tilgang til Microsoft Defender for Office 365 automatiserte konfigurasjonsveiledningen i Administrasjonssenter for Microsoft 365.

Hvorfor Internett-e-post trenger godkjenning

Enkel e-postoverføringsprotokoll (SMTP) på Internett gjør ingen forsøk på å validere at avsenderen av meldingen er den de hevder å være.

En standard SMTP-e-postmelding består av en meldingskonvolutt og meldingsinnhold:

  • Meldingskonvolutten inneholder informasjon om hvordan du sender og mottar meldingen mellom SMTP-servere. Meldingskonvolutten er beskrevet i RFC 5321. Mottakerne ser aldri meldingskonvolutten fordi den genereres under overføringsprosessen for meldinger.
  • Meldingsinnholdet inneholder meldingshodefelt (samlet kalt meldingshodet) og meldingsteksten. Meldingshodet er beskrevet i RFC 5322.

På grunn av denne utformingen har en melding flere avsenderverdier:

  • MAIL FROM-adressen (også kjent som 5321.MailFrom adressen, P1-avsenderen eller konvoluttavsenderen) er e-postadressen som brukes i overføringen av meldingen mellom SMTP-e-postservere. Denne adressen registreres vanligvis i returbanehodefeltet i meldingshodet (selv om kilde-e-postserveren kan angi en annen e-postadresse for returbane ). Denne e-postadressen brukes i rapporter om manglende levering (også kjent som NDR-er eller returmeldinger).
  • Fra-adressen (også kjent som 5322.From adressen eller P2-avsenderen) er e-postadressen i Fra-topptekstfeltet, og er avsenderens e-postadresse som vises i e-postklienter.

Følgende eksempel viser forenklet utskrift av en gyldig meldingsoverføring mellom to SMTP-e-postservere:

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 eksemplet:

  • Kilde-e-postserveren identifiserer seg som woodgrovebank.com til mål-e-postserveren tailspintoys.com i HELO-kommandoen.
  • Meldingsmottakeren er astobes@tailspintoys.com.
  • MAIL FROM-adressen i meldingskonvolutten (brukes til å overføre meldingen mellom SMTP-e-postservere) er dubious@proseware.com.
  • Fra-adressen som vises i mottakerens e-postklient, er security@woodgrovebank.com.

Selv om denne meldingen er gyldig i henhold til SMTP, samsvarer ikke domenet til MAIL FROM-adressen (proseware.com) med domenet i Fra-adressen (woodgrovebank.com). Denne meldingen er et klassisk eksempel på forfalskning, der hensikten sannsynligvis vil lure mottakeren ved å maskere den sanne kilden til meldingen som skal brukes i et phishing-angrep.

Det er klart at SMTP-e-post trenger hjelp til å bekrefte at avsendere av meldinger er den de hevder å være!

Slik fungerer SPF, DKIM og DMARC sammen for å godkjenne avsendere av e-postmeldinger

Denne delen beskriver hvorfor du trenger SPF, DKIM og DMARC for domener på Internett.

  • SPF: Som forklart i Konfigurer SPF for å identifisere gyldige e-postkilder for Microsoft 365-domenet, bruker SPF en TXT-post i DNS til å identifisere gyldige e-postkilder fra MAIL FROM-domenet, og hva du må gjøre hvis mål-e-postserveren mottar e-post fra en udefinert kilde (det er vanskelig å avvise meldingen; «Myk feil» for å godta og merke meldingen).

    SPF-problemer:

    • SPF validerer bare kilder for avsendere i E-POST FRA-domenet. SPF vurderer ikke domenet i Fra-adressen eller justeringen mellom E-POST FRA- og Fra-domenene:

      • En angriper kan sende e-post som passerer SPF-godkjenning (en falsk negativ) ved å følge disse trinnene:
        • Registrer et domene (for eksempel proseware.com) og konfigurer SPF for domenet.
        • Send e-post fra en gyldig kilde for det registrerte domenet, med Fra-e-postadressene i et annet domene (for eksempel woodgrovebank.com).
      • En legitim e-posttjeneste som sender e-post på vegne av andre domener, kan kontrollere E-POST FRA-adressen. De andre domenene og E-POST FRA-domenet samsvarer ikke, så meldingene kan ikke sende SPF-godkjenning (en falsk positiv).

    • SPF bryter etter at meldinger støter på serverbasert videresending av e-post som omdirigerer eller videresender meldinger.

      • Serverbasert videresending av e-post endrer meldingskilden fra den opprinnelige serveren til videresendingsserveren.
      • Videresendingsserveren har ikke tillatelse til å sende e-post fra det opprinnelige MAIL FROM-domenet, så meldingen kan ikke sende SPF-godkjenning (en falsk positiv).

    • Hvert domene og eventuelle underdomener krever sine egne individuelle SPF-poster. Underdomener arver ikke SPF-posten for det overordnede domenet. Denne virkemåten blir problematisk hvis du vil tillate e-post fra definerte og brukte underdomener, men hindre e-post fra udefinerte og ubrukte underdomener.

  • DKIM: Som forklart i Konfigurer DKIM til å signere e-post fra Microsoft 365-domenet, bruker DKIM et domene til å signere viktige elementer i meldingen digitalt (inkludert Fra-adressen) og lagre signaturen i meldingshodet. Målserveren bekrefter at de signerte elementene i meldingen ikke ble endret.

    Hvordan DKIM hjelper SPF: DKIM kan validere meldinger som mislykkes SPF. Eksempel:

    • Meldinger fra en e-postvertstjeneste der samme MAIL FROM-adresse brukes for e-post fra andre domener.
    • Meldinger som støter på serverbasert videresending av e-post.

    Siden DKIM-signaturen i meldingshodet ikke påvirkes eller endres i disse scenariene, kan disse meldingene sende DKIM.

    DKIM-problemer: Domenet som DKIM bruker til å signere en melding, trenger ikke å samsvare med domenet i Fra-adressen som vises i e-postklienter.

    I likhet med SPF kan en angriper sende e-post som består DKIM-godkjenning (en falsk negativ) ved å følge disse trinnene:

    • Registrer et domene (for eksempel proseware.com) og konfigurer DKIM for domenet.
    • Send e-post med Fra-e-postadressene i et annet domene (for eksempel woodgrovebank.com).

  • DMARC: Som forklart i Konfigurer DMARC for å validere Fra-adressedomenet for avsendere i Microsoft 365, bruker DMARC SPF og DKIM til å se etter justering mellom domenene i E-POST FRA- og Fra-adressene. DMARC angir også handlingen som mål-e-postsystemet skal utføre på meldinger som mislykkes DMARC, og identifiserer hvor du skal sende DMARC-resultater (både bestått og mislykket).

    Slik hjelper DMARC SPF og DKIM: Som beskrevet tidligere, gjør SPF ingen forsøk på å samsvare domenet i E-POST FRA-domenet og Fra-adresser. DKIM bryr seg ikke om domenet som signerte meldingen samsvarer med domenet i Fra-adressen.

    DMARC løser disse manglene ved å bruke SPF og DKIM til å bekrefte at domenene i E-POST FROM- og Fra-adressene samsvarer.

    DMARC-problemer: Legitime tjenester som endrer meldinger i transitt før leveringsbrudd SPF, DKIM, og derfor DMARC-kontroller.

  • ARC: Som forklart i Konfigurer klarerte ARC-sealers, kan legitime tjenester som endrer meldinger i transitt, bruke ARC til å bevare den opprinnelige e-postgodkjenningsinformasjonen for endrede meldinger.

    Slik hjelper ARC DMARC: Mål-e-postsystemet kan identifisere tjenesten som en klarert ARC-sealer. ARC kan deretter bruke den bevarte godkjenningsinformasjonen for e-post til å validere meldingen.

Innkommende e-postgodkjenning for e-post sendt til Microsoft 365

På grunn av phishing-bekymringer og mindre enn fullstendig innføring av policyer for sterk godkjenning av e-post fra e-postavsendere på Internett, bruker Microsoft 365 implisitt e-postgodkjenning til å sjekke innkommende e-post. Implisitt e-postgodkjenning utvider vanlige SPF-, DKIM- og DMARC-kontroller ved hjelp av signaler fra andre kilder for å evaluere innkommende e-post. Disse kildene omfatter:

  • Avsenderens omdømme.
  • Avsenderlogg.
  • Mottakerlogg.
  • Atferdsanalyse.
  • Andre avanserte teknikker.

Hvis du vil se Microsofts opprinnelige kunngjøring om implisitt godkjenning, kan du se A Sea of Phish Part 2 – Forbedret anti-spoofing i Microsoft 365.

Ved å bruke disse andre signalene kan meldinger som ellers ville mislykkes tradisjonelle e-postgodkjenningskontroller, passere implisitt godkjenning og tillates inn i Microsoft 365.

Sammensatt godkjenning

Resultatene av Microsoft 365s implisitte godkjenningskontroller kombineres og lagres i én enkelt verdi kalt sammensatt godkjenning eller compauth for kort. Verdien compauth stemples i overskriften Godkjenningsresultater i meldingshodene. Overskriften godkjenningsresultater bruker følgende syntaks:

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

Disse verdiene forklares i meldingshodet for godkjenningsresultater.

Administratorer og brukere kan undersøke meldingshodene for å finne ut hvordan Microsoft 365 identifiserte avsenderen som en mistenkelig forfalsket avsender eller legitim.

Tips

Det er viktig å forstå at en sammensatt godkjenningsfeil ikke direkte fører til at en melding blokkeres. Systemet vårt bruker en helhetlig evalueringsstrategi som vurderer den generelle mistenkelige karakteren til en melding sammen med sammensatte godkjenningsresultater. Denne metoden er utformet for å redusere risikoen for feil blokkering av ekte e-post fra domener som kanskje ikke følger godkjenningsprotokoller for e-post. Denne balanserte tilnærmingen bidrar til å skille ekte ondsinnet e-post fra meldingsavsendere som rett og slett ikke overholder standard praksis for e-postgodkjenning.

Eksemplene nedenfor fokuserer bare på resultatene av e-postgodkjenning ( compauth verdien og årsaken). Andre Microsoft 365-beskyttelsesteknologier kan identifisere meldinger som sender e-postgodkjenning som forfalsket, eller identifisere meldinger som mislykkes med e-postgodkjenning som legitime.

  • Scenario: Domenet i SPF-posten eller DKIM-signaturen samsvarer ikke med domenet i Fra-adressen.

  • Resultat: Meldingen kan mislykkes med sammensatt godkjenning. Til tross for den sammensatte godkjenningsfeilen, kan meldingen fortsatt være tillatt hvis andre vurderinger ikke indikerer mistenkelig 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

  • Scenario: Det fabrikam.com domenet har ingen SPF-, DKIM- eller DMARC-poster.

  • Resultat: Meldinger fra avsendere i det fabrikam.com domenet kan mislykkes med sammensatt godkjenning:

    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: Det fabrikam.com domenet har en SPF-post og ingen DKIM-post. Domenene i E-POST FRA- og Fra-adressene samsvarer.

  • Resultat: Meldingen kan sende sammensatt godkjenning fordi domenet som sendte SPF samsvarer med domenet 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

  • Scenario: Det fabrikam.com domenet har en DKIM-post uten en SPF-post. Domenet som DKIM signerte meldingen samsvarer med domenet i Fra-adressen.

  • Resultat: Meldingen kan sende sammensatt godkjenning fordi domenet i DKIM-signaturen samsvarer med domenet 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

  • Scenario: Domenet i SPF-posten eller DKIM-signaturen samsvarer ikke med domenet i Fra-adressen.

  • Resultat: Meldingen kan mislykkes med sammensatt godkjenning:

    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

Slik unngår du feil ved godkjenning av e-post når du sender e-post til Microsoft 365

Tips

Microsoft 365-kunder kan bruke følgende metoder for å tillate meldinger fra avsendere som er identifisert som forfalsknings- eller godkjenningsfeil:

  • Konfigurer SPF-, DKIM- og DMARC-poster for domenene: Bruk konfigurasjonsinformasjonen som leveres av domeneregistratoren eller DNS-vertstjenesten. Det finnes også tredjepartsselskaper som er dedikerte til å konfigurere poster for e-postgodkjenning.

    Mange firmaer publiserer ikke SPF-poster fordi de ikke kjenner alle e-postkildene for meldinger i domenet.

    1. Begynn med å publisere en SPF-post som inneholder alle e-postkilder du vet om (spesielt hvor bedriftens trafikk befinner seg), og bruk verdien for håndhevelsesregel «myk feil» (~all). Eksempel:

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

      Hvis du oppretter denne SPF-posten, behandler Microsoft 365 innkommende e-post fra bedriftens infrastruktur som godkjent, men e-post fra uidentifiserte kilder kan fremdeles være merket som forfalsning hvis den mislykkes med sammensatt godkjenning. Denne virkemåten er imidlertid fortsatt en forbedring fra all e-post fra avsendere i domenet som merkes som forfalskning av Microsoft 365. Mål-e-postsystemet godtar vanligvis meldinger fra avsendere i domenet fra uidentifiserte kilder når SPF er konfigurert med en myk regel for mislykket håndhevelse.

    2. Oppdag og inkluder flere e-postkilder for meldingene dine. Eksempel:

      • Lokale e-postservere.
      • E-post sendt fra en programvare-som-tjeneste (SaaS)-leverandør.
      • E-post sendt fra en skytjeneste (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services osv.).

      Når du har identifisert alle e-postkildene for domenet, kan du oppdatere SPF-posten til å bruke verdien for håndhevelsesregel «hard fail» (-all).

    3. Konfigurer DKIM til å signere meldinger digitalt.

    4. Konfigurer DMARC til å validere at domenene i E-POST FRA- og Fra-adresser samsvarer, for å angi hva du skal gjøre med meldinger som mislykkes DMARC-kontroller (forkast eller karantene), og for å identifisere rapporteringstjenester for å overvåke DMARC-resultater.

    5. Hvis du bruker masseavsendere til å sende e-post på dine vegne, må du kontrollere at domenet i Fra-adressen samsvarer med domenet som passerer SPF eller DMARC.

  • Du er vert for et domenes e-post eller leverer vertsinfrastruktur som kan sende e-post:

    • Sørg for at kundene har dokumentasjon som forklarer hvordan de konfigurerer SPF for domenene sine.
    • Vurder DKIM-signering av DKIM-utgående e-post, selv om kunden ikke eksplisitt konfigurerer DKIM i domenet sitt (signer med et standarddomene). Du kan til og med dobbeltsignere e-postmeldingen med DKIM-signaturer (med firmadomenet og kundens domene hvis/når det er tilgjengelig).

    Levering til Microsoft er ikke garantert, selv om du godkjenner e-post som kommer fra plattformen din. E-postgodkjenning sikrer imidlertid at Microsoft ikke automatisk søppelpost fra kundedomenene dine rett og slett fordi det ikke er godkjent.