Per impostare DMARC per un dominio personalizzato Microsoft 365 , stabilire i percorsi di invio del dominio, configurare il file appropriato SPF policy, abilita il dominio personalizzato DKIM e verificare un risultato allineato sulla posta ricevuta. Pubblicazione di un DMARC registrazione TXT è un passo in quella sequenza.
Questa guida riguarda l'invio di domini personalizzati tramite Microsoft 365 . Confermare l'ambiente cloud Microsoft e qualsiasi disposizione ibrida, di inoltro o di gateway in uscita prima di utilizzare gli esempi. Le applicazioni che inviano all'esterno di Microsoft 365 necessitano di una propria configurazione di autenticazione supportata, anche quando usano lo stesso dominio Da visibile.
Conferma il dominio, l'host DNS e l'ambiente Microsoft
Conferma il dominio personalizzato, il suo host DNS autorevole, l'ambiente Microsoft 365 e l'autorizzazione necessaria per gestire la firma. Salva i file SPF , DKIM e Registri DMARC prima di cambiarli.
Non confondere l'amministrazione DNS pubblica con l'elenco dei domini del tenant. Il registrar può anche essere l'host DNS , ma non è necessario che lo sia. Controlla i server dei nomi delegati prima di modificare una zona.
Elenca ogni percorso che utilizza il dominio. In particolare, distinguere l'invio ordinario Exchange Online dalle applicazioni che utilizzano l'inoltro, l'invio diretto, un altro provider SMTP o un gateway in uscita. Il solo nome del prodotto non identifica il firmatario finale.
Mappa la posta dei dipendenti e la posta delle candidature
Il passaggio a Microsoft 365 non sposta automaticamente l'applicazione di fatturazione, il modulo di contatto del sito Web o la piattaforma di reclutamento. Tali servizi potrebbero comunque visualizzare il tuo dominio durante l'invio tramite un provider diverso.
Richiedi una semplice mappa dei servizi: posta dei dipendenti, posta per le candidature e comunicazioni in outsourcing, con un titolare accanto a ciascun percorso. Richiedi un test dei messaggi ricevuti per flussi critici come la reimpostazione della password e gli avvisi di fatturazione. Il risultato finale è una comunicazione funzionante e responsabile, non uno screenshot di un'impostazione del tenant abilitata.
Configurare il criterio SPF applicabile
L'esempio documentato di Microsoft per un dominio che invia **solo tramite il servizio Microsoft 365 standard o GCC** è:
v=spf1 include:spf.protection.outlook.com -allQuesto è un esempio con ambito, non una sostituzione di una politica di servizio misto esistente. I documenti Microsoft diversi includono domini per GCC High/DoD e per il suo servizio gestito da 21Vianet. Seguire le istruzioni attuali per il proprio ambiente.
Pubblica una policy SPF applicabile al dominio valutato. Se esiste già una policy valida, rivedi e aggiorna tale policy anziché aggiungerne un'altra Registro SPF. Includi solo le autorizzazioni di invio giustificate e controlla il percorso completo delle dipendenze rispetto ai limiti SPF .
Pubblica entrambi i CNAME DKIM generati dal tenant
DKIM con dominio personalizzato Microsoft 365 ne usa due CNAME record. Ottenere i valori esatti dalla configurazione DKIM del portale Defender o da PowerShell Exchange Online . Non creare una destinazione da un vecchio modello di denominazione: Microsoft documenta più di un formato di destinazione e i valori generati possono contenere un componente specifico del tenant.
In una sessione autorizzata di PowerShell Exchange Online , questo controllo di sola lettura recupera le destinazioni configurate:
Get-DkimSigningConfig -Identity example.com | Elenco formati abilitato, Stato, Selector1CNAME, Selector2CNAMESe il dominio non dispone di alcuna configurazione di firma, utilizzare la procedura di configurazione iniziale documentata di Microsoft prima di aspettarsi che tali proprietà esistano. Nel portale Defender, l'area pertinente è Impostazioni di autenticazione email, quindi DKIM .
Pubblica **entrambi** i record CNAME generati, verifica le relative risposte pubbliche e abilita la firma del dominio personalizzato tramite la procedura del tenant supportato. Un record CNAME delega la gestione della chiave di verifica; non è una richiesta di incollare una chiave privata o una chiave TXT inventata.
Controlla attentamente il comportamento dell'editor DNS . Un pannello che aggiunge il nome della zona può trasformare un nome host completamente inserito in un nome duplicato. Conserva il proprietario esatto pubblicato e i valori di destinazione nel record delle modifiche.
Aggiungi la policy DMARC prevista e la destinazione dei report
Se il dominio sta iniziando una distribuzione monitorata, un record illustrativo su _dmarc.example.com È:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comL'esempio presuppone una destinazione del report funzionante nello stesso dominio. Sostituirlo con l'indirizzo approvato e verificare il ritiro. Le destinazioni esterne possono richiedere autorizzazioni di reporting aggiuntive. Non indebolire una politica di applicazione delle norme esistente semplicemente per seguire questo esempio.
Utilizza la guida alla creazione dei record per la sequenza di pubblicazione e verifica e il DMARCbis guida alla preparazione durante la revisione delle impostazioni di implementazione legacy.
Verifica i messaggi dopo il percorso di invio completo
Invia un messaggio controllato a un destinatario esterno separato e controlla lì il messaggio originale. Registra il Da visibile, l'identità valutata da SPF, ogni dominio DKIM d= pertinente e il risultato DMARC attendibile.
Ripeti il test attraverso le applicazioni critiche e qualsiasi gateway in uscita finale. Se il Da visibile è il tuo dominio personalizzato ma l'unica firma di passaggio utilizza un'identità di tenant non correlata, esamina la firma del dominio personalizzato e il percorso effettivo. Se un gateway modifica il contenuto firmato, verifica il risultato dopo quel gateway.
- Controllare: politica SPF ; Prove da conservare: risposta autorevole e percorso di invio valutato
- Controllare: delega DKIM ; Prove da conservare: sia i CNAME esatti che lo stato di configurazione del tenant
- Verifica: firma in tempo reale; Prove da conservare: firma ricevuta e risultato della verifica attendibile
- Controlla: DMARC ; Prove da conservare: un percorso allineato e un contesto politico osservato
- Controllare: copertura aziendale; Prove da conservare: test per le applicazioni effettivamente utilizzate dall'organizzazione
- Registrare l'accettazione e la proprietà continua
Approvare l'implementazione rispetto a un inventario di servizi denominati. Registra l'approvatore della modifica, la proprietà DNS , i risultati del flusso critico e le restanti eccezioni. Lo stato di firma valida di un tenant non dimostra che ogni applicazione esterna sia coperta.
Mantenere esplicito l'ambiente cloud nella documentazione operativa. Un esempio di cloud standard non deve diventare silenziosamente un’istruzione governativa sul cloud. Assegna controlli periodici per servizi abbandonati e selettori delegati, nonché guasti nel traffico corrente.
Conservare la capacità di ripristinare lo stato precedentemente approvato quando una modifica fallisce, preservando le prove dell'incidente. Una revisione finale dovrebbe spiegare i rischi rimanenti di account compromessi e posta dannosa autenticata, piuttosto che promettere che un passaggio DMARC renda sicuro ogni messaggio.
Il pratico takeaway
La configurazione è completa quando i record pubblicati, lo stato di firma del tenant, le identità dei messaggi ricevuti e il percorso di reporting concordano. Conservare l'inventario dei servizi e le eccezioni con il record delle modifiche; costituiscono la base per la successiva modifica dell'applicazione o del gateway.
Separare la prova della posta dei dipendenti da un'eccezione CRM
Il caso scritto M365-01 presuppone che la posta dei dipendenti proveniente da staff@example.org abbia un passaggio attendibile Firma DKIM con d=example.org. Il CRM di fatturazione utilizza billing@example.org , ma la sua unica firma registrata proviene da un dominio di provider non correlato e il risultato SPF è sconosciuto. Le prove inviate tramite posta elettronica dei dipendenti non stabiliscono il risultato CRM e le prove CRM parziali non possono giustificare un verdetto DMARC completo. Il proprietario del CRM deve identificare la propria identità allineata supportata e raccogliere un messaggio esterno controllato prima che il proprietario del dominio valuti l'idoneità all'applicazione. Queste sono identità e risultati fittizi; non si è verificato alcun tenant, modifica DNS o invio di posta.