Sådan opsætter du Microsoft 365 e-mail korrekt: DNS-guide trin for trin

Opsætning af Microsoft 365 e-mail er ligetil, når du ved præcis, hvilke DNS-records der skal sættes - og kaotisk når du ikke gør. Forkerte eller manglende records resulterer i mail der bouncer, havner i spam, eller Outlook-klienter der ikke kan finde serverindstillinger automatisk. Denne guide giver dig den komplette oversigt over alle nødvendige DNS-records og forklarer, hvad der sker, hvis du springer et trin over.

Hvilke DNS-records kræver Microsoft 365?

Microsoft 365 kræver fem DNS-records for at e-mail fungerer korrekt og sikkert. Hertil anbefales en sjette record (DMARC) af hensyn til e-mailsikkerhed, selv om Microsoft ikke teknisk kræver den. Hver record har en specifik funktion, og de supplerer hinanden:

• MX-record - Fortæller afsendende mailservere at indgående post til dit domæne skal leveres til Microsofts mailservere. Uden den korrekte MX-record modtager du ikke e-mail via Microsoft 365.

• TXT-record (SPF) - Angiver, hvilke servere der er autoriserede til at sende e-mail på vegne af dit domæne. En forkert eller manglende SPF-record øger risikoen for at dine mails afvises eller markeres som spam.

• CNAME-record (Autodiscover) - Bruges af Outlook og andre Microsoft-klienter til automatisk at finde de korrekte serverindstillinger. Mangler den, skal brugerne konfigurere deres klient manuelt.

• CNAME-records (DKIM × 2) - To CNAME-records der peger på Microsofts DKIM-nøgler. De muliggør kryptografisk signering af udgående e-mail, hvilket styrker modtagerens tillid til at mailen er ægte.

• TXT-record (DMARC) - En politik der fortæller modtagende servere, hvad de skal gøre med mail der fejler SPF- eller DKIM-validering. DMARC er ikke teknisk påkrævet af Microsoft, men er afgørende for seriøs e-mailsikkerhed.

Alle seks records skal sættes i DNS-zonen for det domæne, du vil bruge til Microsoft 365. Det gøres typisk hos din DNS-host eller dit domæneregistrar - ikke inde i Microsoft 365 Admin Center.

Trin 1: Find de rigtige værdier til dit domæne

Værdien for din MX-record og DKIM-records er unikke for dit domæne. Du kan ikke bare kopiere en generisk værdi fra internettet. Microsoft genererer specifikke værdier baseret på dit tenant-navn, som typisk ser ud som ditdomæne.onmicrosoft.com.

Den hurtigste måde at finde de korrekte, domænespecifikke værdier på er via DNSinfos Microsoft 365-værktøj. Indtast dit domæne, og værktøjet returnerer de præcise records, du skal oprette - inklusive den korrekte MX-prioritet og de to DKIM CNAME-records med de rigtige selektornavne.

Alternativt kan du finde værdierne direkte i Microsoft 365 Admin Center under Indstillinger > Domæner > vælg dit domæne > DNS-records. Microsoft viser her alle påkrævede records med de korrekte værdier.

Trin 2: MX-record - sæt den korrekt og slet den gamle

MX-recorden er den mest kritiske. Den bestemmer, hvor indgående e-mail leveres. Microsofts MX-record for dit domæne har formatet:

ditdomæne-com.mail.protection.outlook.com

Prikker i domænenavnet erstattes med bindestreger i MX-værdien. For domænet eksempel.dk vil værdien altså være eksempel-dk.mail.protection.outlook.com. Prioriteten sættes typisk til 0 eller 10.

Det vigtigste fejltrin her er at glemme at slette den gamle MX-record. Har du tidligere brugt en anden mailudbyder - f.eks. din hosting-leverandørs mailserver - vil den gamle MX-record stadig være aktiv. Resultatet er uforudsigeligt: noget post leveres til Microsoft 365, andet leveres til den gamle server. Slet altid eksisterende MX-records for domænet, inden du tilføjer den nye.

Husk at MX-records har en TTL (Time To Live), som bestemmer, hvor hurtigt ændringen slår igennem globalt. Sæt TTL til 300 sekunder (5 minutter) inden du foretager ændringen, så propagationen går hurtigere. Du kan tjekke om den nye MX-record er slået igennem med DNSinfos DNS-opslag.

Trin 3: SPF TXT-record

SPF (Sender Policy Framework) angives som en TXT-record på dit domænes rodzone (@). Microsofts SPF-record ser sådan ud:

v=spf1 include:spf.protection.outlook.com -all

include:spf.protection.outlook.com delegerer SPF-valideringen til Microsofts egne SPF-records, som dækker alle Microsofts afsendende mailservere. -all angiver at al post fra servere der ikke er nævnt, skal afvises.

Den klassiske fejl med SPF er at have to SPF-records. En DNS-zone må kun indeholde én SPF TXT-record. Har du tidligere brugt en anden mailudbyder og allerede har en SPF-record, skal du ikke oprette en ny - du skal redigere den eksisterende. Har du f.eks. en eksisterende record som v=spf1 include:mailservicen.dk -all, og vil du tilføje Microsoft 365, skal den se sådan ud:

v=spf1 include:spf.protection.outlook.com include:mailservicen.dk -all

To separate SPF-records på samme domæne resulterer i en PermError, og modtagende mailservere vil typisk afvise eller nedprioritere din post. Brug DNSinfos SPF-analyseværktøj til at verificere at din SPF-record er syntaktisk korrekt og ikke overskrider DNS-opslags-grænsen på 10 includes.

Trin 4: Autodiscover CNAME

Autodiscover-recorden gør det muligt for Outlook og andre Microsoft-mailklienter automatisk at finde de korrekte serverindstillinger - Exchange Online-serveradresse, portnumre og krypteringsindstillinger - uden at brugeren skal indtaste noget manuelt.

Recorden oprettes som en CNAME med følgende værdier:

• Navn/host: autodiscover

• Peger på: autodiscover.outlook.com

• TTL: 3600 (1 time)

Mangler denne record, vil nye Outlook-klienter ikke kunne konfigureres automatisk. Brugerne vil blive bedt om at indtaste serverindstillinger manuelt, og i nogle tilfælde vil klienten slet ikke kunne oprette forbindelse. Det er en hyppig årsag til supporthenvendelser efter en migration til Microsoft 365.

Trin 5: DKIM - aktivering og de to CNAME-records

DKIM (DomainKeys Identified Mail) kræver to handlinger: oprettelse af CNAME-records i DNS og aktivering af DKIM-signering i Microsoft 365 Admin Center. Begge dele skal udføres - DNS-records alene er ikke tilstrækkeligt.

De to CNAME-records har formatet:

• Navn: selector1._domainkey.ditdomæne.dk - Peger på: selector1-ditdomæne-dk._domainkey.dittenantname.onmicrosoft.com

• Navn: selector2._domainkey.ditdomæne.dk - Peger på: selector2-ditdomæne-dk._domainkey.dittenantname.onmicrosoft.com

Værdierne er unikke for dit tenant og domæne. Find dem via Microsoft 365-værktøjet eller direkte i Microsoft 365 Defender-portalen (security.microsoft.com) under E-mail & samarbejde > Politikker & regler > Trusselspolitikker > E-mail-godkendelsesindstillinger > DKIM.

Når CNAME-records er oprettet og propageret (tjek med DNS-opslag), aktiverer du DKIM-signering i Admin Center ved at klikke Aktivér for dit domæne. Springer du aktiveringen over, signeres udgående mails ikke med DKIM - selv om DNS-records er korrekte.

Trin 6: DMARC - en startpolitik der beskytter dit domæne

DMARC er ikke et krav fra Microsoft, men det er en forudsætning for at SPF og DKIM reelt beskytter dit domæne mod spoofing. Uden DMARC kan hvem som helst sende e-mail der udgiver sig for at komme fra dit domæne - og modtagende servere har ingen instruktion om, hvad de skal stille op med det.

En fornuftig startpolitik ser sådan ud:

v=DMARC1; p=none; rua=mailto:dmarc-rapporter@ditdomæne.dk

p=none betyder at ingen mail afvises endnu - du observerer blot. rua angiver en adresse der modtager aggregerede rapporter om, hvem der sender mail på vegne af dit domæne. Når du har analyseret rapporterne og er sikker på at al legitim post passerer korrekt, kan du stramme politikken til p=quarantine og til sidst p=reject.

Brug DNSinfos DMARC-generator til at bygge en korrekt formateret DMARC-record. Du kan læse mere om den fulde DMARC-rejse i guiden fra nul til reject.

Komplet referencetabel over alle records

Erstat "ditdomæne-dk" og "tenant" med de faktiske værdier for dit domæne og Microsoft 365-tenant.

Typiske fejl og hvad de forårsager

Tre fejl går igen i langt de fleste problematiske Microsoft 365-opsætninger:

• Dobbelt SPF-record: To TXT-records med v=spf1 på samme domæne giver en permanent SPF-fejl. Modtagende servere ved ikke, hvilken record de skal følge, og resultatet er typisk at mails afvises eller markeres som mistænkelige. Tjek altid om der allerede eksisterer en SPF-record, inden du opretter en ny.

• Gammel MX-record ikke slettet: Efterlades den gamle MX-record, vil noget post stadig forsøges leveret til den gamle mailserver. I overgangsfasen kan dette betyde at mails forsvinder eller afvises, fordi den gamle server ikke længere håndterer domænet. En migration er ikke afsluttet, før den gamle MX er væk.

• DKIM aktiveret i DNS men ikke i Admin Center: CNAME-records i DNS er kun halvdelen af DKIM-opsætningen. Microsoft 365 skal eksplicit instrueres i at signere udgående post. Glemmer du aktiveringen i Admin Center, sendes mails uden DKIM-signatur - og dit domæne er mere sårbart over for spoofing og leveringsproblemer.

Verificer opsætningen

Når alle records er oprettet, bør du systematisk verificere at de er korrekte og globalt propageret. Brug DNS-opslagsværktøjet til at slå MX-, TXT- og CNAME-records op for dit domæne og bekræft at værdierne matcher det forventede.

Kør derefter en SPF-analyse for at sikre at SPF-recorden er syntaktisk korrekt, at der kun findes én SPF-record, og at antallet af DNS-opslag ikke overskrider grænsen på 10. En SPF-record der overskrider denne grænse, vil ofte fejle validering hos modtagende servere - selv om syntaksen er korrekt.

Tjek desuden om dit domæne er havnet på en e-mail-blacklist som følge af tidligere mailkonfigurationsproblemer, med blacklist-checken. Et domæne der er blacklistet, vil have leveringsproblemer uanset hvor korrekt DNS-opsætningen er. Se også guiden til håndtering af mailblokering, hvis dit domæne er kompromitteret.

Endelig kan du i Microsoft 365 Admin Center under Indstillinger > Domæner se en status for hvert DNS-krav. Microsoft markerer records som "Fundet" eller "Ikke fundet" og giver dermed en hurtig oversigt over, hvad der mangler.

Når alle seks records er på plads, korrekt konfigureret og valideret - MX, SPF, Autodiscover, de to DKIM CNAME-records og DMARC - er din Microsoft 365 e-mail-opsætning komplet. Post leveres korrekt, udgående mails er kryptografisk signerede, og du har grundlaget for at beskytte dit domæne mod spoofing og phishing.