E-postgodkjenning i EOP
Tips
Visste du at du kan prøve funksjonene i Microsoft 365 Defender for Office 365 Plan 2 gratis? Bruk 90-dagers prøveversjonen av Defender for Office 365 i Microsoft 365 Defender-portalen for prøveversjoner. Finn ut mer om hvem som kan registrere seg og vilkår for prøveversjonen her.
Gjelder for
- Exchange Online Protection
- Microsoft Defender for Office 365 plan 1 og plan 2
- Microsoft 365 Defender
E-postgodkjenning (også kjent som e-postvalidering) er en gruppe standarder som prøver å stoppe forfalskning (e-postmeldinger fra forfalskede avsendere). I alle Microsoft 365-organisasjoner bruker EOP disse standardene til å bekrefte innkommende e-post:
E-postgodkjenning bekrefter at e-postmeldinger fra en avsender (for eksempel laura@contoso.com) er legitime og kommer fra forventede kilder for det e-postdomenet (for eksempel contoso.com.)
Resten av denne artikkelen forklarer hvordan disse teknologiene fungerer, og hvordan EOP bruker dem til å sjekke innkommende e-post.
Bruke e-postgodkjenning for å forhindre forfalskning
DMARC hindrer forfalskning ved å undersøke Fra-adressen i meldinger. Fra-adressen er avsenderens e-postadresse som brukere ser i e-postklienten. Mål-e-postorganisasjoner kan også bekrefte at e-postdomenet har passert SPF eller DKIM. Domenet er med andre ord godkjent, og derfor er ikke avsenderens e-postadresse forfalsket.
DNS-poster for SPF, DKIM og DMARC (samlet kalt policyer for e-postgodkjenning) er imidlertid valgfrie. Domener med sterke e-postgodkjenningspolicyer som microsoft.com og skype.com er beskyttet mot forfalskning. Men domener med svakere policyer for e-postgodkjenning, eller ingen policy i det hele tatt, er hovedmål for å bli forfalsket.
Mangel på sterke policyer for godkjenning av e-post er et stort problem. Organisasjoner forstår kanskje ikke hvordan e-postgodkjenning fungerer, men angripere forstår fullt ut og drar nytte av dem. På grunn av phishing-bekymringer og begrenset innføring av policyer for sterk godkjenning av e-post, bruker Microsoft implisitt e-postgodkjenning til å sjekke innkommende e-post.
Implisitt e-postgodkjenning er en utvidelse av vanlige policyer for e-postgodkjenning. Disse utvidelsene inkluderer: avsenderens omdømme, avsenderlogg, mottakerlogg, atferdsanalyse og andre avanserte teknikker. I mangel av andre signaler fra disse utvidelsene merkes meldinger som sendes fra domener som ikke bruker policyer for e-postgodkjenning, som forfalsker.
Hvis du vil se Microsofts generelle kunngjøring, kan du se A Sea of Phish Part 2 – Forbedret anti-spoofing i Microsoft 365.
Sammensatt godkjenning
Hvis et domene ikke har tradisjonelle SPF-, DKIM- og DMARC-poster, kommuniserer ikke disse postkontrollene nok informasjon om godkjenningsstatus. Derfor har Microsoft utviklet en algoritme for implisitt e-postgodkjenning. Denne algoritmen kombinerer flere signaler til én enkelt verdi som kalles sammensatt godkjenning, eller compauth
for kort. Verdien compauth
stemples i overskriften Godkjenningsresultater i meldingshodene.
Authentication-Results:
compauth=<fail | pass | softpass | none> reason=<yyy>
Disse verdiene forklares i meldingshodet for godkjenningsresultater.
Ved å undersøke meldingshodene kan administratorer eller til og med sluttbrukere bestemme hvordan Microsoft 365 fastslo at avsenderen er forfalsket.
Hvorfor e-postgodkjenning ikke alltid er nok til å stoppe forfalskning
Bruk bare e-postgodkjenningsposter til å avgjøre om en innkommende melding er forfalsket, har følgende begrensninger:
Det sendende domenet kan mangle de nødvendige DNS-postene, eller postene er feil konfigurert.
Kildedomenet har riktig konfigurert DNS-poster, men dette domenet samsvarer ikke med domenet i Fra-adressen. SPF og DKIM krever ikke at domenet skal brukes i Fra-adressen. Angripere eller legitime tjenester kan registrere et domene, konfigurere SPF og DKIM for domenet og bruke et helt annet domene i Fra-adressen. Meldinger fra avsendere i dette domenet sender SPF og DKIM.
Sammensatt godkjenning kan løse disse begrensningene ved å sende meldinger som ellers ville mislykket e-postgodkjenningskontroller.
For enkelhetshet konsentrerer eksemplene nedenfor seg om resultater av e-postgodkjenning. Andre bakintelligensfaktorer kan identifisere meldinger som sender e-postgodkjenning som forfalsket, eller meldinger som mislykkes med e-postgodkjenning som legitime.
Det fabrikam.com domenet har for eksempel ingen SPF-, DKIM- eller DMARC-poster. Meldinger fra avsendere i det fabrikam.com domenet kan mislykkes med sammensatt godkjenning (vær oppmerksom på compauth
verdien og årsaken):
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
Hvis fabrikam.com konfigurerer en SPF uten en DKIM-post, kan meldingen sende sammensatt godkjenning. Domenet som besto SPF-kontroller, er justert etter 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
Hvis fabrikam.com konfigurerer en DKIM-post uten en SPF-post, kan meldingen sende sammensatt godkjenning. Domenet i DKIM-signaturen er justert 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
Hvis domenet i SPF eller DKIM-signaturen ikke samsvarer med domenet i Fra-adressen, kan meldingen 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
Løsninger for legitime avsendere som sender uautorisert e-post
Microsoft 365 holder oversikt over hvem som sender uautorisert e-post til organisasjonen. Hvis tjenesten mener at avsenderen ikke er legitim, vil den merke meldinger fra denne avsenderen som en sammensatt godkjenningsfeil. Hvis du vil unngå denne dommen, kan du bruke anbefalingene i denne delen.
Konfigurere e-postgodkjenning for domener du eier
Du kan bruke denne metoden til å løse forfalskning på tvers av organisasjoner og forfalsking på tvers av domener i tilfeller der du eier eller samhandler med flere leiere. Det bidrar også til å løse forfalskning på tvers av domener der du sender til andre kunder i Microsoft 365 eller tredjeparter som driftes av andre leverandører.
- Konfigurer SPF-poster for domenene.
- Konfigurer DKIM-poster for de primære domenene.
- Vurder å konfigurere DMARC-poster for domenet for å bestemme dine legitime avsendere.
Microsoft gir ikke detaljerte implementeringsretningslinjer for SPF-, DKIM- og DMARC-poster. Det er imidlertid mange opplysninger tilgjengelig på nettet. Det finnes også tredjepartsselskaper som er dedikerte til å hjelpe organisasjonen med å konfigurere poster for godkjenning av e-post.
Du kjenner ikke alle kilder for e-posten din
Mange domener publiserer ikke SPF-poster fordi de ikke kjenner alle e-postkildene for meldinger i domenet. Begynn med å publisere en SPF-post som inneholder alle e-postkildene du kjenner til (spesielt hvor bedriftens trafikk befinner seg), og publiser den nøytrale SPF-policyen ?all
. For eksempel,
fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ?all"
Dette eksemplet betyr at e-post fra bedriftens infrastruktur vil sende e-postgodkjenning, men e-post fra ukjente kilder vil falle tilbake til nøytral.
Microsoft 365 behandler innkommende e-post fra bedriftens infrastruktur som godkjent. E-post fra uidentifiserte kilder kan fremdeles være merket som forfalskning hvis den mislykkes implisitt godkjenning. Dette er imidlertid fortsatt en forbedring fra all e-post som merkes som forfalskning av Microsoft 365.
Når du har kommet i gang med en SPF-tilbakefallspolicy ?all
for , kan du gradvis oppdage og inkludere flere e-postkilder for meldingene dine, og deretter oppdatere SPF-posten med en strengere policy.
Konfigurere tillatte avsendere av uautorisert e-post
Du kan også bruke innsikten om falsk intelligens og leierens tillatelses-/blokkeringsliste til å tillate avsendere å overføre uautoriserte meldinger til organisasjonen.
For eksterne domener er den forfalskede brukeren domenet i Fra-adressen, mens infrastrukturen for sending er én av følgende verdier:
- KILDE-IP-adressen (delt opp i /24 CIDR-områder)
- Organisasjonsdomenet for den omvendte DNS-posten (PTR).
- Et bekreftet DKIM-domene.
Opprette en tillatelsesoppføring for avsender-/mottakerparet
Hvis du vil omgå filtrering av søppelpost, enkelte deler av filtreringen for phishing, men ikke filtrering av skadelig programvare for bestemte avsendere, kan du se Opprette lister over klarerte avsendere i Microsoft 365.
Be avsenderen om å konfigurere e-postgodkjenning for domener du ikke eier
På grunn av problemet med søppelpost og phishing anbefaler Microsoft e-postgodkjenning for alle e-postorganisasjoner. I stedet for å konfigurere manuelle overstyringer i organisasjonen, kan du be en administrator i avsenderdomenet om å konfigurere postene for e-postgodkjenning.
Selv om de ikke har behov for å publisere registreringer for e-postgodkjenning tidligere, bør de gjøre det hvis de sender e-post til Microsoft.
Konfigurer SPF til å publisere domenets sendende IP-adresser, og konfigurer DKIM (hvis tilgjengelig) til å signere meldinger digitalt. De bør også vurdere å konfigurere DMARC-poster.
Hvis de bruker masseavsendere til å sende e-post på deres vegne, må du kontrollere at domenet i Fra-adressen (hvis det tilhører dem) samsvarer med domenet som passerer SPF eller DMARC.
Kontroller at følgende plasseringer (hvis de bruker dem) er inkludert i SPF-posten:
- 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.).
Konfigurer SPF-posten for små domener som driftes av en Internett-adresse, i henhold til instruksjonene fra Internett-leverandøren.
Selv om det kan være vanskelig i begynnelsen å få tilsendt domener for å godkjenne, etter hvert som flere og flere e-postfiltre begynner å søppelpost eller til og med avvise e-posten, vil det føre til at de konfigurerer de riktige postene for å sikre bedre levering. Deltakelsen kan også hjelpe i kampen mot phishing, og de kan redusere muligheten for phishing i organisasjonen eller organisasjonen som de sender e-post til.
Informasjon for infrastrukturleverandører (Internett-leverandører, ESP-er eller skyvertstjenester)
Hvis du er vert for et domenes e-post eller leverer vertsinfrastruktur som kan sende e-post, bør du gjøre følgende:
Sørg for at kundene har dokumentasjon som forklarer hvordan kundene skal konfigurere SPF-postene sine
Vurder å signere DKIM-signaturer på utgående e-post, selv om kunden ikke eksplisitt konfigurerer det (signer med et standarddomene). Du kan til og med dobbeltsignere e-postmeldingen med DKIM-signaturer (én gang med kundens domene hvis de har konfigurert den, og en gang til med firmaets DKIM-signatur)
Levering til Microsoft er ikke garantert selv om du godkjenner e-post som kommer fra plattformen din, men i det minste sikrer det at Microsoft ikke søppelpost e-posten din fordi den ikke er godkjent.
Beslektede koblinger
Hvis du vil ha mer informasjon om anbefalte fremgangsmåter for tjenesteleverandører, kan du se anbefalte fremgangsmåter for mobilmeldinger i M3AAWG for tjenesteleverandører.
Finn ut hvordan Office 365 bruker SPF og støtter DKIM-validering: