Ogni tenant Microsoft 365 nasce con un dominio iniziale in formato contoso.onmicrosoft.com, generato al momento della sottoscrizione. È funzionante ma non è presentabile: gli indirizzi email e gli UPN degli utenti devono usare il dominio aziendale reale. Aggiungere un dominio personalizzato è quindi la prima attività di configurazione del tenant.
Il percorso operativo nel Microsoft 365 admin center
Il flusso si trova in Settings > Domains > Add domain e segue sempre lo stesso ordine.
1. Verifica della proprietà (record TXT)
Microsoft genera un valore MS=msXXXXXXXX da pubblicare come record TXT sul dominio radice. Finché il record non viene rilevato, il dominio resta in stato Unverified e non è utilizzabile per nessun oggetto. In alternativa si può usare un record MX temporaneo con lo stesso valore, ma il TXT è la scelta standard perché non interferisce con il mail flow esistente.
2. Record di servizio
Verificata la proprietà, si pubblicano i record richiesti dai carichi di lavoro attivati:
| Servizio | Tipo | Host | Valore |
|---|---|---|---|
| Exchange Online (mail flow) | MX | @ |
contoso-com.mail.protection.outlook.com (priorità 0) |
| Autodiscover | CNAME | autodiscover |
autodiscover.outlook.com |
| Anti-spoofing | TXT | @ |
v=spf1 include:spf.protection.outlook.com -all |
| Teams / SIP (scenari legacy e ibridi) | CNAME | sip |
sipdir.online.lync.com |
| Teams / discovery client | CNAME | lyncdiscover |
webdir.online.lync.com |
| Teams / SIP TLS | SRV | _sip._tls |
sipdir.online.lync.com, porta 443 |
| Teams / federazione | SRV | _sipfederationtls._tcp |
sipfed.online.lync.com, porta 5061 |
| Intune / registrazione dispositivi | CNAME | enterpriseregistration |
enterpriseregistration.windows.net |
| Intune / enrollment | CNAME | enterpriseenrollment |
enterpriseenrollment.manage.microsoft.com |
Un solo record SPF TXT per dominio: se esiste già un SPF per altri mittenti, va unito aggiungendo l’include, non duplicato. DKIM e DMARC si configurano dopo, rispettivamente da Microsoft Defender XDR (portale di sicurezza) e con un TXT su _dmarc.
DNS delegato a Microsoft vs DNS presso il registrar
| Aspetto | DNS gestito da Microsoft | DNS presso il registrar |
|---|---|---|
| Configurazione | Il wizard scrive e mantiene i record automaticamente | Ogni record va inserito a mano |
| Prerequisito | Delega dei name server ad Azure DNS (ns1-01.azure-dns.com, ecc.) |
Nessuno |
| Manutenzione | Nuovi record di servizio aggiunti automaticamente all’attivazione dei workload | Va monitorata la lista Domains > DNS records per record mancanti |
| Quando sceglierlo | Tenant greenfield, nessun sito o servizio di terze parti sul dominio | Presenza di record A/CNAME per hosting, VPN, servizi esterni |
Per alcuni registrar supportati esiste una connessione diretta: il wizard esegue l’autenticazione al registrar e scrive i record senza cambiare i name server.
Coesistenza con Exchange on-premises
In scenario ibrido l’ordine cambia. Il record MX non va spostato su Exchange Online finché tutte le cassette postali non sono migrate: se lo si sposta troppo presto, la posta destinata a utenti ancora on-premises viene instradata dal cloud e richiede routing di rimbalzo. Analogamente, autodiscover deve continuare a puntare all’ambiente on-premises finché esistono cassette locali, perché Exchange on-premises sa reindirizzare i client verso il cloud tramite l’attributo targetAddress, mentre il contrario non è vero. L’SPF deve includere sia gli IP dei server on-premises sia spf.protection.outlook.com per tutta la durata della coesistenza.
Dominio predefinito e UPN esistenti
Un dominio verificato può essere impostato come default da Domains > seleziona dominio > Set as default. L’operazione richiede solo che il dominio sia verificato e abilitato per Exchange. Il cambio del dominio predefinito non modifica gli UPN già assegnati: incide solo sul suffisso proposto per gli utenti creati successivamente. Per allineare gli utenti esistenti bisogna modificare l’UPN uno per uno, in blocco via Set-MgUser/Set-MsolUser, oppure — in ambiente sincronizzato — cambiare l’attributo in Active Directory on-premises e lasciare che Microsoft Entra Connect propaghi la modifica. Ricordare che un dominio è sincronizzabile solo se verificato in Entra ID, altrimenti gli UPN sincronizzati vengono sostituiti con il suffisso .onmicrosoft.com.
Trappole tipiche d’esame
- Scenario: l’amministratore vuole eliminare
contoso.onmicrosoft.comdopo aver aggiunto il dominio aziendale. → Risposta giusta: non è possibile. Il dominio iniziale è permanente e resta come identificatore del tenant, anche se non è quello predefinito. - Scenario: la rimozione di
fabrikam.comfallisce con errore. → Risposta giusta: esistono ancora oggetti che usano il dominio (UPN utente, gruppi, cassette condivise, indirizzi proxy secondari, app registrate). Vanno riassegnati a un altro dominio prima della rimozione. - Scenario: i record sono stati pubblicati venti minuti fa e il portale segnala ancora “record non trovati”. → Risposta giusta: attendere la propagazione DNS (fino a 72 ore, in base al TTL). Non è un errore di configurazione e non richiede di ricreare i record.
- Scenario: migrazione ibrida in corso, metà delle cassette è ancora on-premises. → Risposta giusta: lasciare MX e autodiscover puntati all’ambiente on-premises; spostarli solo a migrazione completata.
- Scenario: dopo aver aggiunto l’SPF di Microsoft, la posta inviata dal gestionale aziendale finisce in quarantena. → Risposta giusta: esistono due record SPF, oppure il record unico non include il mittente applicativo. Consolidare in un solo TXT con tutti gli
includenecessari.