Bruk DMARC til å validere e-post
Tips
Visste du at du kan prøve funksjonene i Microsoft 365 Defender for Office 365 Plan 2 gratis? Bruk den 90-dagers prøveversjonen av Defender for Office 365 på Microsoft Defender portalens prøvehub. Finn ut mer om hvem som kan registrere seg og vilkår for prøveversjonen her.
Domenebasert meldingsgodkjenning, rapportering og samsvar (DMARC) fungerer med Struktur for avsenderpolicy (SPF) og DomainKeys Identified Mail (DKIM) for å godkjenne e-postavsendere.
DMARC sikrer at mål-e-postsystemene klarerer meldinger som sendes fra domenet ditt. Bruk av DMARC med SPF og DKIM gir organisasjoner mer beskyttelse mot forfalskning og phishing-e-post. DMARC hjelper mottak av e-postsystemer med å bestemme hva de skal gjøre med meldinger fra domenet som mislykkes SPF- eller DKIM-kontroller.
Tips
Gå til katalogen til Microsoft Intelligent Security Association (MISA) for å vise tredjepartsleverandører som tilbyr DMARC-rapportering for Microsoft 365.
Tips
Har du sett våre trinnvise veiledninger? Konfigurasjon 1-2-3s og ingen frills, for administratorer i en hast. Gå til trinnene for å aktivere DMARC-rapportering for Microsoft Online-e-postrutingsadresser (MOERA) og parkerte domener.
Hvordan fungerer SPF og DMARC sammen for å beskytte e-post i Microsoft 365?
En e-postmelding kan inneholde flere avsender- eller avsenderadresser. Disse adressene brukes til ulike formål. Vurder for eksempel disse adressene:
E-post fra-adresse: Identifiserer avsenderen og sier hvor returvarsler skal sendes hvis det oppstår problemer med leveringen av meldingen (for eksempel varsler om manglende levering). E-post fra adresse vises i konvoluttdelen av en e-postmelding og vises ikke av e-postprogrammet, og kalles noen ganger 5321.MailFrom-adressen eller adressen for omvendt bane.
Fra-adresse: Adressen som vises som Fra-adressen av e-postprogrammet. Fra adresse identifiserer forfatteren av e-postmeldingen. Det vil se ut som postboksen til personen eller systemet som er ansvarlig for å skrive meldingen. Fra-adressen kalles noen ganger 5322.Fra-adressen.
SPF bruker en DNS TXT-post til å føre opp autoriserte sende-IP-adresser for et gitt domene. Vanligvis utføres SPF-kontroller bare mot 5321.MailFrom-adressen. 5322.From-adressen godkjennes ikke når du bruker SPF alene, noe som muliggjør et scenario der en bruker får en melding som sendte SPF-kontroller, men har en falsk 5322.Fra-avsenderadresse. Vurder for eksempel denne SMTP-utskriften:
S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.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 User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has 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 denne utskriften er avsenderadressene som følger:
E-post fra adresse (5321.MailFrom): phish@phishing.contoso.com
Fra-adresse (5322.From): security@woodgrovebank.com
Hvis du konfigurerte SPF, kontrollerer mottakerserveren E-post fra-adressen phish@phishing.contoso.com. Hvis meldingen kom fra en gyldig kilde for domenet phishing.contoso.com, sendes SPF-kontrollen. Siden e-postklienten bare viser Fra-adressen, ser brukeren denne meldingen fra security@woodgrovebank.com. Med SPF alene ble gyldigheten av woodgrovebank.com aldri godkjent.
Når du bruker DMARC, utfører mottakerserveren også en kontroll mot Fra-adressen. I eksemplet ovenfor, hvis det er en DMARC TXT-post på plass for woodgrovebank.com, mislykkes kontrollen mot Fra-adressen.
Hva er en DMARC TXT-post?
I likhet med DNS-postene for SPF er posten for DMARC en DNS-tekstpost (TXT) som bidrar til å forhindre forfalskning og phishing. Du publiserer DMARC TXT-poster i DNS. DMARC TXT-poster validerer opprinnelsen til e-postmeldinger ved å bekrefte IP-adressen til en e-postforfatter mot den påståtte eieren av avsenderdomenet. DMARC TXT-posten identifiserer autoriserte utgående e-postservere. Mål-e-postsystemer kan deretter bekrefte at meldinger de mottar kommer fra autoriserte utgående e-postservere.
Microsofts DMARC TXT-post ser omtrent slik ut:
_dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"
Hvis du vil ha flere tredjepartsleverandører som tilbyr DMARC-rapportering for Microsoft 365, kan du gå til MISA-katalogen.
Konfigurere DMARC for innkommende e-post
Du trenger ikke å gjøre noe for å konfigurere DMARC for e-post som du mottar i Microsoft 365. Alt er tatt hånd om. Hvis du vil finne ut hva som skjer med e-post som ikke består DMARC-kontrollene våre, kan du se hvordan Microsoft 365 håndterer innkommende e-post som mislykkes med DMARC.
Konfigurere DMARC for utgående e-post fra Microsoft 365
Hvis du bruker Microsoft 365, men ikke bruker et egendefinert domene (du bruker onmicrosoft.com), er SPF allerede konfigurert for deg, og Microsoft 365 genererer automatisk en DKIM-signatur for utgående e-post (hvis du vil ha mer informasjon om denne signaturen, kan du se Standard virkemåte for DKIM og Microsoft 365). Hvis du vil konfigurere DMARC for organisasjonen, må du danne DMARC TXT-posten for onmicrosoft.com-domenet og publisere den til DNS via Office 365 Admin Center> Settings > Domains klikker på onmicrosoft.com domenetilleggspost >>.
Hvis du har et egendefinert domene eller bruker lokale Exchange-servere sammen med Microsoft 365, må du manuelt konfigurere DMARC for utgående e-post. Du kan konfigurere DMARC for det egendefinerte domenet ved å følge disse trinnene:
Trinn 1: Identifiser gyldige e-postkilder for domenet
Hvis du allerede har konfigurert SPF, har du allerede gått gjennom denne øvelsen. Det er noen ytterligere vurderinger for DMARC. Svar på disse to spørsmålene når du identifiserer e-postkilder for domenet:
Hvilke IP-adresser sender meldinger fra domenet mitt?
Vil 5321.MailFrom og 5322.From-domenene samsvare for e-post sendt fra tredjeparter på mine vegne?
Trinn 2: Konfigurere SPF for domenet
Nå som du har en liste over alle gyldige avsendere, kan du følge trinnene for å konfigurere SPF for å forhindre forfalskning.
Forutsatt at contoso.com sender e-post fra Exchange Online, en lokal Exchange-server med IP-adressen 192.168.0.1, og et nettprogram med IP-adressen 192.168.100.100, vil SPF TXT-posten se slik ut:
contoso.com IN TXT " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"
Som en anbefalt fremgangsmåte må du sørge for at SPF TXT-posten tar hensyn til tredjeparts avsendere.
Trinn 3: Konfigurere DKIM for det egendefinerte domenet
Når du har konfigurert SPF, må du konfigurere DKIM. Med DKIM kan du legge til en digital signatur i e-postmeldinger i meldingshodet. Hvis du ikke konfigurerer DKIM og i stedet tillater at Microsoft 365 bruker standard DKIM-konfigurasjon for domenet, kan DMARC mislykkes. Denne feilen kan oppstå fordi standard DKIM-konfigurasjon bruker det opprinnelige onmicrosoft.com domenet som 5321.MailFrom-adressen , ikke det egendefinerte domenet. Dette skaper en uoverensstemmelse mellom 5321.MailFrom og 5322.From-adressene i all e-post som sendes fra domenet.
Hvis du har tredjepartsavsendere som sender e-post på dine vegne, og e-posten de sender, ikke samsvarer med 5321.MailFrom og 5322.From-adresser, vil DMARC mislykkes for denne e-posten. Hvis du vil unngå dette, må du konfigurere DKIM for domenet spesielt med denne tredjepartsavsenderen. Dette gjør at Microsoft 365 kan godkjenne e-post fra denne tredjepartstjenesten. Men det gjør det også mulig for andre, for eksempel Yahoo, Gmail og Comcast, å bekrefte e-post sendt til dem av tredjeparten som om det var e-post sendt av deg. Dette er nyttig fordi det gjør det mulig for kundene å bygge klarering med domenet uansett hvor postboksen er plassert, og samtidig vil ikke Microsoft 365 merke en melding som søppelpost på grunn av forfalskning fordi den passerer godkjenningskontroller for domenet ditt.
Hvis du vil ha instruksjoner om hvordan du konfigurerer DKIM for domenet ditt, inkludert hvordan du konfigurerer DKIM for tredjepartsavsendere slik at de kan forfalske domenet ditt, kan du se Bruke DKIM til å validere utgående e-post sendt fra det egendefinerte domenet.
Trinn 4: Skjema DMARC TXT-posten for domenet
Selv om det finnes andre syntaksalternativer som ikke nevnes her, er dette de mest brukte alternativene for Microsoft 365. Skjema DMARC TXT-posten for domenet i formatet:
_dmarc.domain TTL IN TXT "v=DMARC1; p=policy; pct=100"
Hvor:
domenet er domenet du vil beskytte. Posten beskytter e-post fra domenet og alle underdomener som standard. Hvis du for eksempel angir _dmarc.contoso.com, beskytter DMARC e-post fra domenet og alle underdomener, for eksempel housewares.contoso.com eller plumbing.contoso.com.
TTL må alltid være tilsvarende én time. Enheten som brukes for TTL, enten timer (1 time), minutter (60 minutter) eller sekunder (3600 sekunder), varierer avhengig av registratoren for domenet.
pct=100 angir at denne regelen skal brukes for 100 % av e-posten.
policy angir hvilken policy du vil at mottakerserveren skal følge hvis DMARC mislykkes. Du kan angi policyen til ingen, karantene eller forkaste.
Hvis du vil ha informasjon om hvilke alternativer du skal bruke, kan du bli kjent med konseptene i anbefalte fremgangsmåter for implementering av DMARC i Microsoft 365.
Eksempler:
Policy satt til ingen
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=none"Policy satt til karantene
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=quarantine"Policy satt til å forkaste
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=reject"
Når du har utformet posten, må du oppdatere posten hos domeneregistratoren.
DMARC-e-post
Forsiktig!
E-postmeldinger kan ikke sendes ut daglig.
I dette eksemplet DMARC TXT-post: dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.example.com; ruf=mailto:d@ruf.example.com; fo=1"kan du se rua-adressen . Denne adressen brukes til å sende «aggregert tilbakemelding» for analyse, som brukes til å generere en rapport.
Tips
Gå til MISA-katalogen for å vise flere tredjepartsleverandører som tilbyr DMARC-rapportering for Microsoft 365. Se IETF.org's Domenebasert meldingsgodkjenning, rapportering og samsvar (DMARC)' for mer informasjon om DMARC rua-adresser.
Anbefalte fremgangsmåter for implementering av DMARC i Microsoft 365
Du kan implementere DMARC gradvis uten å påvirke resten av e-postflyten. Opprett og implementer en utrullingsplan som følger disse trinnene. Gjør hvert av disse trinnene først med et underdomene, deretter andre underdomener, og til slutt med det øverste domenet i organisasjonen før du går videre til neste trinn.
Overvåk virkningen av å implementere DMARC
Start med en enkel overvåkingsmoduspost for et underdomene eller domene som ber om at DMARC-mottakere sender deg statistikk om meldinger de ser ved hjelp av dette domenet. En overvåkingsmoduspost er en DMARC TXT-post som har policyen satt til ingen (p=none). Mange selskaper publiserer en DMARC TXT-post med p=none fordi de er usikre på hvor mye e-post de kan miste ved å publisere en mer restriktiv DMARC-policy.
Du kan gjøre dette selv før du har implementert SPF eller DKIM i meldingsinfrastrukturen. Du kan imidlertid ikke effektivt sette e-post i karantene eller avvise e-post ved hjelp av DMARC før du også implementerer SPF og DKIM. Når du introduserer SPF og DKIM, vil rapportene som genereres gjennom DMARC, gi tallene og kildene til meldinger som består disse kontrollene, i motsetning til de som ikke gjør det. Du kan enkelt se hvor mye av den legitime trafikken som er eller ikke dekkes av dem, og feilsøke eventuelle problemer. Du begynner også å se hvor mange falske meldinger som sendes, og hvor de sendes fra.
Be om at eksterne e-postsystemer setter e-post i karantene som mislykkes DMARC
Når du tror at hele eller det meste av den legitime trafikken er beskyttet av SPF og DKIM, og du forstår virkningen av å implementere DMARC, kan du implementere en karantenepolicy. En karantenepolicy er en DMARC TXT-post som har policyen satt i karantene (p=karantene). Ved å gjøre dette ber du DMARC-mottakere om å plassere meldinger fra domenet som mislykkes DMARC i den lokale ekvivalenten av en søppelpostmappe i stedet for kundenes innbokser.
Be om at eksterne e-postsystemer ikke godtar meldinger som mislykkes DMARC
Det siste trinnet er å implementere en forkastingspolicy. En forkastingspolicy er en DMARC TXT-post som har policyen satt til å avvise (p=reject). Når du gjør dette, ber du DMARC-mottakere om ikke å godta meldinger som ikke består DMARC-kontrollene.
Hvordan konfigurere DMARC for underdomene?
DMARC implementeres ved å publisere en policy som en TXT-post i DNS og er hierarkisk (for eksempel vil en policy som publiseres for contoso.com gjelde for sub.domain.contoso.com med mindre en annen policy er eksplisitt definert for underdomenet). Dette er nyttig fordi organisasjoner kan angi et mindre antall DMARC-poster på høyt nivå for bredere dekning. Det bør være lurt å konfigurere eksplisitte DMARC-poster for underdomene der du ikke vil at underdomenene skal arve DMARC-posten for domenet på øverste nivå.
Du kan også legge til en policy for jokertegntype for DMARC når underdomener ikke skal sende e-post, ved å legge til
sp=rejectverdien. Eksempel:_dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"
Avvis DMARC
DMARC p=reject er en policy som er angitt i DMARC TXT-posten av domeneeiere for å varsle tjenesteleverandører om å avvise e-post som mislykkes DMARC.
Det kom fordi når OReject er angitt som standard, ble avvist e-post sendt til karantene i Enterprise, og til søppelpostmappen i Forbruker (på grunn av mangel på karantene i forbruker). Med DMARC p=rejectblir imidlertid e-postmeldingen avvist.
Konfigurasjonen kan utføres i Microsoft Defender-portalen, eller av cmdletene New-AntiPhishPolicy eller Set-AntiPhishPolicy i Exchange Online PowerShell. Hvis du vil ha mer informasjon, kan du se følgende artikler:
- Forfalskningsbeskyttelse og DMARC-policyer for avsender
- Konfigurer policyer for anti-phishing i EOP
- Konfigurer policyer for anti-phishing i Microsoft Defender for Office 365
Slik håndterer Microsoft 365 utgående e-post som mislykkes DMARC
Hvis en melding er utgående fra Microsoft 365 og dmarc mislykkes, og du har angitt policyen til p=karantene eller p=avvis, rutes meldingen gjennom leveringsutvalget med høy risiko for utgående meldinger. Det finnes ingen overstyring for utgående e-post.
Hvis du publiserer en DMARC-forkastingspolicy (p=reject), kan ingen andre kunder i Microsoft 365 forfalske domenet fordi meldinger ikke kan sende SPF eller DKIM for domenet når du videresender en melding utgående gjennom tjenesten. Men hvis du publiserer en DMARC-avvisningspolicy, men ikke har all e-post godkjent via Microsoft 365, kan noe av den merkes som søppelpost for innkommende e-post (som beskrevet ovenfor), eller den blir avvist hvis du ikke publiserer SPF og prøver å videresende den utgående gjennom tjenesten. Dette skjer for eksempel hvis du glemmer å inkludere noen av IP-adressene for servere og apper som sender e-post på vegne av domenet når du danner DMARC TXT-posten.
Slik håndterer Microsoft 365 innkommende e-post som mislykkes DMARC
Hvis DMARC-policyen for avsenderdomenet er p=reject, avviser Exchange Online Protection (EOP) meldingen som standard. Du kan konfigurere policyer for anti-phishing til å overholde eller ikke overholde p=quarantine og p=reject i DMARC-policyer for avsender, og angi separate handlinger for p=quarantine og p=reject. Hvis du vil ha mer informasjon, kan du se Policyer for forfalskningsbeskyttelse og DMARC-policyer for avsender.
Når policyer for anti-phishing er konfigurert til ikke å overholde p=quarantine eller p=reject i DMARC-policyer, merkes meldinger som mislykkes av DMARC som søppelpost og blir ikke avvist. Brukere kan fremdeles få disse meldingene i innboksen gjennom disse metodene:
- Brukere legger til klarerte avsendere enkeltvis ved hjelp av e-postklienten.
- Administratorer kan bruke falsk intelligensinnsikt eller leierens tillatelses-/blokkeringsliste til å tillate meldinger fra den forfalskede avsenderen.
- Administratorer oppretter en Exchange-regel for e-postflyt (også kjent som en transportregel) for alle brukere som tillater meldinger for de bestemte avsenderne.
- Administratorer oppretter en Exchange-e-postflytregel for alle brukere for avvist e-post som ikke oppfyller organisasjonens DMARC-policy.
Hvis du vil ha mer informasjon, kan du se Opprette lister over klarerte avsendere.
Slik bruker Microsoft 365 godkjent mottatt kjede (ARC)
Alle vertsbaserte postbokser i Microsoft 365 vil nå dra nytte av ARC med forbedret leveranse av meldinger og forbedret beskyttelse mot forfalskning. ARC bevarer e-postgodkjenningsresultatene fra alle deltakende mellomledd, eller hopp, når en e-postmelding rutes fra den opprinnelige serveren til mottakerpostboksen. Før ARC kan endringer utført av mellomledd i e-postruting, for eksempel videresendingsregler eller automatiske signaturer, forårsake DMARC-feil innen e-postmeldingen nådde mottakerpostboksen. Med ARC gjør den kryptografiske bevaringen av godkjenningsresultatene det mulig for Microsoft 365 å bekrefte ektheten til avsenderen av en e-post.
Microsoft 365 bruker for øyeblikket ARC til å bekrefte godkjenningsresultater når Microsoft er ARC Sealer, men planlegger å legge til støtte for tredjeparts ARC-sealers i fremtiden.
Feilsøke DMARC-implementeringen
Hvis du har konfigurert domenets MX-poster der EOP ikke er den første oppføringen, håndheves ikke DMARC-feil for domenet.
Hvis du er en kunde, og domenets primære MX-post ikke peker til EOP, får du ikke fordelene med DMARC. DMARC vil for eksempel ikke fungere hvis du peker MX-posten til den lokale e-postserveren og deretter ruter e-post til EOP ved hjelp av en kobling. I dette scenarioet er det mottakende domenet ett av Accepted-Domains, men EOP er ikke den primære MX-en. Anta for eksempel at contoso.com peker sin MX på seg selv og bruker EOP som en sekundær MX-post, ser contoso.coms MX-post slik ut:
contoso.com 3600 IN MX 0 mail.contoso.com
contoso.com 3600 IN MX 10 contoso-com.mail.protection.outlook.com
Alle, eller de fleste, e-post rutes først til mail.contoso.com siden det er den primære MX-en, og deretter blir e-post rutet til EOP. I noen tilfeller kan det hende at du ikke engang viser EOP som en MX-post i det hele tatt, og bare kobler til koblinger for å rute e-posten. EOP trenger ikke å være den første oppføringen for DMARC-validering som skal utføres. Det sikrer bare valideringen, for å være sikker på at alle lokale/ikke-O365-servere utfører DMARC-kontroller. DMARC er kvalifisert til å håndheves for kundens domene (ikke server) når du konfigurerer DMARC TXT-posten, men det er opp til mottakerserveren å gjøre håndhevelse. Hvis du konfigurerer EOP som mottakerserver, gjør EOP DMARC-håndhevelsen.
Hvis du vil ha mer informasjon
Vil du ha mer informasjon om DMARC? Disse ressursene kan hjelpe deg.
Meldingshoder mot søppelpost inkluderer syntaksen og overskriftsfeltene som brukes av Microsoft 365 for DMARC-kontroller.
Ta DMARC-opplæringsserien fra M3AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
Bruk sjekklisten på dmarcian.
Gå direkte til kilden på DMARC.org.
Se også
Slik bruker Microsoft 365 Struktur for avsenderpolicy (SPF) for å hindre forfalskning
Konfigurere SPF i Microsoft 365 for å forhindre forfalskning
Bruk DKIM til å validere utgående e-post sendt fra det egendefinerte domenet i Microsoft 365