Microsoft 365 / Record DNS email: verificare MX, SPF, DKIM e DMARC

Per le email di Microsoft 365, i record DNS (Domain Name System) indirizzano la posta in arrivo e supportano l'autenticazione della posta in uscita. Un record mail-exchanger (MX) identifica il server ricevente; Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) e Domain-based Message Authentication, Reporting, and Conformance (DMARC) forniscono vari controlli di autenticazione e informazioni sulle policy. Verifica la proprietà del dominio e l'inventario di Microsoft 365 e dei servizi di invio esterni prima di modificare questi record.

Ruoli dei quattro record

La guida Microsoft alla distribuzione dell’autenticazione email spiega come configurare SPF, DKIM e DMARC per i domini personalizzati. Il superamento di SPF o DKIM da solo non garantisce il superamento di DMARC: anche il dominio autenticato deve essere allineato con il dominio del mittente visualizzato.

SPF dichiara quali sorgenti di invio sono autorizzate. Con DKIM, il mittente utilizza una chiave privata per firmare parti del messaggio, e il destinatario utilizza una chiave pubblica pubblicata tramite DNS per verificare la firma. DMARC controlla l'allineamento con il dominio visibile nel campo From e pubblica la politica richiesta per la gestione degli errori e la destinazione dei rapporti. Queste capacità di autenticazione sono incluse nella protezione integrata per le cassette postali cloud; altre funzionalità di Defender possono avere requisiti di licenza aggiuntivi.

SPF controlla il dominio utilizzato in MAIL FROM, l'indirizzo del mittente della busta usato tra i server di posta. Questo può differire dall'indirizzo From mostrato al lettore. Un dominio di firma DKIM può anche appartenere al provider di servizi. Un servizio di gestione delle relazioni con i clienti (CRM) potrebbe quindi superare SPF e DKIM con il dominio del suo provider ma comunque fallire DMARC per il dominio aziendale mostrato in From. Il requisito chiave è che almeno una verifica SPF o DKIM con dominio allineato abbia esito positivo.

L'allineamento può essere rilassato (stesso dominio organizzativo, consentendo sottodomini) o rigoroso (una corrispondenza esatta del nome di dominio). I tag opzionali aspf e adkim controllano separatamente l'allineamento SPF e DKIM; entrambi hanno come valore predefinito l’allineamento rilassato (r). Controllare queste modalità quando un servizio di invio utilizza un sottodominio.

Indagare il percorso di invio prima della configurazione

• Email inviate dai dipendenti da Exchange Online
• Email inviate da sistemi esterni come moduli di contatto del sito web, CRM, servizi di marketing e dispositivi multifunzione
• Servizi di invio che utilizzano sottodomini separatamente
• Percorso attraverso un gateway di sicurezza della posta o server relay

Se la fonte di invio è omessa, le email legittime potrebbero essere rifiutate dopo il rafforzamento di SPF, DKIM e DMARC. Rimuovere le fonti di invio non utilizzate e autenticare i servizi richiesti secondo le linee guida ufficiali del rispettivo provider.

Ordine di verifica in Microsoft 365

1. Nel centro di amministrazione di Microsoft 365, apri il dominio di destinazione in [Impostazioni] → [Domini] e controlla lo stato della configurazione DNS. Usa i valori MX mostrati nella procedura guidata del dominio per quel dominio.

2. Verifica gli attuali record TXT SPF con il provider di hosting DNS. Se è necessario includere sorgenti di invio esterne a Microsoft 365, integrale nei valori esistenti.
3. Nelle impostazioni di autenticazione della posta nel portale Microsoft Defender, controlla lo stato DKIM del dominio personalizzato e i record DNS richiesti. Dopo aver aggiunto i valori suggeriti al DNS, verifica che la firma sia attivata.

4. Introdurre DMARC gradualmente. Analizzare i mittenti reali e i fallimenti di autenticazione tramite i report, quindi decidere sul rafforzamento della politica. Se si aggiunge solo la dichiarazione di politica senza leggere i report, è difficile rilevare i problemi.
5. Inviare un'email di test a un indirizzo esterno all'organizzazione e verificare i risultati e l'allineamento di SPF, DKIM e DMARC nelle intestazioni ricevute. Anche se lo stato del DNS è normale, è necessario testare il percorso di invio reale.

Condizioni in cui l'esempio di SPF può essere usato così com'è

Per un dominio personalizzato di cui gestisci il DNS pubblico, il seguente valore TXT è un esempio base quando Microsoft 365 è l'unico servizio di invio. Questo esempio si applica al servizio commerciale globale di Microsoft; cloud speciali per enti governativi o gestiti in Cina possono richiedere domini inclusi diversi. Usa i valori specifici del servizio nel tuo centro amministrativo e nella documentazione. Se un sito web o un servizio di marketing invia direttamente utilizzando lo stesso dominio, non sostituire la tua policy attuale con questo esempio da solo. Confronta l'assistente dei domini e le linee guida ufficiali di configurazione di ciascun mittente.

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

include si riferisce all'ambito di invio di Microsoft 365 e -all dichiara che le sorgenti di invio non autorizzate dai meccanismi SPF devono essere trattati come errori SPF. Creare due record SPF TXT con lo stesso nome per includere separatamente Microsoft 365 e servizi esterni è una configurazione errata. Riunisci le sorgenti di invio necessarie in un’unica policy SPF e rimuovere i mittenti non necessari. I record TXT per la verifica della proprietà diversi da SPF hanno uno scopo differente e non sono soggetti a rimozione. Selezionare in base agli scenari di invio in Guida all'impostazione SPF di Microsoft.

Quando si combinano i servizi, verificare anche il limite di SPF di 10 lookup DNS durante la valutazione. Anche i meccanismi include annidati contano: meno di 10 provider o voci include non garantisce che la valutazione rimanga entro il limite.

Valori da selezionare durante la configurazione di DKIM e DMARC

Nel portale Defender, apri il dominio personalizzato sotto Posta elettronica e collaborazione → Criteri e regole → Criteri per le minacce → Impostazioni di autenticazione della posta elettronica → DKIM. Genera le chiavi se necessario, quindi inserisci i nomi e destinazioni dei due record CNAME (nome canonico) mostrati nei dettagli del dominio presso il tuo provider DNS. Un record CNAME punta un nome DNS a un altro; in questa configurazione collega il lookup DKIM ai record chiave di Microsoft. Copia i nomi dei selettori e le destinazioni fornite per il tuo tenant invece di costruirli da un vecchio blog. Microsoft ha introdotto un nuovo formato di destinazione per i nuovi domini personalizzati a maggio 2025, mentre i domini esistenti possono mantenere il formato precedente.

Dopo la propagazione del DNS, attiva l'interruttore della firma DKIM per il dominio e controlla se sta firmando. Se il CNAME è mancante, ricontrolla il nome inserito, il provider DNS effettivo e il tempo di rilevamento. Non presumere che la firma sia abilitata solo perché entrambi i record sono salvati. Puoi controllare la procedura per procedere secondo lo stato attuale in procedura ufficiale di configurazione DKIM .

La politica DMARC iniziale può essere impostata come configurazione focalizzata sui report che può analizzare i mittenti legittimi. Di seguito è riportato un esempio usando example.com come dominio di esempio. Pubblica il record TXT su _dmarc per il tuo dominio e sostituisci dmarc@example.com nel valore rua=mailto: con una reale casella di report controllata dalla tua organizzazione. L'indirizzo di esempio non è una destinazione da usare così com'è.

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none è una politica iniziale che non richiede quarantena o rifiuto per i fallimenti DMARC in sé, e non disabilita altri filtri antispam o di sicurezza. Il parametro rua indica la destinazione dei report aggregati. Devi essere pronto a ricevere e analizzare effettivamente a quell'indirizzo, e se usi un indirizzo di servizio di report esterno, devi anche verificare condizioni aggiuntive di approvazione DNS. Dopo aver verificato l'allineamento dei mittenti legittimi e il percorso di consegna, rafforzi la politica ai passaggi quarantine e reject. Le condizioni dettagliate seguono le linee guida di implementazione guida all’implementazione di DMARC.

Verifica i record DNS e l'autenticazione sulle email appena inviate

Invia nuove email a un indirizzo di test per ciascun percorso di invio, come posta dei dipendenti, moduli di richiesta web, CRM, ecc. Sul lato ricezione, apri il messaggio originale e le intestazioni Internet per controllare i risultati SPF, DKIM e DMARC nel campo Authentication-Results generato dal sistema ricevente, e confronta anche il dominio di firma DKIM con il From visualizzato. Controlla i risultati dei messaggi inviati dopo le modifiche: il fatto che i vecchi messaggi fossero regolari non verifica la nuova configurazione.

Se il DNS è normale ma un CRM specifico fallisce, verifica prima il dominio di invio e le impostazioni di firma per quel percorso. Se il corpo firmato cambia o il server di invio è diverso durante il processo di consegna, i risultati possono variare. Il superamento dell'autenticazione non garantisce la consegna in posta in arrivo, e anche reputazione, spam e politiche di contenuto hanno un impatto.

I valori dei record variano a seconda del dominio e del momento della configurazione. Lo scopo di questo articolo non è memorizzare i valori, ma confrontare i valori forniti dal centro di gestione , i valori effettivi nel DNS e i risultati di autenticazione sul lato ricevente. Se ci sono problemi nella ricezione o nell'invio di email, identificare l'ambito dell'impatto in base ai record DNS prima delle modifiche. Se le email legittime sono interessate, confrontare la politica precedente e la configurazione del mittente per ripristinare solo le modifiche problematiche e testare di nuovo. Non eliminare tutti i record SPF, DKIM e DMARC né mantenere una politica DMARC rigorosa senza conoscerne la causa. Nel rapporto, distinguere tra i fallimenti dei mittenti legittimi e invii sospettati di essere contraffatti, e determinare di conseguenza le azioni successive.