Undgå mail-nedetid: MX-ændring i Exchange Online

Et nyt domæne plejer at være “bare DNS”. Fra 1. juli 2026 kan et nyt Microsoft 365-domæne stoppe jeres indgående e-mail, hvis I bruger gamle MX-værdier eller automatisering med hardcodede records. Det rammer især ved virksomhedsopkøb, nye brands og datterselskaber, hvor mail skal virke samme dag. Med få konkrete ændringer kan I gøre domæne-onboarding forudsigelig igen.

• Undgå driftstop ved nye domæner: opdater jeres proces, så Exchange Online MX records 2026 hentes dynamisk og ikke ligger fast i scripts.
• Fjern den klassiske faldgrube: kortlæg hvor I stadig bruger mail.protection.outlook.com som “standard-MX”, og ret før næste M&A.
• Luk et sikkerhedshul (MitM): planlæg DNSSEC + SMTP DANE, som Microsoft nu understøtter for inbound mail (GA).
• Skab klart ejerskab: aftal hvem der ændrer DNS (webbureau/hosting/IT/MSP) og hvad der testes før cutover.
• Dokumentér compliance-tiltag: brug DNSSEC/DANE som håndgribelig dokumentation i jeres NIS2/ISO-arbejde.

Hvorfor ændrer Microsoft MX til mx.microsoft?

Microsoft flytter nye domæners mail-routing fra det kendte *.mail.protection.outlook.com til mx.microsoft for at understøtte DNSSEC og inbound SMTP DANE i Exchange Online. Formålet er at gøre det sværere at aflytte eller nedgradere TLS på vej ind (Man-in-the-Middle), fordi DANE bruger DNSSEC til at validere, at TLS-forbindelsen er den rigtige. Se Microsofts udmelding i Message Center (MC1048624) og GA-annonceringen af inbound SMTP DANE.

For jer betyder det: “sæt MX til X” bliver ikke et stabilt svar fremover. Det korrekte svar afhænger af domænet, og værdierne skal hentes fra Microsoft som source of truth (fx via Microsoft Graph), ikke fra en gammel runbook.

Hvilke domæner påvirkes af Exchange Online MX records 2026?

Deadlinen i MC1048624 gælder nye Accepted Domains, der oprettes efter udrulningen (sat til 1. juli 2026). Eksisterende domæner fortsætter typisk som de er, men jeres processer rammes uanset hvad, fordi det ofte er samme script/runbook, der bruges til alle domæner.

Fejl der koster mailflow ved M&A

• Hardcodet MX: “sæt MX til domain-com.mail.protection.outlook.com” i et script eller i en onboarding-skabelon.
• DNS ejes af andre: domænet ligger hos et webbureau/hostingpartner, og ændringer bliver kørt uden testvindue.
• Split ansvar: én person opretter domænet i M365, en anden lægger DNS-records, og ingen validerer samlet mailflow.

Før → Efter (mikro-transformation #1):
Før: IT opretter domænet og sender en mail med “MX = mail.protection…” til et bureau, der kopierer en gammel opskrift.
Efter: IT henter aktuelle service-records fra Microsoft (Graph/portalen), lægger dem i en DNS-change med rollback og tester indgående mail før go-live. Resultat: færre “mystiske” leveringsfejl på dag 1.

Sådan undgår I at scripts knækker, når MX skifter

Hvis I automatiserer tenant- og domæne-onboarding med PowerShell, RMM eller tredjepartsværktøjer, så antag at alt, der bygger på statiske MX-værdier, kan fejle fra juli 2026. Microsoft og uafhængige analyser peger på, at I bør bruge API/portalen som sandhed i stedet for at gætte records.

Tre beslutningsregler til IT

1. Hvis jeres onboarding har en fast streng med mail.protection.outlook.com: ændr nu. Det er en kendt “break point”.
2. Hvis I har flere DNS-udbydere: standardisér, eller lav pr. udbyder playbooks (DNSSEC understøttelse varierer).
3. Hvis I ikke kan teste mailflow samme dag: planlæg domæne-tilføjelse som en change med acceptkriterier (se tjeklisten nedenfor).

Tjekliste: Domæne-onboarding der holder efter 1. juli 2026

Brug tjeklisten som change-template. Den er lavet til jer, der vil kunne onboarde et nyt domæne uden at “gætte DNS”.

Kontrolpunkt	Hvad I gør	Hvad I kigger efter (acceptkriterie)
1) Ejerskab af DNS	Afklar hvem der kan ændre DNS og hvor hurtigt (bureau/hosting/jeres MSP).	Navngiven ansvarlig + aftalt SLA for DNS-changes.
2) Hent aktuelle M365 service-records	Hent records fra Microsoft (portal/Graph) for det konkrete domæne.	MX/tekstposter matches 1:1 med Microsofts anbefalinger (ingen copy/paste fra gamle domæner).
3) Stop hardcoding i scripts	Gennemgå onboarding-scripts, runbooks og SOP’er for statiske værdier.	Ingen faste MX-hostnames; records kommer fra en dynamisk kilde eller manuel “source of truth”.
4) DNSSEC readiness	Tjek om jeres DNS-host kan signere zonen og håndtere key rollover.	DNSSEC kan aktiveres uden at bryde delegation (plan for DS-record i registrator).
5) Plan for SMTP DANE	Aftal om I vil køre DANE inbound, og hvordan I dokumenterer det.	Beslutning logget (ja/nej) + hvem der følger op i drift.
6) Mailflow-test	Test indgående mail fra mindst to eksterne domæner (fx leverandør + privat).	Levering til inbox uden forsinkelse; header viser TLS, og ingen NDR/queue-problemer.
7) Basis e-mail sikkerhed	Valider SPF, DKIM og DMARC samtidig med domæne-go-live.	SPF uden for mange lookups, DKIM signer korrekt, DMARC policy er bevidst valgt.

Før → Efter (mikro-transformation #2):
Før: Domæner bliver onboardet “når vi får tid”, og dokumentation ligger i en mailtråd.
Efter: Hvert domæne får en change med tjekliste, testresultater og ansvarlig. Resultat: hurtigere fejlfinding og færre gentagne fejl ved næste domæne.

Hvordan passer DNSSEC og DANE ind i NIS2 og compliance?

NIS2 handler i praksis om at kunne dokumentere styring af risici i drift og leverandørkæde. DNSSEC er et konkret kontrolpunkt i DNS-infrastrukturen (ENISA har DNS-sikring som anbefaling), og NIST fremhæver DANE/DNSSEC som en del af “trustworthy email”. Det gør det nemmere at vise, at I aktivt reducerer risikoen for manipulation af routing og TLS-nedgradering.

Hvis I allerede arbejder med compliance, så behandl DNS som en “kritisk afhængighed” på linje med identitet (Entra ID) og patching: log ændringer, håndhæv change management, og gem testbeviser.

FAQ: Exchange Online MX records 2026, mx.microsoft og DANE

Hvad er mx.microsoft?

mx.microsoft er Microsofts nye MX-infrastruktur for nye Exchange Online-domæner, lavet til at understøtte DNSSEC og inbound SMTP DANE. Pointen er, at MX ikke længere er en “evig” værdi, I kan kopiere fra et gammelt domæne.

Hvornår udfases mail.protection.outlook.com?

Microsofts udmelding (MC1048624) peger på, at ændringen gælder for nye domæner fra 1. juli 2026. Eksisterende domæner kan fortsat virke, men jeres onboarding-proces og scripts skal kunne håndtere begge scenarier.

Påvirker MX-ændringen mine nuværende domæner i Microsoft 365?

Som tommelfingerregel: nej, ikke på dag 1. Risikoen ligger i, at I ved næste domæne (opkøb/brand) genbruger en gammel opskrift og derfor får forkert MX. Prioritér derfor at opdatere playbooks nu, selv hvis alt “virker i dag”.

Hvorfor kan vi ikke modtage mails på et nyt M365-domæne?

De typiske årsager er: forkert MX-hostname, manglende domæne-verifikation, eller at DNS er lagt i forkert zone/host. Start med at sammenligne jeres DNS-records med Microsofts aktuelle anbefalinger for netop det domæne, og test mailflow fra en ekstern afsender.

Hvad er forskellen på DMARC og SMTP DANE?

DMARC hjælper mod spoofing og styrer, hvad modtageren skal gøre, hvis SPF/DKIM ikke matcher. SMTP DANE handler om transportlaget: at TLS-forbindelsen til jeres mailmodtager ikke kan omdirigeres eller nedgraderes uden at det opdages, fordi DNSSEC bruges til at validere oplysningerne. De løser to forskellige problemer og kan med fordel bruges sammen.

Skal vi aktivere DNSSEC for at bruge DANE i Microsoft 365?

Ja: DANE bygger på DNSSEC. Hvis jeres DNS-udbyder eller registrator ikke understøtter DNSSEC korrekt (inkl. key rollover og DS-record), så får I ikke den fulde effekt. Beslutningsregel: hvis I ikke kan slå DNSSEC til uden manuel “brandslukning”, så bør I først standardisere DNS-platform og ansvar.

Hvad betyder MC1048624 for vores virksomhed?

Det betyder, at nye domæner i Microsoft 365 kan kræve andre DNS-records end jeres nuværende. Jeres risiko er mest operationel: fejl i onboarding, forsinket mailflow og ekstra timer på fejlfinding. Løsningen er proces + automation, der henter de rigtige records, samt en plan for DNSSEC/DANE hvis I vil hæve sikkerhedsniveauet.

Sådan kommer I i mål (uden at overbygge)

1. Auditér jeres domæne-onboarding (scripts, runbooks, mail-skabeloner) for hardcodede MX- og autodiscover-værdier.
2. Fastlæg ejerskab af DNS: hvem kan ændre, hvem godkender, hvem tester, og hvem har rollback.
3. Standardisér “source of truth” for records (Microsoft portal/Graph) og gem output i jeres change-dokumentation.
4. Test et nyt domæne i et kontrolleret vindue: mailflow ind/ud, SPF/DKIM/DMARC, og log evt. afvigelser.
5. Beslut om DNSSEC + SMTP DANE er en del af jeres baseline, især hvis I arbejder mod NIS2/ISO.
6. Udrul en fast tjekliste (tabellen) som krav, hver gang I tilføjer domæner ved M&A eller nye brands.

Kilder: Microsoft Message Center (MC1048624), Microsoft Tech Community (Inbound SMTP DANE GA), Microsoft Learn (How SMTP DANE works), NIST SP 800-177 Rev. 1, CISA CEG (Securing Web and Email Servers), ENISA (Securing DNS), Thomas Juhl Olesen (analyse), Brandaris (implementeringsguide).