Konfigurer DMARC til at validere domænet Fra-adresse for afsendere i Microsoft 365

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 sig og om prøvevilkår her.

Domænebaseret meddelelsesgodkendelse, -rapportering og -overensstemmelse (DMARC) er en metode til mailgodkendelse , der hjælper med at validere mails, der sendes fra din Microsoft 365-organisation, for at forhindre spooferede afsendere, der bruges i beC (Business Email Compromise), ransomware og andre phishingangreb.

Du aktiverer DMARC for et domæne ved at oprette en TXT-post i DNS. DMARC-validering af en mail omfatter følgende elementer:

  • Kontrollér, at domænerne i MAIL FROM- og FROM-adresserne er justeret: SPF og DKIM kræver ikke, at domænerne i følgende mailadresser "justeres" (matcher):

    • MAIL FROM-adressen: Den mailadresse, der bruges til overførsel af meddelelsen mellem SMTP-mailservere. Denne adresse kaldes også adresse 5321.MailFrom , P1-afsender eller konvolut afsender.
    • Fra-adressen: Mailadressen i overskriftsfeltet Fra , der vises som meddelelsessender i mailklienter. Denne adresse kaldes også adressen 5322.From eller P2-afsenderen.

    Du kan få flere oplysninger om, hvordan disse mailadresser kan være i forskellige domæner og bruges til spoofing, under Hvorfor internetmail skal godkendes.

    • DMARC bruger resultatet fra SPF til at bekræfte begge følgende betingelser:

      • Meddelelsen kom fra en godkendt kilde for det domæne, der bruges i MAIL FROM-adressen (det grundlæggende krav i SPF).
      • Domænerne i adresserne MAIL FRA og Fra i meddelelsen er justeret. Dette resultat kræver effektivt, at gyldige kilder til meddelelsen skal være i domænet Fra-adresse.

    • DMARC bruger resultatet fra DKIM til at bekræfte, at det domæne, der har signeret meddelelsen (værdien d= i feltet DKIM-Signaturheader som valideret af værdien s= selektor), er i overensstemmelse med domænet i Fra-adressen.

    En meddelelse sender DMARC, hvis den ene eller begge af de beskrevne SPF- eller DKIM-kontrol bestås. En meddelelse mislykkes DMARC, hvis begge de beskrevne SPF- eller DKIM-kontroller mislykkes.

  • DMARC-politik: Angiver, hvad der skal gøres med meddelelser, der mislykkes DMARC (afvis, sæt i karantæne eller ingen instruktion).

  • DMARC-rapporter: Angiver, hvor der skal sendes aggregerede rapporter (en periodisk oversigt over positive og negative DMARC-resultater) og kriminaltekniske rapporter (også kendt som fejlrapporter, næsten øjeblikkelige DMARC-fejlresultater, der svarer til en rapport, der ikke leveres, eller en bouncemeddelelse).

Før vi går i gang, skal du gøre følgende for at få mere at vide om DMARC i Microsoft 365 baseret på dit maildomæne:

  • Hvis du kun bruger domænet Microsoft Online Email Routing Address (MOERA) til mail (f.eks. contoso.onmicrosoft.com): Selvom SPF og DKIM allerede er konfigureret til dit *.onmicrosoft.com domæne, skal du oprette DMARC TXT-posten for domænet *.onmicrosoft.com i Microsoft 365 Administration. Du kan finde instruktioner i dette afsnit senere i denne artikel. Du kan få flere oplysninger om *.onmicrosoft.com domæner under Hvorfor har jeg et "onmicrosoft.com"-domæne?.

  • Hvis du bruger et eller flere brugerdefinerede domæner til mail (f.eks. contoso.com): Hvis du ikke allerede har det, skal du konfigurere SPF for alle brugerdefinerede domæner og underdomæner, du bruger til mail. Du skal også konfigurere DKIM-signering ved hjælp af det brugerdefinerede domæne eller underdomæne, så det domæne, der bruges til at signere meddelelsen, stemmer overens med domænet i fra-adressen. Du kan finde instruktioner i følgende artikler:

    Derefter skal du også konfigurere DMARC TXT-posterne for dine brugerdefinerede domæner som beskrevet i denne artikel. Du har også følgende overvejelser:

    • Underdomæner:

      • For mailtjenester, der ikke er under din direkte kontrol (f.eks. massemailtjenester), anbefaler vi, at du bruger et underdomæne (f.eks. marketing.contoso.com) i stedet for dit primære maildomæne (f.eks. contoso.com). Du ønsker ikke, at problemer med mails, der sendes fra disse mailtjenester, skal påvirke omdømmet for mails, der sendes af medarbejdere i dit primære maildomæne. Du kan få flere oplysninger om tilføjelse af underdomæner under Kan jeg føje brugerdefinerede underdomæner eller flere domæner til Microsoft 365?.
      • I modsætning til SPF og DKIM dækker DMARC TXT-posten for et domæne automatisk alle underdomæner (herunder ikke-eksisterende underdomæner), der ikke har deres egen DMARC TXT-post. Du kan med andre ord afbryde nedarvningen af DMARC på et underdomæne ved at oprette en DMARC TXT-post i det pågældende underdomæne. Men hvert underdomæne kræver en SPF- og DKIM-post for DMARC.

    • Hvis du ejer registrerede, men ubrugte domæner: Hvis du ejer registrerede domæner, der ikke bruges til mail eller noget (også kendt som parkerede domæner), skal du konfigurere DMARC TXT-posterne i disse domæner for at angive, at ingen mail nogensinde skal komme fra disse domæner. Dette direktiv indeholder domænet *.onmicrosoft.com, hvis du ikke bruger det til mail.

  • DMARC-kontroller for indgående post kan have brug for hjælp: Hvis du bruger en mailtjeneste, der ændrer meddelelser under overførsel før levering til Microsoft 365, kan du identificere tjenesten som en PÅLIDELIG ARC-sealer, så de ændrede meddelelser ikke automatisk mislykkes DMARC-kontroller. Du kan finde flere oplysninger i afsnittet Næste trin i slutningen af denne artikel.

I resten af denne artikel beskrives den DMARC TXT-post, du skal oprette for domæner i Microsoft 365, den bedste måde at gradvist og sikkert konfigurere DMARC til brugerdefinerede domæner i Microsoft 365 på, og hvordan Microsoft 365 bruger DMARC på indgående mail.

Tip

Hvis du vil oprette DMARC TXT-posten for dit *.onmicrosoft.com domæne i Microsoft 365 Administration, skal du se dette afsnit senere i denne artikel.

Der er ingen administrationsportaler eller PowerShell-cmdlet'er i Microsoft 365, hvor du kan administrere DMARC TXT-poster i dine brugerdefinerede domæner. Du kan i stedet oprette DMARC TXT-posten hos din domæneregistrator eller DNS-hostingtjeneste (ofte den samme virksomhed).

Vi giver instruktioner til at oprette bevis for domæneejerskab TXT-posten for Microsoft 365 hos mange domæneregistratorer. Du kan bruge disse instruktioner som udgangspunkt for at oprette DMARC TXT-poster. Du kan få flere oplysninger under Tilføj DNS-poster for at oprette forbindelse til dit domæne.

Hvis du ikke er fortrolig med DNS-konfigurationen, skal du kontakte din domæneregistrator og bede om hjælp.

Syntaks for DMARC TXT-poster

DMARC TXT-poster er udtømmende beskrevet i RFC 7489.

Den grundlæggende syntaks for DMARC TXT-posten for et domæne i Microsoft 365 er:

Værtsnavn: _dmarc
TXT-værdi: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

Eller

Værtsnavn: _dmarc
TXT-værdi: v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

Det kan f.eks. være:

Værtsnavn: _dmarc
TXT-værdi: v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

  • Værdien for værtsnavn _dmarc er påkrævet.

  • v=DMARC1; identificerer TXT-posten som en DMARC TXT-post.

  • DMARC-politik: Fortæller destinationens mailsystem, hvad der skal til med meddelelser, der mislykkes DMARC som beskrevet tidligere i denne artikel:

    • p=reject: Meddelelserne bør afvises. Det, der rent faktisk sker med meddelelsen, afhænger af destinationens mailsystem, men meddelelserne kasseres typisk.
    • p=quarantine: Meddelelserne skal accepteres, men markeres. Hvad der rent faktisk sker med meddelelsen, afhænger af destinationens mailsystem. Meddelelsen kan f.eks. være sat i karantæne som spam, leveret til mappen Uønsket mail eller leveret til indbakken med et id, der er føjet til emne- eller meddelelsesteksten.
    • p=none: Ingen foreslået handling for meddelelser, der mislykkes DMARC. Det, der sker med meddelelsen, afhænger af funktionerne til mailbeskyttelse i destinationens mailsystem. Du bruger denne værdi til test og justering af DMARC-politikken som beskrevet senere i denne artikel.

    Tip

    Udgående post fra domæner i Microsoft 365, der ikke udfører DMARC-kontroller fra destinationsmailtjenesten, dirigeres gennem gruppen for højrisikolevering for udgående meddelelser , hvis DMARC-politikken for domænet er p=reject eller p=quarantine. Der er ingen tilsidesættelse af denne funktionsmåde.

  • Procentdel af mislykket DMARC-mail, der er underlagt DMARC-politik: Fortæller destinationens mailsystem, hvor mange meddelelser der mislykkes DMARC (procentdel), får den DMARC-politik, der anvendes på dem. Betyder f.eks., at alle meddelelser, pct=100 der ikke lykkes DMARC, får den DMARC-politik, der anvendes på dem. Du bruger værdier, der er mindre end 100, til test og justering af DMARC-politikken , som beskrevet senere i denne artikel. Hvis du ikke bruger pct=, er pct=100standardværdien .

  • DMARC-rapporter:

    • URI til samlet DMARC-rapport: Værdien rua=mailto: identificerer, hvor DMARC-aggregeringsrapporten skal sendes. Aggregeringsrapporten har følgende egenskaber:

      • De mails, der indeholder den samlede rapport, sendes typisk én gang om dagen (rapporten indeholder DMARC-resultaterne fra den forrige dag). Emnelinjen indeholder destinationsdomænet, der sendte rapporten (indsenderen) og kildedomænet for DMARC-resultaterne (rapportdomæne).
      • DMARC-dataene findes i en vedhæftet XML-mail, der sandsynligvis er komprimeret med GZIP. XML-skemaet er defineret i tillæg C til RFC 7489. Rapporten indeholder følgende oplysninger:
        • IP-adresserne på servere eller tjenester, der sender mail ved hjælp af dit domæne.
        • Uanset om serverne eller tjenesterne består eller mislykkes DMARC-godkendelse.
        • De handlinger, som DMARC tager på mail, der mislykkes DMARC-godkendelse (baseret på DMARC-politikken).

      Tip

      Oplysningerne i den aggregerede rapport kan være enorme og svære at fortolke. For at hjælpe med at give mening for dataene kan du bruge følgende indstillinger til DMARC-rapportering:

      • Create automatisering ved hjælp af PowerShell eller Microsoft Power BI.
      • Brug en ekstern tjeneste. Hvis du vil have vist en liste over tjenester, skal du søge efter DMARC i Kataloget for Microsoft Intelligent Security Association (MISA) på https://www.microsoft.com/misapartnercatalog. DMARC-rapporteringstjenesterne beskriver de brugerdefinerede værdier, der kræves i DMARC TXT-posten.

    • URI til DMARC-kriminalteknisk rapport: Værdien ruf=mailto: identificerer, hvor DMARC Forensic Report skal sendes (også kendt som DMARC-fejlrapporten). Rapporten genereres og sendes umiddelbart efter en DMARC-fejl, f.eks. en rapport om manglende levering (også kendt som en NDR eller bounce-meddelelse).

    Tip

    Du bør regelmæssigt gennemse DMARC Aggregerede rapporter for at overvåge, hvor mail fra dine domæner kommer fra, og for at kontrollere, om der er utilsigtede DMARC-fejl (falske positiver).

    De enkelte destinationsmailsystemer er ansvarlige for at sende DMARC-rapporter tilbage til dig. Mængden og variationen af DMARC-rapporter varierer på samme måde, som mængden og variationen af mails, der sendes fra din organisation, varierer. Du kan f.eks. forvente en lavere mailmængde i ferier og en højere mailmængde under organisationshændelser. Det er bedst at udpege bestemte personer til at overvåge DMARC-rapporter og bruge en bestemt postkasse eller Microsoft 365-gruppe til at modtage DMARC-rapporterne (levér ikke rapporterne til en brugers postkasse).

Du kan få flere oplysninger om DMARC ved at bruge følgende ressourcer:

Brug Microsoft 365 Administration til at tilføje DMARC TXT-poster for *.onmicrosoft.com domæner i Microsoft 365

  1. I Microsoft 365 Administration på https://admin.microsoft.comskal du vælge Vis alle>indstillinger>Domæner. Du kan også gå direkte til siden Domæner ved at bruge https://admin.microsoft.com/Adminportal/Home#/Domains.

  2. På siden Domæner skal du vælge domænet *.onmicrosoft.com på listen ved at klikke et vilkårligt sted i rækken ud for afkrydsningsfeltet ud for domænenavnet.

  3. På siden med domæneoplysninger, der åbnes, skal du vælge fanen DNS-poster .

  4. Vælg Tilføj post under fanen DNS-poster.

  5. Konfigurer følgende indstillinger i pop op-vinduet Tilføj en brugerdefineret DNS-post , der åbnes:

    • Type: Kontrollér, at TXT (Text) er valgt.

    • TXT-navn: Angiv _dmarc.

    • TXT-værdi: Angiv v=DMARC1; p=reject.

      Tip

      Hvis du vil angive destinationer for DMARC-samlings- og DMARC-kriminaltekniske rapporter, skal du bruge syntaksen v=DMARC1; p=reject rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. Det kunne f.eks. være v=DMARC1; p=reject rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

      DMARC-rapporteringsleverandører i MISA-kataloget på https://www.microsoft.com/misapartnercatalog gør det nemmere at få vist og fortolke DMARC-resultater.

    • TTL: Kontrollér, at 1 time er valgt.

    Når du er færdig med pop op-vinduet Tilføj en brugerdefineret DNS-post , skal du vælge Gem.

Konfigurer DMARC til aktive brugerdefinerede domæner i Microsoft 365

Tip

Som tidligere nævnt i denne artikel skal du oprette SPF TXT-poster og konfigurere DKIM-signering for alle brugerdefinerede domæner og underdomæner, som du bruger til at sende mail i Microsoft 365, før du konfigurerer DMARC for brugerdefinerede domæner eller underdomæner.

Vi anbefaler en gradvis tilgang til konfiguration af DMARC til dine Microsoft 365-domæner. Målet er at få adgang til en p=reject DMARC-politik for alle dine brugerdefinerede domæner og underdomæner, men du skal teste og bekræfte undervejs for at forhindre, at destinationens mailsystemer afviser god mail på grund af utilsigtede DMARC-fejl.

Din DMARC-udrulningsplan skal bruge følgende trin. Start med et domæne eller underdomæne med lav mailmængde og/eller færre potentielle mailkilder (mindre chance for, at legitime mails fra ukendte kilder blokeres):

  1. Start med en DMARC-politik for , p=none og overvåg resultaterne for domænet. Det kan f.eks. være:

    DMARC TXT-post for marketing.contoso.com:

    Værtsnavn: _dmarc
    TXT-værdi: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    DMARC-samlings- og DMARC-rapporterne giver antallet og kilderne til meddelelser, der består og mislykkes DMARC-kontroller. Du kan se, hvor meget af din legitime posttrafik der er eller ikke er dækket af DMARC, og foretage fejlfinding af eventuelle problemer. Du kan også se, hvor mange falske meddelelser der sendes, og hvor de sendes fra.

  2. Øg DMARC-politikken til p=quarantine , og overvåg resultaterne for domænet.

    Når der er tid nok til at overvåge effekten af p=none, kan du øge DMARC-politikken til p=quarantine for domænet. Det kan f.eks. være:

    DMARC TXT-post for marketing.contoso.com:

    Værtsnavn: _dmarc
    TXT-værdi: v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    Du kan også bruge værdien pct= til gradvist at påvirke flere meddelelser og bekræfte resultaterne. Du kan f.eks. flytte i følgende trin:

    • pct=10
    • pct=25
    • pct=50
    • pct=75
    • pct=100

  3. Øg DMARC-politikken til p=reject , og overvåg resultaterne for domænet.

    Når der er tid nok til at overvåge effekten af p=quarantine, kan du øge DMARC-politikken til p=reject for domænet. Det kan f.eks. være:

    DMARC TXT-post for marketing.contoso.com:

    Værtsnavn: _dmarc
    TXT-værdi: v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    Du kan også bruge værdien pct= til gradvist at påvirke flere meddelelser og bekræfte resultaterne.

  4. Gentag de forrige tre trin for de resterende underdomæner for at øge mængden og/eller kompleksiteten, og gem det overordnede domæne til sidst.

    Tip

    Blokering af legitime e-mails i en betydelig mængde er uacceptabelt for brugerne, men det er næsten uundgåeligt, at du får nogle falske positiver. Gå langsomt og metodisk med at håndtere problemer, der afsløres i DMARC-rapportering. DMARC-rapporteringsleverandører i MISA-kataloget gør https://www.microsoft.com/misapartnercatalog det nemmere at få vist og fortolke DMARC-resultaterne.

  5. Som beskrevet tidligere arver underdomæner indstillingerne for DMARC TXT-posten for det overordnede domæne, som kan tilsidesættes af en separat DMARC TXT-post i underdomænet. Når du er færdig med at konfigurere DMARC i et domæne og alle underdomæner, og DMARC-indstillingerne reelt er identiske for det overordnede domæne og alle underdomæner, kan du fjerne DMARC TXT-posterne i underdomænerne og stole på den enkelte DMARC TXT-post i det overordnede domæne.

DMARC TXT-poster for parkerede domæner i Microsoft 365

Tip

Den anbefalede SPF TXT-post for parkerede domæner, der ikke sender post, er beskrevet i SPF TXT-poster for brugerdefinerede domæner i Microsoft 365. Som beskrevet i Konfigurer DKIM til at signere mails fra dit Microsoft 365-domæne, anbefaler vi ikke DKIM CNAME-poster for parkerede domæner.

  1. Hvis du har registreret domæner, som ingen på internettet bør forvente at modtage mail fra, skal du oprette følgende DMARC TXT-post hos domæneregistratoren for domænet:

    Værtsnavn: _dmarc
    TXT-værdi: v=DMARC1; p=reject;

    • Værdien pct= er ikke inkluderet, fordi standardværdien er pct=100.
    • Værdierne rua=mailto: og ruf=mailto: er muligvis ikke nødvendige i dette scenarie, fordi ingen gyldige mails nogensinde skal komme fra afsendere i domænet.

  2. Hvis du ikke bruger domænet *.onmicrosoft.com til at sende post, skal du også tilføje DMARC TXT-posten for dit *.onmicrosoft.com domæne.

DMARC for indgående mail til Microsoft 365

  • DMARC-kontroller af mails, der kommer til Microsoft 365, påvirkes af følgende funktioner i Exchange Online Protection (EOP):

    • Angiver, om spoof intelligence er aktiveret eller deaktiveret i den anti-phishing-politik, der har kontrolleret meddelelsen. Deaktivering af spoof intelligence deaktiverer kun implicit spoofing-beskyttelse mod kontrol af sammensat godkendelse .
    • Angiver, om politikken For DMARC-post, når meddelelsen registreres som spoof-indstilling , er aktiveret eller deaktiveret i den anti-phishing-politik, der har kontrolleret meddelelsen, og de angivne handlinger, der er baseret på kildedomænets DMARC-politik (p=quarantineeller p=reject i DMARC TXT-posten).

    Du kan få komplette oplysninger under Spoof Protection og afsender DMARC-politikker.

    Hvis du vil se standardværdierne for disse indstillinger i politikker til bekæmpelse af phishing, skal du kontrollere indstillingsværdierne i tabellen under Indstillinger for EOP-politik for anti-phishing.

  • Microsoft 365 sender ikke DMARC Forensic Reports (også kendt som DMARC Failure Reports), selvom der findes en gyldig ruf=mailto: adresse i DMARC TXT-posten for kildedomænet.

  • Microsoft 365 sender DMARC-aggregerede rapporter til alle domæner med en gyldig rua=mailto: adresse i DMARC TXT-posterne, så længe MX-posten for Microsoft 365-domænet peger direkte på Microsoft 365.

    Hvis mails fra internettet dirigeres via en tredjepartstjeneste eller enhed, før de leveres til Microsoft 365 (MX-postpunkterne et andet sted end Microsoft 365), sendes DMARC-aggregerede rapporter ikke. Denne begrænsning omfatter hybride eller separate EOP-scenarier, hvor mail leveres til det lokale miljø, før den distribueres til Microsoft 365 ved hjælp af en connector.

    Tip

    Når en tredjepartstjeneste eller -enhed er placeret foran en post, der flyder ind i Microsoft 365, identificerer udvidet filtrering for connectors (også kaldet oversigt over oversigt) korrekt kilden til internetmeddelelser til SPF, DKIM (hvis tjenesten ændrer meddelelser) og DMARC-validering.

Fejlfinding af DMARC

Du kan bruge følgende grafik til at foretage fejlfinding af problemer med DMARC-godkendelse.

En fejlfindingsgrafik til DMARC

Næste trin

For mails, der kommer til Microsoft 365, skal du muligvis også konfigurere ARC-beseglingsprogrammer, der er tillid til, hvis du bruger tjenester, der ændrer meddelelser under overførsel, før de leveres til din organisation. Du kan få flere oplysninger under Konfigurer ARC-sealere, der er tillid til.