Migrazione MX Microsoft 365 verso mx.microsoft: DNSSEC automatico, Graph API obbligatoria e azioni da intraprendere prima di luglio 2026
Di CaptainDNS
Pubblicato il 6 marzo 2026
- 1° luglio 2026: Microsoft provisiona i MX dei nuovi Accepted Domain sotto
mx.microsoftanzichémail.protection.outlook.com(MC1048624, posticipato da febbraio 2026) - Se il tuo dominio ha DNSSEC attivo, la catena di fiducia si estende automaticamente al MX sotto
mx.microsoft: DANE diventa possibile senza alcuna azione aggiuntiva - Qualsiasi automazione che costruisce il MX a partire dal pattern
<dominio>.mail.protection.outlook.comsmetterà di funzionare dopo il 1° luglio - La Graph API
serviceConfigurationRecordsdiventa l'unica fonte di verità - I domini esistenti non sono interessati immediatamente, ma Microsoft prevede una migrazione progressiva dopo luglio 2026
- Verifica subito se il tuo dominio è pronto per DNSSEC con un diagnostica DNSSEC : è il prerequisito per beneficiare della protezione DANE
Il 4 aprile 2025, Microsoft ha pubblicato l'annuncio MC1048624: a partire dal 1° luglio 2026, tutti i nuovi Accepted Domain aggiunti a Exchange Online riceveranno i loro record MX sotto il dominio mx.microsoft e non più sotto mail.protection.outlook.com. La data iniziale di febbraio 2026 è stata posticipata a luglio dopo i feedback della community.
Non è un cambiamento cosmetico. Il dominio mail.protection.outlook.com non è firmato DNSSEC. Il TLD .microsoft, invece, lo è end-to-end. Migrando i MX sotto mx.microsoft, Microsoft rimuove il principale ostacolo tecnico all'adozione di DNSSEC e DANE per le email in entrata su Exchange Online. Gli amministratori non devono più attivare manualmente la migrazione del MX.
Per i team IT, l'impatto è duplice. Da un lato, è una buona notizia: DNSSEC "gratuito" se il tuo dominio è già firmato. Dall'altro, qualsiasi automazione basata sul pattern <dominio>.mail.protection.outlook.com smetterà di funzionare. Solo la Graph API serviceConfigurationRecords fornirà il valore MX corretto.
Pubblico di riferimento: amministratori Microsoft 365, MSP che gestiscono tenant multi-dominio, team DevOps con workflow di provisioning DNS automatizzati.
Cosa cambia concretamente il 1° luglio 2026
Prima: mail.protection.outlook.com
Fino ad oggi, quando aggiungi un dominio personalizzato a Exchange Online, Microsoft provisiona il MX con un formato prevedibile:
captaindns.com. 3600 IN MX 0 captaindns-com.mail.protection.outlook.com.
Questo formato permetteva di indovinare il valore MX dal nome di dominio: sostituisci i punti con i trattini, aggiungi .mail.protection.outlook.com. Molte automazioni (script PowerShell, workflow Terraform, strumenti di provisioning MSP) sfruttano questo pattern.
Dopo: mx.microsoft
A partire da luglio 2026, i nuovi Accepted Domain riceveranno un MX con il formato:
captaindns.com. 3600 IN MX 0 captaindns-com.o-v1.mx.microsoft.
Il suffisso o-v1.mx.microsoft non è deducibile dal solo nome di dominio. Il valore esatto va recuperato tramite il centro di amministrazione Exchange o la Graph API.
Timeline dettagliata
| Data | Evento |
|---|---|
| 4 aprile 2025 | Pubblicazione dell'annuncio MC1048624 |
| Febbraio 2026 | Data iniziale prevista (posticipata) |
| 2 febbraio 2026 | Aggiornamento: rinvio a luglio 2026 |
| Inizio luglio 2026 | Inizio del passaggio progressivo |
| Fine luglio 2026 | Tutti i nuovi Accepted Domain sotto mx.microsoft |
| Dopo luglio 2026 | Migrazione progressiva dei domini esistenti (data non comunicata) |
Chi è interessato?
| Situazione | Impatto |
|---|---|
| Dominio esistente, MX già configurato | Nessun impatto immediato. Il MX attuale sotto mail.protection.outlook.com continua a funzionare |
| Nuovo dominio aggiunto dopo luglio 2026 | Il MX sarà sotto mx.microsoft. Le automazioni basate sul vecchio pattern falliranno |
| Automazione di provisioning DNS | Azione richiesta: migrare alla Graph API serviceConfigurationRecords |
| DNSSEC già attivo sul tuo dominio | Bonus: DNSSEC si estende automaticamente al MX, DANE attivabile senza frizione |
Perché questo cambiamento? Il problema DNSSEC di outlook.com
Il dominio outlook.com, e per estensione mail.protection.outlook.com, non è firmato DNSSEC. È una scelta storica di Microsoft: firmare un dominio così massiccio con così tanti sottodomini dinamici pone sfide operative.
Il problema: senza DNSSEC sul MX, DANE è impossibile. Un server mittente vuole verificare il certificato TLS di Exchange Online tramite DANE. Deve poter validare la catena DNSSEC end-to-end, dal MX fino al TLSA. Se il MX punta a un dominio non firmato, la catena è spezzata.
La soluzione di Microsoft: il TLD .microsoft. Questo TLD di marca (brand TLD) è firmato DNSSEC end-to-end. Creando l'infrastruttura mx.microsoft, Microsoft ottiene una zona DNS interamente sotto il suo controllo e firmata, senza i vincoli ereditati da outlook.com.
La catena DNSSEC completa diventa:
root (.) → .microsoft → mx.microsoft → o-v1.mx.microsoft → captaindns-com.o-v1.mx.microsoft
Ogni anello è firmato. I record TLSA pubblicati da Microsoft sotto _25._tcp.captaindns-com.o-v1.mx.microsoft sono verificabili da qualsiasi server mittente compatibile DANE.
Per capire nel dettaglio il funzionamento della catena di fiducia DNSSEC, consulta la nostra guida sulla catena di fiducia DNSSEC.
DNSSEC automatico: cosa ottieni gratuitamente
Il cambiamento MC1048624 ha un effetto collaterale importante: se il tuo dominio è già firmato DNSSEC, benefici automaticamente della protezione DNSSEC end-to-end per le tue email in entrata, senza alcuna azione nel centro di amministrazione Exchange.
Scenario 1: il tuo dominio non ha DNSSEC
Nulla cambia funzionalmente. Il MX punta a mx.microsoft anziché mail.protection.outlook.com, ma la risoluzione DNS funziona normalmente. Niente DANE, niente verifica TLSA : il comportamento è identico a oggi.
Scenario 2: il tuo dominio ha DNSSEC attivo
La magia avviene:
- Il server mittente risolve il MX di
captaindns.com→captaindns-com.o-v1.mx.microsoft - La risposta è firmata DNSSEC (il tuo dominio è firmato,
mx.microsoftè firmato) - Il server richiede il TLSA per
_25._tcp.captaindns-com.o-v1.mx.microsoft - Microsoft pubblica automaticamente i record TLSA corrispondenti ai certificati di Exchange Online
- Il server verifica il certificato TLS tramite DANE : autenticazione del server senza dipendere dalle autorità di certificazione
Risultato: protezione contro gli attacchi man-in-the-middle sul trasporto email, automaticamente. Prima di questo cambiamento, ottenere DANE su Exchange Online richiedeva una procedura manuale di attivazione. Dopo luglio 2026, per i nuovi domini, è trasparente.
La Graph API diventa l'unica fonte di verità
È il punto di azione critico dell'annuncio MC1048624. Microsoft lo dice esplicitamente:
"After July 1, 2026, List serviceConfigurationRecords Graph API will be the only source of truth for your Accepted Domains' MX record value."
Il problema delle automazioni attuali
Molti script di provisioning costruiscono il MX per convenzione:
# PRIMA: pattern prevedibile (SMETTERÀ DI FUNZIONARE dopo luglio 2026)
$domain = "captaindns.com"
$mx = $domain.Replace(".", "-") + ".mail.protection.outlook.com"
# Risultato: captaindns-com.mail.protection.outlook.com
Questo pattern non funziona più con mx.microsoft. Il suffisso può variare e non è deducibile.
La soluzione: serviceConfigurationRecords
# DOPO: usare la Graph API (OBBLIGATORIO dopo luglio 2026)
Connect-MgGraph -Scopes "Domain.Read.All"
$records = Get-MgDomainServiceConfigurationRecord -DomainId "captaindns.com"
$mxRecord = $records | Where-Object \{ $_.RecordType -eq "Mx" \}
$mxValue = $mxRecord.AdditionalProperties.mailExchange
# Risultato: captaindns-com.o-v1.mx.microsoft (valore reale, non dedotto)
L'endpoint REST corrispondente:
GET https://graph.microsoft.com/v1.0/domains/captaindns.com/serviceConfigurationRecords
Authorization: Bearer {token}
La risposta JSON contiene il valore MX esatto nel campo mailExchange dell'oggetto domainDnsMxRecord:
{
"@odata.type": "microsoft.graph.domainDnsMxRecord",
"isOptional": false,
"label": "captaindns.com",
"recordType": "Mx",
"supportedService": "Email",
"ttl": 3600,
"mailExchange": "captaindns-com.o-v1.mx.microsoft",
"preference": 0
}
Permessi richiesti: Domain.Read.All (minimo). L'utente connesso deve avere il ruolo Amministratore nomi di dominio o Lettore globale.
Altri record restituiti dall'API
L'API restituisce anche i CNAME DKIM, l'Autodiscover, l'SPF e i SRV Teams. È l'occasione per migrare tutte le tue automazioni DNS verso questa fonte unica:
| Tipo OData | Record | Campi chiave |
|---|---|---|
domainDnsMxRecord | MX | mailExchange, preference |
domainDnsTxtRecord | TXT (SPF) | text |
domainDnsCnameRecord | CNAME (DKIM, Autodiscover) | canonicalName |
domainDnsSrvRecord | SRV (Teams) | nameTarget, port, priority |
Preparare la transizione: MTA-STS e TLS-RPT
Parallelamente a DNSSEC e DANE, Microsoft raccomanda di implementare MTA-STS e TLS-RPT per una copertura completa della sicurezza del trasporto email.
MTA-STS obbliga i server mittenti a usare TLS per consegnare le email, anche se non supportano DANE. È una rete di sicurezza complementare:
_mta-sts.captaindns.com. 3600 IN TXT "v=STSv1; id=20260306T000000"
TLS-RPT ti invia dei report quando un server mittente non riesce a stabilire una connessione TLS con il tuo dominio:
_smtp._tls.captaindns.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
Per la configurazione dettagliata, consulta le nostre guide: MTA-STS per Microsoft 365 e TLS-RPT completo.
Piano d'azione prima di luglio 2026
- Verificare le tue automazioni: cerca ogni script, workflow Terraform, playbook Ansible o strumento MSP che costruisce un MX a partire dal pattern
mail.protection.outlook.com. È la priorità assoluta - Migrare alla Graph API: sostituisci la costruzione per convenzione con una chiamata a
serviceConfigurationRecords. Testa fin da subito su un dominio di test - Attivare DNSSEC sui tuoi domini: presso il tuo registrar o provider DNS. È il prerequisito per beneficiare di DANE automatico dopo la migrazione
- Verificare la tua configurazione DNSSEC: usa
dig +dnssec captaindns.com SOAper confermare che il flag AD è presente - Implementare MTA-STS e TLS-RPT: completa il dispositivo di sicurezza del trasporto prima della migrazione
- Monitorare gli annunci Microsoft: il MC1048624 è già stato posticipato una volta. Segui gli aggiornamenti nel centro messaggi di Microsoft 365
FAQ
I miei domini esistenti sono interessati da questo cambiamento?
No, non immediatamente. Il MC1048624 riguarda solo i nuovi Accepted Domain aggiunti dopo il 1° luglio 2026. I tuoi domini esistenti conservano il loro MX sotto mail.protection.outlook.com. Tuttavia, Microsoft prevede una migrazione progressiva dei domini esistenti dopo questa data, senza un calendario preciso. È prudente preparare le tue automazioni fin da subito.
Cosa succede se la mia automazione usa ancora il vecchio pattern dopo luglio 2026?
Se aggiungi un nuovo dominio a Exchange Online dopo luglio 2026 e la tua automazione costruisce il MX a partire da mail.protection.outlook.com, il MX sarà errato. Il flusso di posta non funzionerà per quel dominio finché non correggerai il valore MX per farlo corrispondere a quello mostrato nel centro di amministrazione Exchange o restituito dalla Graph API.
Devo attivare DANE manualmente dopo questo cambiamento?
Per i nuovi domini provisionati dopo luglio 2026, se il tuo dominio ha DNSSEC attivo, la catena DNSSEC si estende automaticamente al MX sotto mx.microsoft e Microsoft pubblica i TLSA. Non hai nessuna azione aggiuntiva per il DANE inbound. Per i domini esistenti ancora sotto mail.protection.outlook.com, la procedura manuale rimane necessaria.
Qual è la differenza tra DANE automatico e DANE attivato manualmente?
Il risultato finale è identico: un record TLSA firmato DNSSEC che autentica il certificato TLS di Exchange Online. La differenza sta nel percorso. Con l'attivazione manuale (domini esistenti), devi avviare la migrazione MX tramite PowerShell. Con i nuovi domini dopo luglio 2026, il MX è già sotto mx.microsoft e i TLSA vengono pubblicati automaticamente se DNSSEC è attivo sul tuo dominio.
La Graph API serviceConfigurationRecords è disponibile nei cloud sovrani?
Sì. L'endpoint è disponibile nel cloud globale, US Government L4, US Government L5 (DoD) e 21Vianet (Cina). I permessi richiesti sono identici: Domain.Read.All come minimo.
Come verifico se il mio dominio è pronto per DNSSEC?
Esegui dig +dnssec captaindns.com SOA e verifica che il flag ad (Authenticated Data) compaia nella risposta. Se non è presente, attiva DNSSEC presso il tuo registrar. Consulta la nostra guida all'attivazione DNSSEC per la procedura dettagliata secondo il tuo provider DNS.
Questo cambiamento influisce su SPF, DKIM e DMARC?
No. SPF (include:spf.protection.outlook.com), DKIM (CNAME verso *.onmicrosoft.com) e DMARC non sono interessati. Solo il record MX cambia suffisso. I meccanismi di autenticazione email continuano a funzionare come prima.
Perché Microsoft ha posticipato la data da febbraio a luglio 2026?
Microsoft non ha comunicato una ragione ufficiale. Il rinvio è stato annunciato il 2 febbraio 2026 in un aggiornamento del MC1048624 con la menzione "Thank you for your patience". È probabile che i feedback della community sulla mancanza di preparazione delle automazioni abbiano motivato questo ritardo aggiuntivo.
Scarica le tabelle comparative
Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.
Glossario
- Accepted Domain: dominio personalizzato aggiunto a un tenant Microsoft 365 nel centro di amministrazione Exchange e configurato per ricevere email.
- MC1048624: identificativo dell'annuncio Microsoft nel centro messaggi di Microsoft 365 che descrive la migrazione DNS dei MX verso mx.microsoft.
- serviceConfigurationRecords: endpoint della Microsoft Graph API che restituisce l'elenco dei record DNS necessari per attivare i servizi Microsoft 365 su un determinato dominio.
- Brand TLD: dominio di primo livello corrispondente a un marchio (es:
.microsoft,.google,.amazon), gestito dall'azienda proprietaria e spesso firmato DNSSEC. - DANE (DNS-based Authentication of Named Entities): meccanismo che lega un certificato TLS a un nome di dominio tramite un record TLSA firmato DNSSEC, eliminando la dipendenza dalle autorità di certificazione.
