Domenebasert meldingsgodkjenning, rapportering og samsvar (DMARC) er en metode for e-postgodkjenning som bidrar til å validere e-post sendt fra Microsoft 365-organisasjonen for å forhindre falske avsendere som brukes i e-postkompromisser for bedrifter (BEC), løsepengevirus og andre phishing-angrep.
Du aktiverer DMARC for et domene ved å opprette en TXT-post i DNS. DMARC-validering av en e-postmelding omfatter følgende elementer:
Kontroller at domenene i E-POST FRA- og FROM-adressene justeres: SPF og DKIM krever ikke at domenene i følgende e-postadresser justeres (samsvarer):
E-POST FRA-adressen: E-postadressen som brukes i overføringen av meldingen mellom SMTP-e-postservere. Denne adressen er også kjent som avsenderen 5321.MailFrom av adressen, P1-avsenderen eller konvolutten.
Fra-adressen: E-postadressen i Fra-topptekstfeltet som vises som avsenderen av meldingen i e-postklienter. Denne adressen kalles også 5322.From adressen eller P2-avsenderen.
Hvis du vil ha mer informasjon om hvordan disse e-postadressene kan være i forskjellige domener og brukes til forfalskning, kan du se Hvorfor Internett-e-post trenger godkjenning.
DMARC bruker resultatet fra SPF til å bekrefte begge disse betingelsene:
Meldingen kom fra en autorisert kilde for domenet som brukes i MAIL FROM-adressen (det grunnleggende kravet til SPF).
Domenene i E-POST FRA- og Fra-adressene i meldingen er justert. Dette resultatet krever effektivt at gyldige kilder for meldingen må være i Fra-adressedomenet.
DMARC bruker resultatet fra DKIM til å bekrefte domenet som signerte meldingen ( d= verdien i et DKIM-signaturhodefelt som validert av s= velgerverdien) justeres med domenet i Fra-adressen.
En melding sender DMARC hvis én eller begge av de beskrevne SPF- eller DKIM-kontrollene passerer. En melding mislykkes DMARC hvis begge de beskrevne SPF- eller DKIM-kontrollene mislykkes.
DMARC-policy: Angir hva du skal gjøre med meldinger som mislykkes DMARC (forkast, karantene eller ingen instruksjon).
DMARC-rapporter: Angir hvor aggregeringsrapporter skal sendes (et periodisk sammendrag av positive og negative DMARC-resultater) og rettsmedisinske rapporter (også kjent som feilrapporter, nesten umiddelbare DMARC-feilresultater som ligner på en rapport om manglende levering eller returmelding).
Før vi begynner, må du vite følgende om DMARC i Microsoft 365 basert på e-postdomenet ditt:
Hvis du bare bruker domenet Microsoft Online Email Routing Address (MOERA) for e-post (for eksempel contoso.onmicrosoft.com): Selv om SPF og DKIM allerede er konfigurert for *.onmicrosoft.com-domenet, må du opprette DMARC TXT-posten for domenet *.onmicrosoft.com i Administrasjonssenter for Microsoft 365. Hvis du vil ha instruksjoner, kan du se denne delen senere i denne artikkelen. Hvis du vil ha mer informasjon om *.onmicrosoft.com domener, kan du se Hvorfor har jeg et «onmicrosoft.com»-domene?.
Hvis du bruker ett eller flere egendefinerte domener for e-post (for eksempel contoso.com): Hvis du ikke allerede har gjort det, må du konfigurere SPF for alle egendefinerte domener og underdomener som du bruker til e-post. Du må også konfigurere DKIM-signering ved hjelp av det egendefinerte domenet eller underdomenet, slik at domenet som brukes til å signere meldingen, samsvarer med domenet i Fra-adressen. Hvis du vil ha instruksjoner, kan du se følgende artikler:
Deretter må du også konfigurere DMARC TXT-postene for de egendefinerte domenene som beskrevet i denne artikkelen. Du har også følgende vurderinger:
Underdomener:
For e-posttjenester som ikke er under din direkte kontroll (for eksempel massetjenester for e-post), anbefaler vi at du bruker et underdomene (for eksempel marketing.contoso.com) i stedet for hoved-e-postdomenet (for eksempel contoso.com). Du vil ikke at problemer med e-post som sendes fra disse e-posttjenestene, skal påvirke omdømmet til e-post som sendes av ansatte i hoved-e-postdomenet. Hvis du vil ha mer informasjon om hvordan du legger til underdomener, kan du se Kan jeg legge til egendefinerte underdomener eller flere domener i Microsoft 365?.
I motsetning til SPF og DKIM dekker DMARC TXT-posten for et domene automatisk alle underdomener (inkludert ikke-eksisterende underdomener) som ikke har sin egen DMARC TXT-post. Du kan med andre ord forstyrre arven til DMARC på et underdomene ved å opprette en DMARC TXT-post i dette underdomenet. Hvert underdomene krever imidlertid en SPF- og DKIM-post for DMARC.
Hvis du eier registrerte, men ubrukte domener: Hvis du eier registrerte domener som ikke brukes til e-post eller noe i det hele tatt (også kjent som parkerte domener), konfigurerer du DMARC TXT-postene i disse domenene for å angi at ingen e-post noensinne skal komme fra disse domenene.
Dette direktivet inneholder domenet *.onmicrosoft.com hvis du ikke bruker det til e-post.
DMARC-kontroller for innkommende e-post kan trenge hjelp: Hvis du bruker en e-posttjeneste som endrer meldinger i transitt før levering til Microsoft 365, kan du identifisere tjenesten som en klarert ARC-forsegling, slik at de endrede meldingene ikke automatisk mislykkes DMARC-kontroller. Hvis du vil ha mer informasjon, kan du se neste trinn-delen på slutten av denne artikkelen.
Resten av denne artikkelen beskriver DMARC TXT-posten du må opprette for domener i Microsoft 365, den beste måten å gradvis og trygt konfigurere DMARC for egendefinerte domener i Microsoft 365 på, og hvordan Microsoft 365 bruker DMARC på innkommende e-post .
Tips
Hvis du vil opprette DMARC TXT-posten for *.onmicrosoft.com-domenet i Administrasjonssenter for Microsoft 365, kan du se denne delen senere i denne artikkelen.
Det finnes ingen administrasjonsportaler eller PowerShell-cmdleter i Microsoft 365 som du kan bruke til å administrere DMARC TXT-poster i egendefinerte domener. I stedet oppretter du DMARC TXT-posten hos domeneregistratoren eller DNS-vertstjenesten (ofte samme firma).
Vi gir instruksjoner for å opprette bevis på TXT-posten for domeneeierskap for Microsoft 365 hos mange domeneregistratorer. Du kan bruke disse instruksjonene som utgangspunkt for å opprette DMARC TXT-poster. Hvis du vil ha mer informasjon, kan du se Legge til DNS-poster for å koble til domenet.
Hvis du ikke er kjent med DNS-konfigurasjonen, kontakter du domeneregistratoren og ber om hjelp.
Syntaks for TXT-poster for DMARC
DMARC TXT-poster er fullstendig beskrevet i RFC 7489.
Den grunnleggende syntaksen for DMARC TXT-posten for et domene i Microsoft 365 er:
Vertsnavn: _dmarc TXT-verdi: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>
v=DMARC1; identifiserer TXT-posten som en DMARC TXT-post.
DMARC-policy: Forteller mål-e-postsystemet hva de skal gjøre med meldinger som mislykkes DMARC som beskrevet tidligere i denne artikkelen:
p=reject: Meldingene skal avvises. Hva som faktisk skjer med meldingen, avhenger av mål-e-postsystemet, men meldingene forkastes vanligvis.
p=quarantine: Meldingene skal godtas, men merkes. Hva som faktisk skjer med meldingen, avhenger av mål-e-postsystemet. Meldingen kan for eksempel settes i karantene som søppelpost, leveres til Søppelpost-mappen eller leveres til innboksen med en identifikator lagt til i emneteksten eller meldingsteksten.
p=none: Ingen foreslått handling for meldinger som mislykkes DMARC. Hva som skjer med meldingen, avhenger av e-postbeskyttelsesfunksjonene i mål-e-postsystemet. Du bruker denne verdien til testing og justering av DMARC-policyen som beskrevet senere i denne artikkelen.
Tips
Utgående e-post fra domener i Microsoft 365 som mislykkes DMARC-kontroller av mål-e-posttjenesten, rutes gjennom leveringsutvalget med høy risiko for utgående meldinger hvis DMARC-policyen for domenet er p=reject eller p=quarantine. Det finnes ingen overstyring for denne virkemåten.
Prosentandel mislykket DMARC-e-post som er underlagt DMARC-policy: Forteller mål-e-postsystemet hvor mange meldinger som mislykkes DMARC (prosent) får DMARC-policyen brukt på dem. Betyr for eksempel pct=100 at alle meldinger som mislykkes DMARC får DMARC-policyen brukt på dem. Du bruker verdier som er mindre enn 100 for testing og justering av DMARC-policyen , som beskrevet senere i denne artikkelen. Hvis du ikke bruker pct=, er pct=100standardverdien .
DMARC-rapporter:
DMARC Aggregate Report URI: Verdien rua=mailto: identifiserer hvor DMARC-mengderapporten skal sendes. Mengderapporten har følgende egenskaper:
E-postmeldingene som inneholder mengderapporten, sendes vanligvis én gang per dag (rapporten inneholder DMARC-resultatene fra dagen før). Emnelinjen inneholder måldomenet som sendte rapporten (innsenderen) og kildedomenet for DMARC-resultatene (rapportdomenet).
DMARC-dataene er i et XML-e-postvedlegg som sannsynligvis er GZIP-komprimert. XML-skjemaet er definert i Tillegg C av RFC 7489. Rapporten inneholder følgende informasjon:
IP-adressene til servere eller tjenester som sender e-post ved hjelp av domenet ditt.
Om serverne eller tjenestene passerer eller mislykkes DMARC-godkjenning.
Handlingene som DMARC utfører på e-post som mislykkes DMARC-godkjenning (basert på DMARC-policyen).
Tips
Informasjonen i mengderapporten kan være stor og vanskelig å analysere. Du kan bruke følgende alternativer for DMARC-rapportering for å forstå dataene:
Opprett automatisering ved hjelp av PowerShell eller Microsoft Power BI.
Bruk en ekstern tjeneste. Hvis du vil ha en liste over tjenester, kan du søke etter DMARC i Katalogen for Microsoft Intelligent Security Association (MISA) på https://www.microsoft.com/misapartnercatalog. DMARC-rapporteringstjenester beskriver eventuelle egendefinerte verdier som kreves i DMARC TXT-posten.
DMARC Rettsmedisinsk rapport URI: Verdien ruf=mailto: identifiserer hvor du skal sende DMARC rettsmedisinske rapporten (også kjent som DMARC Failure report). Rapporten genereres og sendes umiddelbart etter en DMARC-feil som en rapport om manglende levering (også kjent som en NDR- eller returmelding).
Tips
Du bør jevnlig se gjennom DMARC-aggregatrapportene for å overvåke hvor e-post fra domenene kommer fra, og for å se etter utilsiktede DMARC-feil (falske positiver).
Individuelle mål-e-postsystemer er ansvarlige for å sende DMARC-rapporter tilbake til deg. Mengden og variasjonen av DMARC-rapporter varierer på samme måte som volumet og variasjonen av e-post som sendes fra organisasjonen, varierer. Du kan for eksempel forvente lavere e-postvolum i helligdager og høyere e-postvolum under organisasjonsarrangementer. Det er best å angi bestemte personer til å overvåke DMARC-rapporter og bruke en bestemt postboks eller Microsoft 365-gruppe til å motta DMARC-rapporter (ikke lever rapportene til en brukers postboks).
Hvis du vil ha mer informasjon om DMARC, kan du bruke følgende ressurser:
DMARC-opplæringsserien fra M3AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
Velg domenet *.onmicrosoft.com fra listen på Domener-siden ved å klikke hvor som helst i raden annet enn avmerkingsboksen ved siden av domenenavnet.
Velg DNS-poster-fanen på domenedetaljsiden som åpnes.
Velg Legg til post på DNS-poster-fanen.
Konfigurer følgende innstillinger på undermenyen Legg til en egendefinert DNS-post som åpnes:
Type: Kontroller at TXT (tekst) er valgt.
TXT-navn: Skriv inn _dmarc.
TXT-verdi: Enter v=DMARC1; p=reject.
Tips
Hvis du vil angi mål for DMARC-aggregat- og DMARC-rettsmedisinske rapporter, bruker du syntaksen v=DMARC1; p=reject rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. For eksempel v=DMARC1; p=reject rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.
Når du er ferdig med undermenyen Legg til en egendefinert DNS-post , velger du Lagre.
Konfigurere DMARC for aktive egendefinerte domener i Microsoft 365
Tips
Som nevnt tidligere i denne artikkelen, må du opprette SPF TXT-poster og konfigurere DKIM-signering for alle egendefinerte domener og underdomener som du bruker til å sende e-post i Microsoft 365 før du konfigurerer DMARC for egendefinerte domener eller underdomener.
Vi anbefaler en gradvis fremgangsmåte for å konfigurere DMARC for Microsoft 365-domenene dine. Målet er å få tilgang til en p=reject DMARC-policy for alle egendefinerte domener og underdomener, men du må teste og bekrefte underveis for å hindre at mål-e-postsystemer avviser god e-post på grunn av utilsiktede DMARC-feil.
DMARC-utrullingsplanen bør bruke følgende fremgangsmåte. Start med et domene eller underdomene med lavt e-postvolum og/eller færre potensielle e-postkilder (mindre sjanse for at ekte e-post fra ukjente kilder blokkeres):
Start med en DMARC-policy for p=none og overvåk resultatene for domenet. Eksempel:
DMARC-aggregat- og DMARC-rettsmedisinske rapporter gir tallene og kildene til meldinger som passerer og mislykker DMARC-kontroller. Du kan se hvor mye av den legitime e-posttrafikken som dekkes av DMARC, og feilsøke eventuelle problemer. Du kan også se hvor mange falske meldinger som sendes, og hvor de sendes fra.
Øk DMARC-policyen til og p=quarantine overvåk resultatene for domenet.
Etter nok tid til å overvåke effektene av p=none, kan du øke DMARC-policyen til p=quarantine for domenet. Eksempel:
Du kan også bruke pct= verdien til gradvis å påvirke flere meldinger og bekrefte resultatene.
Gjenta de tre foregående trinnene for de gjenværende underdomenene for å øke volum og/eller kompleksitet, og lagre det overordnede domenet til slutt.
Tips
Blokkering av legitim e-post i et betydelig volum er uakseptabelt for brukerne, men det er nesten uunngåelig at du kommer til å få noen falske positiver. Gå sakte og metodisk med problemer som vises i DMARC-rapportering. DMARC-rapporteringsleverandører i MISA-katalogen https://www.microsoft.com/misapartnercatalog gjør det enklere å vise og tolke DMARC-resultatene.
Som beskrevet tidligere arver underdomener DMARC TXT-postinnstillingene for det overordnede domenet, som kan overstyres av en separat DMARC TXT-post i underdomenet. Når du er ferdig med å konfigurere DMARC i et domene og alle underdomener, og DMARC-innstillingene er effektivt identiske for det overordnede domenet og alle underdomener, kan du eliminere DMARC TXT-postene i underdomenene og stole på den enkle DMARC TXT-posten i det overordnede domenet.
DMARC TXT-poster for parkerte domener i Microsoft 365
Hvis du har registrert domener som ingen på Internett skal forvente å motta e-post fra, oppretter du følgende DMARC TXT-post hos domeneregistratoren for domenet:
Vertsnavn: _dmarc TXT-verdi: v=DMARC1; p=reject;
Verdien pct= er ikke inkludert fordi standardverdien er pct=100.
ruf=mailto: Og rua=mailto: verdiene er uten tvil ikke nødvendig i dette scenarioet, fordi ingen gyldig e-post noensinne skal komme fra avsendere i domenet.
DMARC-kontroller av e-post som kommer inn i Microsoft 365, påvirkes av følgende funksjoner i Exchange Online Protection (EOP):
Om forfalskningsintelligens er aktivert eller deaktivert i policyen for anti-phishing som sjekket meldingen. Deaktivering av forfalskningsintelligens deaktiverer implisitt forfalskningsbeskyttelse bare fra sammensatte godkjenningskontroller .
Om postpolicyen Honor DMARC når meldingen oppdages som falsk innstilling er aktivert eller deaktivert i policyen for anti-phishing som sjekket meldingen, og de angitte handlingene basert på DMARC-policyen for kildedomenet (p=quarantineeller p=reject i DMARC TXT-posten).
Hvis du vil se standardverdiene for disse innstillingene i policyer for anti-phishing, kan du kontrollere innstillingsverdiene i tabellen ved innstillinger for anti-phishing-policy for EOP.
Microsoft 365 sender ikke DMARC-rettsmedisinske rapporter (også kjent som DMARC-feilrapporter), selv om det finnes en gyldig ruf=mailto: adresse i DMARC TXT-posten for kildedomenet.
Microsoft 365 sender DMARC-mengderapporter til alle domener med en gyldig rua=mailto: adresse i DMARC TXT-postene, så lenge MX-posten for Microsoft 365-domenet peker direkte til Microsoft 365.
Hvis e-post fra Internett rutes gjennom en tredjepartstjeneste eller enhet før levering til Microsoft 365 (MX-posten peker et annet sted enn Microsoft 365), sendes ikke DMARC-mengderapporter. Denne begrensningen inkluderer hybride eller frittstående EOP-scenarier der e-post leveres til det lokale miljøet før de rutes til Microsoft 365 ved hjelp av en kobling.
Tips
Når en tredjepartstjeneste eller enhet sitter foran e-post som flyter inn i Microsoft 365, identifiserer forbedret filtrering for koblinger (også kjent som hopp over oppføring) kilden til Internett-meldinger for SPF, DKIM (hvis tjenesten endrer meldinger) og DMARC-validering.
Feilsøking av DMARC
Du kan bruke følgende grafikk til å feilsøke problemer med DMARC-godkjenning.
Neste trinn
For e-post som kommer inn i Microsoft 365, må du kanskje også konfigurere klarerte ARC-sealers hvis du bruker tjenester som endrer meldinger i transitt før levering til organisasjonen. Hvis du vil ha mer informasjon, kan du se Konfigurere klarerte ARC-tetninger.
This module examines how Microsoft Defender for Office 365 extends EOP protection through various tools, including Safe Attachments, Safe Links, spoofed intelligence, spam filtering policies, and the Tenant Allow/Block List.