Koble et domene til Microsoft 365

Et domene kan være registrert og ha nettside hos én leverandør, mens Microsoft 365 håndterer e-post. Du trenger ikke flytte domenet til Microsoft. Du må verifisere at virksomheten kontrollerer det og publisere DNS-postene som gjelder for akkurat deres Microsoft 365-miljø.

Skill mellom to hendelser:

• Domeneverifisering med TXT gir Microsoft bevis på kontroll, men skal ikke flytte e-posten.
• MX-endring sender ny innkommende e-post for hele domenet til Exchange Online.

Ikke gjør MX-endringen før alle brukere, aliaser, grupper, data og integrasjoner er klare.

Før oppsettet

Du trenger:

• global administrator eller nødvendige delegerte roller i Microsoft 365
• tilgang til autoritativ DNS
• et abonnement som inkluderer Exchange Online for brukerne som skal ha postboks
• liste over postbokser, aliaser, grupper og videresendinger
• liste over nettsider, fakturasystemer, skannere og andre avsendere
• eksport av dagens DNS-sone og registrert TTL
• plan for gammel historikk, klienter og differansekopi
• avtalt endringsvindu, tester og rollback

Hvis domenet allerede mottar e-post, bruk den komplette migreringsplanen sammen med denne DNS-guiden.

Steg 1: legg domenet til før brukerne opprettes

I Microsoft 365 Admin går du til domeneinnstillingene og legger til domenet. Microsoft anbefaler å legge til det egendefinerte domenet før brukerne, slik at kontoene kan få riktig påloggingsnavn og adresse fra starten.

Oppsettveiviseren kan tilby Domain Connect hos støttede DNS-leverandører. Ved manuelt oppsett kopierer du postene fra Admin til DNS selv. Selv med automatikk bør du dokumentere hva som endres og eksportere sonen først.

Microsofts veiledning for egendefinert domene viser gjeldende meny og alternativer.

Steg 2: verifiser med unik TXT-post

TXT er det anbefalte valget når domenet allerede har e-post. Microsoft gir en unik verdi som ligner:

MS=msXXXXXXXX

Publiser posten nøyaktig slik Admin viser:

Kontroller posten fra en ekstern resolver før du trykker på bekreftelse. Denne TXT-posten kan sameksistere med andre TXT-poster. Den skal ikke erstatte SPF.

Microsoft opplyser at verifiseringsposten kan fjernes etter vellykket verifisering. Ikke bruk MX som alternativ verifisering på et domene i drift uten å forstå rutingseffekten.

Steg 3: opprett hele målet

Før mottaket flyttes, opprett og test:

• alle lisensierte postbokser
• e-postaliaser
• distribusjonslister og Microsoft 365-grupper
• delte postbokser og rettigheter
• administratorer med minst nødvendig tilgang
• MFA, betinget tilgang og gjenoppretting etter virksomhetens krav
• ruting, transportregler, tillatelses- og blokkeringslister
• bevaring, arkiv og eDiscovery dersom dette er et krav

Et alias har ikke egen innlogging. En delt postboks er heller ikke det samme som en gruppe. Test Send som, Send på vegne av og medlemskap der funksjonene brukes.

Steg 4: hent de faktiske DNS-verdiene

I Microsoft 365 Admin velger du domenet og DNS-administrasjon. Kopier verdiene for tjenestene dere faktisk skal bruke. Microsofts DNS-veiledning oppgir at e-post vanligvis trenger:

• tenant-spesifikk MX
• Autodiscover CNAME
• SPF som del av den eksisterende TXT-konfigurasjonen
• to tenant-spesifikke DKIM CNAME-poster

Teams, Intune og andre Microsoft-tjenester kan kreve flere CNAME- eller SRV-poster. Ikke kopier alt fra en generell tabell hvis tjenesten ikke er i bruk.

Steg 5: kartlegg alle som sender fra domenet

SPF og DMARC må dekke mer enn Outlook. Registrer:

• Exchange Online
• nettside og kontaktskjema
• regnskaps- og fakturasystem
• CRM, booking og kundeservice
• nyhetsbrev og transaksjonelle tjenester
• printere, skannere og overvåking
• gammel e-postleverandør i overgangsperioden

For hver kilde trenger dere synlig Fra-domene, konvoluttavsender, DKIM-domene, teknisk tjeneste og eier. Ikke bruk SPF-posten alene som inventarliste; noen tjenester autentiserer med et eget returdomenet og DKIM.

Steg 6: bygg én korrekt SPF-post

Når Exchange Online er den eneste avsenderen, viser Microsoft dette eksemplet for vanlig Microsoft 365:

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

Bruk ikke verdien ubetinget. Hvis andre legitime tjenester sender, må de inngå i samme SPF-post eller bruke egne, korrekt justerte underdomener. To separate TXT-poster som starter med v=spf1 gjør SPF ugyldig.

Under en migrering må gammel og ny avsender ofte være autorisert samtidig. -all er riktig først når listen faktisk er uttømmende. Microsofts SPF-veiledning beskriver syntaks og scenarier. Bruk den operative guiden til SPFs grense på ti DNS-oppslag når flere tjenester skal være aktive samtidig.

Fjern gammel leverandør etter at leveringslogger og systemeiere bekrefter at trafikken er avsluttet, ikke samtidig med MX bare fordi mottaket er flyttet.

Steg 7: publiser begge DKIM-selectorene

Microsoft 365 bruker to CNAME-poster for nøkkelrotasjon:

• selector1._domainkey
• selector2._domainkey

Målverdiene er tenant- og domenespesifikke. Microsoft endret formatet for nye egendefinerte domener i mai 2025, og nyere verdier kan inneholde en dynamisk partisjon og dkim.mail.microsoft. Eldre miljøer kan fortsatt bruke mål under onmicrosoft.com.

Derfor skal du ikke konstruere målverdiene fra et eksempel. Hent dem i Admin eller med Get-DkimSigningConfig som beskrevet i Microsofts DKIM-dokumentasjon .

Etter publisering:

1. bekreft begge CNAME-postene eksternt
2. aktiver DKIM for domenet i Microsoft 365
3. send en ekstern testmelding
4. kontroller dkim=pass i meldingshodet
5. kontroller at DKIM-domenet er justert med synlig Fra-domene

To DNS-poster uten aktivert signering er ikke ferdig DKIM-oppsett.

Steg 8: innfør DMARC gradvis

DMARC publiseres som TXT på _dmarc.dittdomene.no. Microsoft anbefaler SPF og DKIM for alle aktive sendende domener før DMARC håndheves, og en gradvis vei mot p=reject.

Et mulig overvåkingspunkt er:

v=DMARC1; p=none; rua=mailto:dmarc@dittdomene.no

Adressen må kunne motta rapporter. p=none gir innsikt, men ber ikke mottakere blokkere feilende post. Analyser rapporter, rett legitime avsendere og øk deretter policy kontrollert. Se Microsofts DMARC-veiledning .

Steg 9: publiser Autodiscover

For vanlig Exchange Online viser Microsoft en CNAME:

Microsoft beskriver posten som valgfri, men sterkt anbefalt for klienter som støtter automatisk konfigurasjon. Manglende CNAME betyr ikke at alle klienter nødvendigvis må settes opp manuelt; moderne klienter kan bruke flere oppdagelsesmekanismer. Test de faktiske Outlook-versjonene, mobile enhetene og identitetsoppsettet deres.

En eksisterende autodiscover-post kan ikke uten videre erstattes tidlig i en hybrid eller trinnvis migrering. Følg den valgte Microsoft-arkitekturen.

Steg 10: forbered MX-bytte tidlig

MX-målet er unikt og ligner:

<token>.mail.protection.outlook.com

Den eksakte verdien og prioriteten skal hentes i Admin. Microsoft viser normalt høyeste prioritet, ofte 0, og støtter MX-TTL under seks timer.

Minst én gammel TTL-periode før endringen:

1. les publisert MX og TTL fra eksternt oppslag
2. senk TTL kontrollert hvis ønskelig og støttet
3. vent hele den tidligere TTL-en
4. bekreft den nye verdien fra autoritative og eksterne oppslag

En endring til 300 sekunder bare 24 timer i forveien er ikke universelt riktig. Har den gamle TTL-en vært lengre, må du vente tilsvarende; tillater leverandøren ikke 300, velger du en annen planlagt verdi.

Steg 11: endre MX i et kontrollert vindu

Ved byttet:

1. bekreft tjenestehelse og at alle målpostbokser finnes
2. ta ny eksport av DNS og mottakere
3. fjern gammel MX og publiser verdien fra Microsoft 365 Admin
4. kontroller autoritative navnetjenere
5. kontroller eksterne resolvere
6. test eksternt mottak til brukere, aliaser, grupper og delte postbokser
7. test utgående post og svar
8. overvåk meldingssporing, avvisninger og autentisering

Microsoft anbefaler én MX som leder til ett e-postsystem. Flere uavhengige leverandører som MX med samme prioritet deler ikke postdata og gir uforutsigbart mottak.

MX påvirker ikke nettsidens A-, AAAA- eller CNAME-poster. Ikke endre web-DNS som en del av e-postbyttet uten en egen grunn.

Steg 12: flytt klienter og applikasjoner

Bruk moderne autentisering der klienten og scenarioet støtter det. Kartlegg separat:

• Outlook-profiler og mobile klienter
• delte postbokser og delegering
• skannere og eldre enheter
• SMTP fra applikasjoner
• systemer som er låst til brukernavn eller gammel server
• sikkerhetsstandarder og eventuelle unntak

Ikke aktiver eldre autentisering bredt for å få én enhet til å virke. Velg en støttet Microsoft-metode for applikasjonens sendebehov, dokumenter minste tilgang og test feilvarsling.

Steg 13: avstem og avvikle gammel tjeneste sist

Hold gammel tjeneste aktiv til:

• minst hele tidligere TTL er passert
• ingen ny legitim post observeres på gammel side
• leveringskøer og forsinkelser er vurdert
• differansekopi er kjørt
• mappe- og meldingskontroll er godkjent
• alle kritiske klienter og avsendere er testet
• rollback-vinduet er avsluttet med beslutning

Det finnes ingen fast 24-, 48- eller 72-timersgrense som alene beviser at flyttingen er ferdig. Bruk meldingssporing, DNS-data, migreringsrapporter og faktisk trafikk.

Etter godkjenning:

• gjenopprett normal TTL
• fjern gamle avsendere fra SPF
• fjern gamle klient- og applikasjonstilganger
• avslutt gammel tjeneste etter eksport og bevaringskrav
• dokumenter administratorer, support og gjenoppretting

Feilsøk med bevis

Bruk Microsofts meldingssporing, fullstendige meldingshoder og autoritative DNS-oppslag. Endre én hypotese om gangen.

Domene hos Vymo, e-post hos Microsoft

Du kan registrere og administrere domenet separat fra Microsoft 365. Et domenekjøp hos Vymo inkluderer ikke Microsoft 365-abonnement, brukerlisenser eller migrering.

Søk etter et ledig domene dersom du starter nytt. Vurderer du Google i stedet, se Google Workspace DNS-guiden . For en eksisterende e-posttjeneste bør migreringsplanen være godkjent før MX endres.