Configurare DMARC per convalidare il dominio dell'indirizzo From per i mittenti in Microsoft 365

• Si applica a:

  ✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

Consiglio

Sapevi che puoi provare gratuitamente le funzionalità in Microsoft Defender per Office 365 Piano 2? Usa la versione di valutazione Defender per Office 365 di 90 giorni nell'hub delle versioni di valutazione del portale di Microsoft Defender. Informazioni su chi può iscriversi e sulle condizioni di valutazione in Prova Microsoft Defender per Office 365.

DMARC (Domain-based Message Authentication, Reporting and Conformance) è un metodo di autenticazione tramite posta elettronica che consente di convalidare la posta inviata dall'organizzazione di Microsoft 365 per impedire mittenti contraffatti usati nella compromissione della posta elettronica aziendale, ransomware e altri attacchi di phishing.

È possibile abilitare DMARC per un dominio creando un record TXT in DNS. La convalida DMARC di un messaggio di posta elettronica include gli elementi seguenti:

• Verificare che i domini negli indirizzi MAIL FROM e FROM siano allineati: SPF e DKIM non richiedono che i domini negli indirizzi di posta elettronica seguenti siano allineati (corrispondenza):

  • Indirizzo MAIL FROM: indirizzo di posta elettronica usato nella trasmissione del messaggio tra server di posta elettronica SMTP. Questo indirizzo è noto anche come 5321.MailFrom indirizzo, mittente P1 o mittente della busta.
  • Indirizzo da: indirizzo di posta elettronica nel campo intestazione Da visualizzato come mittente del messaggio nei client di posta elettronica. Questo indirizzo è noto anche come 5322.From indirizzo o mittente P2.

  Per altre informazioni su come questi indirizzi di posta elettronica possono essere in domini diversi e usati per lo spoofing, vedere Perché la posta elettronica Internet richiede l'autenticazione.

  • DMARC usa il risultato di SPF per verificare entrambe le condizioni seguenti:

    • Il messaggio proviene da un'origine autorizzata per il dominio usato nell'indirizzo MAIL FROM (requisito di base di SPF).
    • I domini negli indirizzi MAIL FROM e From nel messaggio sono allineati. Questo risultato richiede in modo efficace che le origini valide per il messaggio siano nel dominio Dell'indirizzo.

  • DMARC usa il risultato di DKIM per verificare che il dominio che ha firmato il messaggio (il valore d= in un campo di intestazione DKIM-Signature convalidato dal valore del selettore s= ) sia allineato al dominio nell'indirizzo Da.

  Un messaggio passa DMARC se uno o entrambi i controlli SPF o DKIM descritti vengono superati. Un messaggio ha esito negativo se entrambi i controlli SPF o DKIM descritti hanno esito negativo.

• Criteri DMARC: specifica le operazioni da eseguire con i messaggi che hanno esito negativo in DMARC (rifiuto, quarantena o nessuna istruzione).

• Report DMARC: specifica dove inviare report aggregati (un riepilogo periodico dei risultati DMARC positivi e negativi) e report forensi (noti anche come report di errore; risultati di errore DMARC quasi immediati simili a un report di mancato recapito o a un messaggio di rimbalzo).

Prima di iniziare, ecco cosa è necessario sapere su DMARC in Microsoft 365 in base al dominio di posta elettronica:

• Se si usa solo il dominio MICROSOFT Online Email Routing Address (MOERA) per la posta elettronica (ad esempio, contoso.onmicrosoft.com): sebbene SPF e DKIM siano già configurati per il dominio *.onmicrosoft.com, è necessario creare il record TXT DMARC per il dominio *.onmicrosoft.com nel interfaccia di amministrazione di Microsoft 365. Per istruzioni, vedere questa sezione più avanti in questo articolo. Per altre informazioni sui domini *.onmicrosoft.com, vedere Perché si dispone di un dominio "onmicrosoft.com".

• Se si usano uno o più domini personalizzati per la posta elettronica (ad esempio, contoso.com): se non è già stato fatto, è necessario configurare SPF per tutti i domini e i sottodomini personalizzati usati per la posta elettronica. È anche necessario configurare la firma DKIM usando il dominio o il sottodominio personalizzato in modo che il dominio usato per firmare il messaggio sia allineato al dominio nell'indirizzo Da. Per istruzioni, vedere gli articoli seguenti:

  • Configurazione di SPF per evitare lo spoofing
  • Usare DKIM per convalidare la posta in uscita dal dominio personalizzato

  Successivamente, è anche necessario configurare i record TXT DMARC per i domini personalizzati, come descritto in questo articolo. Sono inoltre disponibili le considerazioni seguenti:

  • Sottodomini:

    • Per i servizi di posta elettronica che non sono sotto il controllo diretto (ad esempio, i servizi di posta elettronica in blocco), è consigliabile usare un sottodominio (ad esempio, marketing.contoso.com) anziché il dominio di posta elettronica principale (ad esempio, contoso.com). Non si vuole che i problemi relativi alla posta inviata da tali servizi di posta elettronica influiscano sulla reputazione della posta inviata dai dipendenti nel dominio di posta elettronica principale. Per altre informazioni sull'aggiunta di sottodomini, vedere È possibile aggiungere sottodomini personalizzati o più domini a Microsoft 365?.
    • A differenza di SPF e DKIM, il record TXT DMARC per un dominio copre automaticamente tutti i sottodomini (inclusi i sottodomini non inesistenti) che non hanno il proprio record TXT DMARC. In altre parole, è possibile interrompere l'ereditarietà di DMARC in un sottodominio creando un record TXT DMARC in tale sottodominio. Tuttavia, ogni sottodominio richiede un record SPF e DKIM per DMARC.

  • Se si possiedono domini registrati ma inutilizzati: se si possiedono domini registrati che non vengono usati per la posta elettronica o altro (noti anche come domini parcheggiati), configurare i record TXT DMARC in tali domini per specificare che nessun messaggio di posta elettronica deve mai provenire da tali domini. Questa direttiva include il dominio *.onmicrosoft.com se non lo si usa per la posta elettronica.

• I controlli DMARC per la posta in ingresso potrebbero richiedere assistenza: se si usa un servizio di posta elettronica che modifica i messaggi in transito prima del recapito in Microsoft 365, è possibile identificare il servizio come sealer ARC attendibile in modo che i messaggi modificati non vengano eseguiti automaticamente i controlli DMARC. Per altre informazioni, vedere la sezione Passaggi successivi alla fine di questo articolo.

Il resto di questo articolo descrive il record TXT DMARC che è necessario creare per i domini in Microsoft 365, il modo migliore per configurare gradualmente e in modo sicuro DMARC per i domini personalizzati in Microsoft 365 e come Microsoft 365 usa DMARC nella posta in ingresso .

Consiglio

Per creare il record TXT DMARC per il dominio *.onmicrosoft.com nel interfaccia di amministrazione di Microsoft 365, vedere questa sezione più avanti in questo articolo.

Non sono disponibili portali di amministrazione o cmdlet di PowerShell in Microsoft 365 per gestire i record TXT DMARC nei domini personalizzati . Si crea invece il record TXT DMARC nel registrar o nel servizio di hosting DNS (spesso la stessa società).

Vengono fornite istruzioni per creare il record TXT di verifica della proprietà del dominio per Microsoft 365 in molti registrar. È possibile usare queste istruzioni come punto di partenza per creare record TXT DMARC. Per altre informazioni, vedere Aggiungere record DNS per connettere il dominio.

Se non si ha familiarità con la configurazione DNS, contattare il registrar e richiedere assistenza.

Sintassi per i record TXT DMARC

I record TXT DMARC sono descritti in modo esaustivo in RFC 7489.

La sintassi di base del record TXT DMARC per un dominio in Microsoft 365 è la seguente:

Nome host: _dmarc
Valore TXT: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

Oppure

Nome host: _dmarc
Valore TXT: v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

Ad esempio:

Nome host: _dmarc
Valore TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

• Il valore _dmarc del nome host è obbligatorio.

• v=DMARC1; identifica il record TXT come record TXT DMARC.

• Criterio DMARC: indica al sistema di posta elettronica di destinazione cosa fare con i messaggi che hanno esito negativo di DMARC, come descritto in precedenza in questo articolo:

  • p=reject: i messaggi devono essere rifiutati. Ciò che accade effettivamente al messaggio dipende dal sistema di posta elettronica di destinazione, ma i messaggi vengono in genere eliminati.
  • p=quarantine: i messaggi devono essere accettati ma contrassegnati. Ciò che accade effettivamente al messaggio dipende dal sistema di posta elettronica di destinazione. Ad esempio, il messaggio potrebbe essere messo in quarantena come posta indesiderata, recapitato alla cartella Posta indesiderata Email o recapitato alla posta in arrivo con un identificatore aggiunto al corpo del soggetto o del messaggio.
  • p=none: nessuna azione suggerita per i messaggi che hanno esito negativo in DMARC. Ciò che accade al messaggio dipende dalle funzionalità di protezione della posta elettronica nel sistema di posta elettronica di destinazione. Questo valore viene usato per il test e l'ottimizzazione dei criteri DMARC , come descritto più avanti in questo articolo.

  Consiglio

  La posta in uscita dai domini in Microsoft 365 che non riescono a controllare DMARC dal servizio di posta elettronica di destinazione viene instradata attraverso il pool di recapito ad alto rischio per i messaggi in uscita se i criteri DMARC per il dominio sono p=reject o p=quarantine. Non è disponibile alcuna sostituzione per questo comportamento.

• Percentuale di messaggi DMARC non riusciti soggetti ai criteri DMARC: indica al sistema di posta elettronica di destinazione quanti messaggi che non riescono DMARC (percentuale) ottengono i criteri DMARC applicati. Ad esempio, pct=100 significa che tutti i messaggi che non riescono DMARC ottengono i criteri DMARC applicati. Per il test e l'ottimizzazione dei criteri DMARC vengono usati valori inferiori a 100, come descritto più avanti in questo articolo. Se non si usa pct=, il valore predefinito è pct=100.

• Report DMARC:

  • URI del report di aggregazione DMARC: il rua=mailto: valore identifica dove inviare il report di aggregazione DMARC. Il report di aggregazione ha le proprietà seguenti:

    • I messaggi di posta elettronica che contengono il report di aggregazione vengono in genere inviati una volta al giorno (il report contiene i risultati DMARC del giorno precedente). La riga Oggetto contiene il dominio di destinazione che ha inviato il report (Submitter) e il dominio di origine per i risultati DMARC (Dominio report).
    • I dati DMARC si trova in un allegato di posta elettronica XML probabilmente compresso da GZIP. Lo schema XML è definito nell'Appendice C della RFC 7489. Il report contiene le informazioni seguenti:
      • Indirizzi IP di server o servizi che inviano messaggi di posta elettronica usando il dominio.
      • Indica se i server o i servizi passano o non riescono l'autenticazione DMARC.
      • Azioni eseguite da DMARC sulla posta elettronica che non esegue l'autenticazione DMARC (in base ai criteri DMARC).

    Consiglio

    Le informazioni nel report di aggregazione possono essere vaste e difficili da analizzare. Per comprendere meglio i dati, è possibile usare le opzioni seguenti per la creazione di report DMARC:

    • Creare l'automazione usando PowerShell o Microsoft Power BI.
    • Usare un servizio esterno. Per un elenco di servizi, cercare DMARC nel catalogo MISA (Microsoft Intelligent Security Association) all'indirizzo https://www.microsoft.com/misapartnercatalog. DMARC Reporting Services descrive tutti i valori personalizzati necessari nel record TXT DMARC.

  • URI del report forense DMARC: il ruf=mailto: valore identifica dove inviare il report forense DMARC (noto anche come report degli errori DMARC). Il report viene generato e inviato immediatamente dopo un errore DMARC, ad esempio un report di mancato recapito (noto anche come rapporto di mancato recapito o messaggio di mancato recapito).

  Consiglio

  È consigliabile esaminare regolarmente i report di aggregazione DMARC per monitorare la provenienza della posta elettronica dai domini e verificare la presenza di errori DMARC non intenzionali (falsi positivi).

  I singoli sistemi di posta elettronica di destinazione sono responsabili dell'invio di report DMARC all'utente. La quantità e la varietà di report DMARC variano nello stesso modo in cui il volume e la varietà di messaggi inviati dall'organizzazione variano. Ad esempio, è previsto un volume di posta inferiore durante le festività e un volume di posta superiore durante gli eventi dell'organizzazione. È consigliabile designare persone specifiche per monitorare i report DMARC e usare una cassetta postale specifica o un gruppo di Microsoft 365 per ricevere i report DMARC (non recapitare i report alla cassetta postale di un utente).

Per altre informazioni su DMARC, usare le risorse seguenti:

• La serie di training DMARC di M³AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
• Informazioni all'indirizzo DMARC.org.

Usare il interfaccia di amministrazione di Microsoft 365 per aggiungere record TXT DMARC per i domini *.onmicrosoft.com in Microsoft 365

1. Nella interfaccia di amministrazione di Microsoft 365 in https://admin.microsoft.comselezionare Mostra tutti i>dominidelle impostazioni>. In alternativa, per passare direttamente alla pagina Domini , usare https://admin.microsoft.com/Adminportal/Home#/Domains.

2. Nella pagina Domini selezionare il dominio *.onmicrosoft.com dall'elenco facendo clic in un punto qualsiasi della riga diversa dalla casella di controllo accanto al nome di dominio.

3. Nella pagina dei dettagli del dominio visualizzata selezionare la scheda Record DNS .

4. Nella scheda Record DNS selezionare Aggiungi record.

5. Nel riquadro a comparsa Aggiungi record DNS personalizzato visualizzato configurare le impostazioni seguenti:

   • Tipo: verificare che l'opzione TXT (Text) sia selezionata.

   • NOME TXT: immettere _dmarc.

   • VALORE TXT: immettere v=DMARC1; p=reject.

     Consiglio

     Per specificare le destinazioni per i report DMARC Aggregate e DMARC Forensic, usare la sintassi v=DMARC1; p=reject rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. Ad esempio, v=DMARC1; p=reject rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

     I fornitori di report DMARC nel catalogo https://www.microsoft.com/misapartnercatalog MISA in semplificano la visualizzazione e l'interpretazione dei risultati di DMARC.

   • TTL: verificare che sia selezionata 1 ora .

   Al termine del riquadro a comparsa Aggiungi un record DNS personalizzato , selezionare Salva.

Configurare DMARC per i domini personalizzati attivi in Microsoft 365

Consiglio

Come accennato in precedenza in questo articolo, è necessario creare record TXT SPF e configurare la firma DKIM per tutti i domini personalizzati e i sottodomini usati per inviare messaggi di posta elettronica in Microsoft 365 prima di configurare DMARC per domini personalizzati o sottodomini.

È consigliabile un approccio graduale alla configurazione di DMARC per i domini di Microsoft 365. L'obiettivo è quello di ottenere un p=reject criterio DMARC per tutti i domini e sottodomini personalizzati, ma è necessario testare e verificare lungo il percorso per impedire ai sistemi di posta elettronica di destinazione di rifiutare la posta corretta a causa di errori DMARC non intenzionali.

Il piano di implementazione di DMARC deve seguire questa procedura. Iniziare con un dominio o un sottodominio con un volume di posta basso e/o un numero inferiore di potenziali origini di posta elettronica (meno probabilità che la posta legittima proveniente da origini sconosciute venga bloccata):

1. Iniziare con un criterio DMARC di p=none e monitorare i risultati per il dominio. Ad esempio:

   Record TXT DMARC per marketing.contoso.com:

   Nome host: _dmarc
   Valore TXT: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   I report DMARC Aggregate e DMARC Forensic forniscono i numeri e le origini dei messaggi che superano e non superano i controlli DMARC. È possibile vedere la quantità di traffico di posta elettronica legittimo che è o non è coperto da DMARC e risolvere eventuali problemi. È anche possibile vedere quanti messaggi fraudolenti vengono inviati e da dove vengono inviati.

2. Aumentare i criteri DMARC per p=quarantine e monitorare i risultati per il dominio.

   Dopo un tempo sufficiente per monitorare gli effetti di p=none, è possibile aumentare i criteri DMARC a p=quarantine per il dominio. Ad esempio:

   Record TXT DMARC per marketing.contoso.com:

   Nome host: _dmarc
   Valore TXT: v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   È anche possibile usare il pct= valore per influire gradualmente su più messaggi e verificare i risultati. Ad esempio, è possibile spostarsi negli incrementi seguenti:

   • pct=10
   • pct=25
   • pct=50
   • pct=75
   • pct=100

3. Aumentare i criteri DMARC per p=reject e monitorare i risultati per il dominio.

   Dopo un tempo sufficiente per monitorare gli effetti di p=quarantine, è possibile aumentare i criteri DMARC a p=reject per il dominio. Ad esempio:

   Record TXT DMARC per marketing.contoso.com:

   Nome host: _dmarc
   Valore TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   È anche possibile usare il pct= valore per influire gradualmente su più messaggi e verificare i risultati.

4. Ripetere i tre passaggi precedenti per i sottodomini rimanenti di volume e/o complessità crescenti, salvando il dominio padre per ultimo.

   Consiglio

   Bloccare la posta elettronica legittima in qualsiasi volume significativo è inaccettabile per gli utenti, ma è quasi inevitabile che si otterranno alcuni falsi positivi. Gestire lentamente e metodicamente i problemi che vengono rivelati nella creazione di report DMARC. I fornitori di report DMARC nel catalogo https://www.microsoft.com/misapartnercatalog MISA in semplificano la visualizzazione e l'interpretazione dei risultati di DMARC.

5. Come descritto in precedenza, i sottodomini ereditano le impostazioni del record TXT DMARC del dominio padre, che possono essere sostituite da un record TXT DMARC separato nel sottodominio. Al termine della configurazione di DMARC in un dominio e in tutti i sottodomini e le impostazioni DMARC sono effettivamente identiche per il dominio padre e tutti i sottodomini, è possibile eliminare i record TXT DMARC nei sottodomini e basarsi sul singolo record TXT DMARC nel dominio padre.

Record TXT DMARC per i domini parcheggiati in Microsoft 365

Consiglio

Il record TXT SPF consigliato per i domini parcheggiati che non inviano messaggi di posta elettronica è descritto in Record TXT SPF per i domini personalizzati in Microsoft 365. Come descritto in Configurare DKIM per firmare la posta elettronica dal dominio di Microsoft 365, non è consigliabile usare record CNAME DKIM per i domini parcheggiati.

1. Se sono stati registrati domini da cui nessuno su Internet dovrebbe aspettarsi di ricevere messaggi di posta elettronica, creare il record TXT DMARC seguente nel registrar per il dominio:

   Nome host: _dmarc
   Valore TXT: v=DMARC1; p=reject;

   • Il pct= valore non è incluso, perché il valore predefinito è pct=100.
   • I rua=mailto: valori e ruf=mailto: non sono probabilmente necessari in questo scenario, perché nessun messaggio di posta valido deve mai provenire da mittenti nel dominio.

2. Se non si usa il dominio *.onmicrosoft.com per inviare messaggi di posta elettronica, è anche necessario aggiungere il record TXT DMARC per il dominio *.onmicrosoft.com.

DMARC per la posta in ingresso in Microsoft 365

• I controlli DMARC sulla posta in arrivo in Microsoft 365 sono interessati dalle funzionalità seguenti in Exchange Online Protection (EOP):

  • Indica se l'intelligence per lo spoofing è abilitata o disabilitata nei criteri anti-phishing che hanno controllato il messaggio. La disabilitazione dell'intelligence spoofing disabilita la protezione implicita dallo spoofing solo dai controlli di autenticazione composita .
  • Indica se i criteri di record Honor DMARC quando il messaggio viene rilevato come impostazione spoof sono abilitati o disabilitati nei criteri anti-phishing che hanno controllato il messaggio e le azioni specificate in base ai criteri DMARC del dominio di origine (p=quarantineo p=reject nel record TXT DMARC).

  Per informazioni complete, vedere Protezione spoofing e criteri DMARC del mittente.

  Per visualizzare i valori predefiniti per queste impostazioni nei criteri anti-phishing, controllare i valori delle impostazioni nella tabella in Impostazioni dei criteri anti-phishing di EOP.

• Microsoft 365 non invia report forensi DMARC (noti anche come report di errore DMARC), anche se esiste un indirizzo valido ruf=mailto: nel record TXT DMARC del dominio di origine.

• Microsoft 365 invia report di aggregazione DMARC a tutti i domini con un indirizzo valido rua=mailto: nei record TXT DMARC, purché il record MX per il dominio di Microsoft 365 punti direttamente a Microsoft 365.

  Se la posta da Internet viene instradata tramite un servizio o un dispositivo di terze parti prima del recapito a Microsoft 365 (i punti record MX in un punto diverso da Microsoft 365), i report di aggregazione DMARC non vengono inviati. Questa limitazione include scenari EOP ibridi o autonomi in cui la posta viene recapitata all'ambiente locale prima di essere instradata a Microsoft 365 usando un connettore.

  Consiglio

  Quando un servizio o un dispositivo di terze parti si trova davanti alla posta che scorre in Microsoft 365, il filtro avanzato per i connettori (noto anche come elenco ignorati) identifica correttamente l'origine dei messaggi Internet per SPF, DKIM (se il servizio modifica i messaggi) e la convalida DMARC.

Risoluzione dei problemi di DMARC

È possibile usare il grafico seguente per risolvere i problemi di autenticazione DMARC.

Passaggi successivi

Per la posta in arrivo in Microsoft 365, potrebbe anche essere necessario configurare sealer ARC attendibili se si usano servizi che modificano i messaggi in transito prima del recapito all'organizzazione. Per altre informazioni, vedere Configurare sealer ARC attendibili.