SPF, DKIM e DMARC per Microsoft 365.
Microsoft 365 (Exchange Online) non autentica il tuo dominio con un'unica procedura guidata, come fa un ESP in hosting: divide il lavoro tra due console. SPF è un vero include condiviso (include:spf.protection.outlook.com) da unire all'unico record TXT SPF del tuo dominio, mentre DKIM è composto da due record CNAME di “selettore” che pubblichi e poi attivi nel portale Microsoft Defender. DMARC è un terzo record, separato, che Microsoft non crea mai per te. Allineali tutti e tre ed Exchange Online invierà posta pienamente autenticata con il tuo dominio, invece di appoggiarsi alla firma predefinita di onmicrosoft.com.
Perché autenticare Microsoft 365?
Autenticare un dominio Microsoft 365 decide se le tue email raggiungono la posta in arrivo, e M365 ha una trappola specifica che rompe DMARC senza dare nell'occhio. Da febbraio 2024 Gmail e Yahoo richiedono a ogni mittente di grandi volumi (circa 5.000+ messaggi al giorno) di superare SPF, DKIM e DMARC con allineamento, e da maggio 2025 Microsoft stessa ha iniziato ad applicare le stesse regole alla posta ad alto volume diretta a Outlook.com/Hotmail/Live: quindi anche la posta aziendale che arriva nelle caselle consumer di Microsoft deve essere autenticata. L'insidia esclusiva di M365: di base, Exchange Online firma con DKIM la posta in uscita usando il dominio onmicrosoft.com del tenant (d=contoso.onmicrosoft.com), che non si allinea al tuo dominio From personalizzato (contoso.com). L'SPF di Microsoft invece si allinea, quindi la posta diretta può superare DMARC di misura grazie al solo SPF; ma appena un messaggio viene inoltrato (mailing list, regole .forward, gateway di filtraggio) SPF si rompe e, poiché DKIM firma con il dominio sbagliato, non resta nulla a sostenere DMARC. Configurare DKIM sul dominio personalizzato è ciò che chiude questa falla e fa confluire sul tuo dominio la reputazione di invio che costruisci.
Come funziona davvero SPF con Microsoft 365
Microsoft 365 è un vero provider a “include”: a differenza degli ESP con delega tramite CNAME (Mailchimp, Klaviyo) o dei mittenti per account (Amazon SES), c'è un solo vero include condiviso da aggiungere al tuo SPF radice: include:spf.protection.outlook.com. Pubblicalo dentro un unico record TXT SPF sul dominio, ad esempio v=spf1 include:spf.protection.outlook.com -all. Due cose rendono l'SPF di M365 insolitamente ben fatto. Primo, l'include si risolve in un record piatto che contiene solo intervalli ip4:/ip6: e il suo -all, senza include annidati, quindi costa UNA SOLA delle tue 10 ricerche DNS SPF (un mito diffuso parla di 2-3; il record pubblicato non ha sotto-include). Secondo, poiché Exchange Online usa di default il tuo dominio come SMTP MAIL FROM (busta/Return-Path), SPF si ALLINEA davvero al tuo dominio, quindi l'include di M365 contribuisce da solo a superare DMARC: una cosa che non possono fare gli ESP con un proprio Return-Path. Microsoft raccomanda esplicitamente il qualificatore -all (hard fail) perché si aspetta che tu usi anche DKIM e DMARC. Due avvertenze: fanno eccezione solo i cloud sovrani/governativi (GCC High e DoD usano include:spf.protection.office365.us, 21Vianet in Cina usa include:spf.protection.partner.outlook.cn), e ogni sottodominio di invio ha bisogno di un proprio record SPF (il record di contoso.com non copre marketing.contoso.com).
Passo dopo passo
- 1
Conferma il dominio e trova i suoi record DNS
Accedi ad admin.microsoft.com, vai su Settings → Domains, seleziona il tuo dominio e apri la scheda DNS records. Se hai delegato i nameserver a Microsoft, potrebbe aver già pubblicato SPF e l'MX (yourdomain-com.mail.protection.outlook.com). Se il tuo DNS è presso un registrar o un provider, tieni presente che qui M365 non offre controlli per SPF o DMARC: quei record li aggiungi tu presso il tuo provider DNS.
- 2
Pubblica o unisci il record SPF
Presso il tuo provider DNS crea UN SOLO record TXT sul dominio radice (host @): v=spf1 include:spf.protection.outlook.com -all. Se esiste già un record v=spf1 (Google Workspace, uno strumento di marketing, ecc.), unisci l'include a quell'unico record: non aggiungere mai un secondo TXT SPF. Microsoft raccomanda di terminare con -all (hard fail). GCC High/DoD usano spf.protection.office365.us; 21Vianet usa spf.protection.partner.outlook.cn.
- 3
Apri la scheda DKIM
Il DKIM personalizzato NON si trova nell'interfaccia di amministrazione di M365. Vai su security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings, poi seleziona la scheda DKIM.
- 4
Visualizza i due valori CNAME
Fai clic sul tuo dominio personalizzato. Un dominio mai configurato mostra Status = NoDKIMKeys e l'interruttore su Disabled. Sposta l'interruttore su Enable: poiché i CNAME non esistono ancora, si apre una finestra “Client error” e Status passa a CnameMissing. È previsto, non è un errore: la sezione “Publish CNAMEs” ora mostra le destinazioni CNAME esatte di selector1 e selector2. Copiale (oppure esegui Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME,Selector2CNAME in Exchange Online PowerShell).
- 5
Aggiungi i due CNAME dei selettori DKIM
Crea selector1._domainkey e selector2._domainkey come record CNAME che puntano alle destinazioni esatte fornite dal portale. I domini più recenti (il formato introdotto da Microsoft a maggio 2025) ricevono destinazioni come selector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft (<char>, es. n o r, è un carattere di partizione assegnato da Microsoft); i domini configurati prima ricevono selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com. Usa il formato che mostra il portale: i due formati non si possono mescolare sullo stesso selettore. Non trasformarli in TXT.
- 6
Imposta DKIM su Enabled
Dopo la propagazione dei CNAME (di solito pochi minuti, fino a 48 ore), torna alla scheda DKIM, seleziona il dominio e sposta di nuovo l'interruttore su Enable. Status passa a Valid e diventa disponibile “Rotate DKIM keys”. Da questo momento M365 firma con d=yourdomain.com invece del predefinito onmicrosoft.com, quindi DKIM si allinea.
- 7
Aggiungi il record DMARC
M365 non crea DMARC. Aggiungi un record TXT sull'host _dmarc: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Parti da p=none, la modalità di monitoraggio “take no action” di Microsoft, così non cambia nulla mentre confermi che SPF e DKIM si allineano; poi potrai inasprire la policy.
- 8
Invia un'email di prova e leggi le intestazioni
Da una casella del dominio, inviati un'email su Gmail, apri il messaggio e scegli ⋮ → Show original. Devi vedere SPF: PASS con il tuo dominio, DKIM: PASS con d=yourdomain.com (NON onmicrosoft.com) e DMARC: PASS. Poi conferma che ogni record si risolva con un check-up del dominio.
Record da aggiungere
Microsoft 365 genera i valori esatti nella sua procedura guidata di configurazione: questi mostrano la struttura di ciò che aggiungerai presso il tuo provider DNS.
| Tipo | Host | Valore |
|---|---|---|
| TXT | @ | v=spf1 include:spf.protection.outlook.com -allSPF radice: tieni esattamente UN record SPF; unisci questo include se hai già un record v=spf1. Costa ~1 ricerca DNS. |
| CNAME | selector1._domainkey | selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftChiave DKIM 1 (ruotata in automatico). Valore di esempio: copia la destinazione esatta dal portale Defender; i domini creati prima di maggio 2025 terminano con .onmicrosoft.com invece di .n-v1.dkim.mail.microsoft. |
| CNAME | selector2._domainkey | selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftChiave DKIM 2 (il secondo selettore permette a Microsoft di ruotare le chiavi). Valore di esempio: usa il valore esatto del portale. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comQuesto lo aggiungi tu: M365 non lo crea mai. Uno per dominio; parti da p=none. |
| MX | @ | contoso-com.mail.protection.outlook.comInstrada la posta in entrata verso Exchange Online (priorità 0). Non è un record di autenticazione, ma fa parte della configurazione di M365; i punti del tuo dominio diventano trattini. |
Tieni esattamente un record TXT SPF (v=spf1) sul dominio radice e unisci al suo interno tutti i mittenti. Avere due record SPF è di per sé un errore.
Il limite di 10 ricerche DNS
SPF ha un tetto fisso di 10 ricerche DNS: se lo superi, restituisce un permerror e smette di essere valido ovunque. Ecco quanto consuma di questo budget la configurazione di Microsoft 365.
Microsoft 365 occupa 1 delle tue 10 ricerche; i meccanismi ip4: e ip6: non consumano ricerche.
DKIM
DKIM in Microsoft 365 è la parte che molti sbagliano, perché M365 “firma già” la posta prima che tu faccia qualsiasi cosa, solo che lo fa con il dominio sbagliato. Di default Exchange Online firma con DKIM la posta in uscita usando il dominio onmicrosoft.com iniziale del tenant (d=contoso.onmicrosoft.com). Quella firma è valida, ma non si allinea al tuo dominio From personalizzato, quindi non serve a nulla per DMARC su contoso.com. Per risolvere devi attivare DKIM sul dominio personalizzato: due record CNAME, selector1._domainkey e selector2._domainkey, che delegano le chiavi pubbliche a Microsoft. Poiché sono CNAME (non record TXT da incollare), Microsoft conserva le chiavi private e usa i due selettori per ruotare le chiavi in automatico, senza che tu debba più toccare il DNS. Il formato della destinazione è cambiato a maggio 2025: i domini personalizzati più recenti ricevono selector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft (<char>, es. n o r, è un carattere di partizione assegnato da Microsoft), mentre i domini configurati prima di allora usano ancora selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com. Il portale (o Get-DkimSigningConfig in Exchange Online PowerShell) mostra esattamente quale è assegnato al tuo tenant, e i due formati non possono coesistere per lo stesso selettore. La procedura: visualizza i CNAME nel portale Defender (Email authentication settings → DKIM), pubblicali entrambi presso il tuo provider DNS, attendi la propagazione, poi porta l'interruttore DKIM del dominio su Enabled, così che Status mostri Valid. Le chiavi sono di default a 1024 bit; quelle a 2048 bit sono disponibili con New-DkimSigningConfig (con -KeySize 2048). Solo dopo che l'interruttore è su Enabled M365 firma con d=yourdomain.com e DKIM inizia ad allinearsi.
DMARC
DMARC è un record TXT di policy, separato, sul tuo dominio: Microsoft 365 non lo crea, devi aggiungerlo tu presso il tuo provider DNS. Pubblicalo su _dmarc.yourdomain.com partendo da v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none è la modalità di monitoraggio “take no action” raccomandata da Microsoft: non cambia nulla nel recapito mentre controlli nei report aggregati (rua) che M365 (e ogni altro mittente) superi SPF e DKIM con allineamento al tuo dominio. La linea guida di Microsoft è attivare rapidamente la firma DKIM e DMARC in monitoraggio, poi inasprire gradualmente la policy: passa a p=quarantine e infine a p=reject quando l'allineamento è costante. Tieni esattamente un record _dmarc per l'intero dominio organizzativo; i sottodomini ereditano automaticamente la policy del dominio padre (puoi sovrascriverla per un sottodominio specifico con un suo record _dmarc o con il tag sp=). Poiché l'SPF di M365 si allinea e, dopo aver configurato il DKIM personalizzato, si allinea anche DKIM, un dominio M365 configurato correttamente supera DMARC con entrambi i meccanismi: la configurazione robusta che resiste agli inoltri.
Verifica che funzioni davvero
Non fidarti del solo badge “Valid” del portale Defender: controlla su un messaggio reale. Inviati un'email di prova da una casella del dominio, aprila in Gmail e scegli ⋮ → Show original: devi vedere SPF: PASS, DKIM: PASS con d=yourdomain.com (il segnale rivelatore del problema è d=yourtenant.onmicrosoft.com, che indica che il DKIM personalizzato non è ancora attivo) e DMARC: PASS. Nel portale Defender la scheda DKIM deve mostrare Status = Valid e Toggle = Enabled per il dominio. Poi analizza il tuo dominio con il check-up del dominio di Qualisend per confermare che SPF, entrambi i CNAME dei selettori DKIM e il record DMARC si risolvano correttamente e, quando iniziano ad arrivare i report aggregati DMARC, caricane uno nell'analizzatore di report DMARC: Outlook.com / Exchange Online dovrebbe comparire come sorgente allineata che supera i controlli.
Insidie comuni
- Copertura
La trappola n. 1 di M365: finché non attivi DKIM sul dominio personalizzato, la posta è firmata come d=yourtenant.onmicrosoft.com, che NON si allinea, quindi DKIM non aiuta DMARC e DMARC si rompe appena un messaggio viene inoltrato. Il solo SPF non basta.
- Configurazione DNS
La finestra “Client error” e lo stato CnameMissing che ottieni la prima volta che sposti l'interruttore DKIM su Enable sono previsti, non sono un bug: è così che il portale mostra i valori CNAME. Pubblica i due CNAME, poi torna e sposta di nuovo l'interruttore su Enable.
- Configurazione DNS
Le destinazioni dei CNAME DKIM sono cambiate a maggio 2025: i domini personalizzati configurati da allora puntano a <tenant>.<char>-v1.dkim.mail.microsoft, quelli più vecchi a <tenant>.onmicrosoft.com. Copia la destinazione esatta dal portale Defender (o da Get-DkimSigningConfig): il vecchio e il nuovo formato non si possono mescolare sullo stesso selettore.
- Fa fallire l'autenticazione
Tieni esattamente UN record TXT SPF sul dominio. Se invii già tramite Google Workspace, SendGrid, ecc., unisci include:spf.protection.outlook.com a quell'unico record: due record TXT SPF sono di per sé un PermError.
- Copertura
M365 attivato tramite GoDaddy o IONOS arriva spesso con un SPF predefinito include:secureserver.net, che NON autorizza le caselle Exchange Online. Deve risolversi in include:spf.protection.outlook.com.
- Configurazione DNS
I record DKIM di M365 sono CNAME, quindi se il tuo DNS è dietro Cloudflare imposta ogni record di selettore su “DNS only” (nuvola grigia): un CNAME con proxy attivo (nuvola arancione) non si risolve nell'host di Microsoft e l'attivazione di DKIM fallisce.
- Configurazione DNS
Attenzione agli errori di sintassi SPF segnalati da Microsoft: nessun punto finale (include:spf.protection.outlook.com. è sbagliato), i due punti e non un segno di uguale dopo “include”, e nessuno spazio dopo i due punti. Molti registrar aggiungono inoltre automaticamente il tuo dominio ai campi CNAME/host, duplicandolo.
- Copertura
Ogni sottodominio di invio ha bisogno di un proprio SPF (e di un proprio DKIM). Il record su contoso.com non copre marketing.contoso.com: gli strumenti di marketing o per grandi volumi che inviano da un sottodominio hanno bisogno lì di SPF, DKIM e, di solito, di una propria gestione DMARC.
Crea il tuo record SPF
Microsoft 365 è già preselezionato qui sotto. Aggiungi le altre piattaforme con cui invii, poi pubblica l'unico record unificato.
Server propri del dominio
Autorizza il dominio stesso, se invia posta direttamente (non tramite una delle piattaforme sopra).
Altri mittenti e IP
Tutto ciò che non è nella lista: l'host SPF di un altro provider o indirizzi IP specifici.
Aggiungiamo noi il prefisso include:. Inserisci l'hostname indicato nella documentazione del provider.
Policy per tutti gli altri
Cosa devono fare i server riceventi con la posta proveniente da server non elencati sopra (il meccanismo all).
- Pubblicalo come record TXT sul dominio radice: host @ (il dominio senza prefissi), come valore l'intera stringa qui sopra.
- Tieni un solo record SPF per dominio. Unisci tutte le fonti di invio in quest'unica riga. Un secondo record TXT che inizia con v=spf1 li rende entrambi non validi.
- Resta entro le 10 ricerche DNS. Contano come ricerche include:, a e mx, e un include può innescarne altre al suo interno; ip4: e ip6: sono gratuiti.
Autenticazione pubblicata? Il passo successivo è inviare a una lista pulita e verificata.
Verifica una listaSPF per Microsoft 365: domande frequenti
Letture correlate
Altri provider: Workspace e caselle
- Microsoft 365 (GoDaddy / IONOS)
- Migadu
- Namecheap Private Email
- Proton Mail
- Purelymail
- Rackspace Email
- Titan
- Yandex 360
Dopo la pubblicazione, controlla con il check-up del dominio che tutti i record vengano risolti correttamente, poi scopri con l'analizzatore di report DMARC chi invia a tuo nome. Sfoglia tutte le fonti di invio nel generatore. L'autenticazione, però, è solo metà della deliverability: un IP o un dominio di invio in blacklist ti manda comunque nello spam, per quanto pulito sia il tuo SPF, quindi conviene tenere d'occhio le blacklist con il monitoraggio blacklist.
Dominio autenticato: ora mantieni pulita la lista
Superare SPF, DKIM e DMARC ti porta nella posta in arrivo; una lista pulita ti ci fa restare. Verifica la tua: inizia gratis con 100 crediti, senza carta di credito.