Configurare DMARC per convalidare il dominio dell'indirizzo From per i mittenti cloud

Consiglio

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

L'autenticazione dei messaggi basata sul dominio, la creazione di report e la conformità (DMARC) è un metodo di autenticazione tramite posta elettronica per convalidare la posta inviata dall'organizzazione di Microsoft 365. Questa convalida consente di evitare mittenti contraffatti usati in bec (Business Email Compromise), 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 degli indirizzi MAIL FROM e FROM siano allineati: SPF e DKIM non richiedono che i domini nei seguenti indirizzi di posta elettronica siano "allineati" (ossia corrispondano):

  • Indirizzo MAIL FROM: indirizzo di posta elettronica usato per la trasmissione del messaggio tra server di posta elettronica SMTP. Questo indirizzo è noto anche come indirizzo 5321.MailFrom, mittente P1 o mittente della busta di trasporto.
  • 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 di fatto che i mittenti validi del messaggio appartengano al dominio Indirizzo da.

  • 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 non supera il controllo DMARC se entrambi i controlli SPF e 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 i report:

  • Report aggregati (riepilogo periodico dei risultati DMARC positivi e negativi).
  • Rapporti forensi (noti anche come rapporti di errore; rapporti sugli errori DMARC generati quasi immediatamente, simili a un rapporto di mancata consegna 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 Usare il interfaccia di amministrazione di Microsoft 365 per aggiungere record TXT DMARC per i domini *.onmicrosoft.com in Microsoft 365. 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 Indirizzo da. Per istruzioni, vedere gli articoli seguenti:

  • Configurare SPF per identificare origini di posta elettronica valide per i domini cloud personalizzati
  • Configurare DKIM per firmare la posta elettronica dal dominio cloud

  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), 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 dagli utenti 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 altri domini (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 viene usato 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. I firmatari ARC attendibili impediscono che i messaggi modificati non superino automaticamente i controlli DMARC. Per altre informazioni, vedere Passaggi successivi.

Il resto di questo articolo illustra la creazione di record TXT DMARC, l'implementazione graduale per i domini personalizzati e la gestione DMARC in ingresso in Microsoft 365.

Consiglio

Per creare il record TXT DMARC per il dominio *.onmicrosoft.com nel interfaccia di amministrazione di Microsoft 365, vedere Usare il interfaccia di amministrazione di Microsoft 365 per aggiungere record TXT DMARC per i domini *.onmicrosoft.com in Microsoft 365.

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 di dominio. È 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>

o

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 DMARC (rifiutare, mettere in quarantena o nessuna azione):

  • 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.

  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 che non superano DMARC a cui viene applicato il criterio DMARC: indica al sistema di posta elettronica del destinatario a quanti messaggi che non superano DMARC (percentuale) viene applicato il criterio DMARC. Ad esempio, pct=100 significa che a tutti i messaggi che non superano il controllo DMARC viene applicato il criterio DMARC. Si usano valori inferiori a 100 per il test e l'ottimizzazione dei criteri DMARC. Se non si usa pct=, il valore predefinito è pct=100.

• Rapporti 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 superano o meno 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 corsi di formazione 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

Seguire questa procedura per aggiungere un record TXT DMARC per il dominio *.onmicrosoft.com nel interfaccia di amministrazione di Microsoft 365.

1. Nel centro di amministrazione di Microsoft 365 in https://admin.microsoft.com, seleziona Mostra tutto>Impostazioni>Domini. 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: Immetti 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 reportistica DMARC nel catalogo MISA disponibile all'indirizzo https://www.microsoft.com/misapartnercatalog consentono di visualizzare e interpretare più facilmente i risultati DMARC.

   • TTL: verificare che sia selezionata 1 ora .

   Dopo aver completato le operazioni nel riquadro a comparsa Aggiungi un record DNS personalizzato, selezionare Salva.

Configurare DMARC per i domini personalizzati attivi in Microsoft 365

Consiglio

Prima di configurare DMARC per domini personalizzati o sottodomini, è 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.

È 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 del dominio 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 del dominio 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 del dominio 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 email legittime in quantità significative è inaccettabile per gli utenti, ma è quasi inevitabile che si verifichino alcuni falsi positivi. Affronta con calma e metodo i problemi evidenziati nei report DMARC. I fornitori di soluzioni di reporting DMARC nel catalogo MISA disponibile all'indirizzo https://www.microsoft.com/misapartnercatalog semplificano la visualizzazione e l'interpretazione dei risultati DMARC.

5. I sottodomini ereditano le impostazioni del record TXT DMARC del dominio principale, che possono essere sovrascritte con 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 domini cloud personalizzati. Come descritto in Configurare DKIM per firmare la posta dal dominio cloud, i record CNAME DKIM non sono consigliati 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

Le funzionalità e i comportamenti seguenti influiscono sul modo in cui Microsoft 365 valuta DMARC per i messaggi in ingresso e se i report DMARC vengono inviati.

• Le funzionalità di sicurezza predefinite seguenti per tutte le cassette postali cloud influiscono sui controlli DMARC sulla posta in arrivo:

  • Indica se spoof intelligence è abilitata o disabilitata nel criterio anti-phishing che ha controllato il messaggio. La disabilitazione di spoof intelligence disattiva la protezione implicita dallo spoofing fornita solo dai controlli di autenticazione composita.
  • Indica se l'impostazione Rispetta i criteri del record DMARC quando il messaggio viene rilevato come contraffatto è abilitata o disabilitata nei criteri anti-phishing che hanno controllato il messaggio e quali azioni sono specificate in base ai criteri DMARC del dominio di origine (p=quarantine o p=reject nel record TXT DMARC).

  Per informazioni complete, vedere Protezione da 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 per tutte le cassette postali cloud.

• 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 si instrada la posta Internet tramite un servizio o un dispositivo non Microsoft 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 ibridi 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 non Microsoft 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

Per una tabella di riferimento rapido degli errori, delle cause e delle correzioni di DMARC, vedere Risolvere i problemi di autenticazione della posta elettronica in Microsoft 365.

Questa sezione consente di diagnosticare e risolvere gli errori DMARC comuni, comprendere in che modo Microsoft 365 agisce sui diversi criteri DMARC e interpretare i report aggregati e forensi DMARC.

Diagnosi degli errori di allineamento

Come descritto in Configurare DMARC per convalidare il dominio di Indirizzo da per i mittenti cloud, un messaggio supera il controllo DMARC se almeno un controllo di allineamento riesce (SPF o DKIM). Un messaggio ha esito negativo in DMARC solo se entrambi i controlli di allineamento hanno esito negativo.

Modalità di allineamento

I aspf tag (SPF) e adkim (DKIM) nel record TXT DMARC controllano in che modo il dominio From deve corrispondere al dominio autenticato. Entrambi sono facoltativi e per impostazione predefinita sono r (rilassato), ma è disponibile anche s (rigido). L'esempio seguente mostra un record TXT DMARC che usa un rigoroso allineamento SPF (aspf=s) e un allineamento DKIM rilassato (adkim=r):

Hostname: _dmarc
TXT value: v=DMARC1; p=reject; aspf=s; adkim=r; pct=100; rua=mailto:dmarc@contoso.com

• Relaxed (rimpostazione predefinita): i domini dell'organizzazione (domini radice) devono corrispondere. I sottodomini sono consentiti.
• Strict (s): gli FQDN devono corrispondere esattamente. Nessun sottodominio corrispondente.

Nota

I aspf tag e adkim sono indipendenti. È possibile usare modalità diverse per ognuna, come illustrato nell'esempio. Un messaggio passa DMARC se uno dei controlli di allineamento ha esito positivo, quindi un errore rigido su un controllo non è importante se l'altro controllo passa con un allineamento rilassato.

Esempi:

Indirizzo mittente	indirizzo MAIL FROM / DKIM-Signature d=	Rilassato (r)	Rigido (s)
user@contoso.com	contoso.com	✅ Superato	✅ Superato
user@contoso.com	bounces.contoso.com	✅ Superato	❌ Non riuscito
user@marketing.contoso.com	contoso.com	✅ Superato	❌ Non riuscito
user@contoso.com	contoso.onmicrosoft.com	❌ Non riuscito	❌ Non riuscito
user@contoso.com	adatum.net	❌ Non riuscito	❌ Non riuscito

Scenari di errore di allineamento comuni

La tabella seguente elenca gli scenari comuni di errore di allineamento DMARC, i relativi sintomi, le cause radice e le correzioni consigliate.

Scenario	Sintomo	Causa radice	Risoluzione
Il servizio non Microsoft invia per conto dell'utente	SPF ha esito positivo per adatum.com ma DMARC ha esito negativo	MAIL FROM usa il dominio del servizio (ad esempio, bounce.adatum.com) e senza firma DKIM con il tuo dominio	Configurare la firma DKIM con il dominio nel servizio o modificare MAIL FROM nel dominio/sottodominio
Inoltro automatico di Microsoft 365	Errore di DMARC nella destinazione	L'inoltro modifica il mittente della busta; la firma DKIM potrebbe non essere più valida	Usare firmatari ARC attendibili nel server di destinazione oppure usare DKIM (sopravvive all'inoltro se il corpo del messaggio non viene modificato)
Sottodominio invia con allineamento rigoroso	aspf=s causa errori per i mittenti del sottodominio	MAIL FROM è sub.contoso.com ma From è contoso.com	Passare a aspf=r (rilassato) o assicurarsi che l'indirizzo From corrisponda al sottodominio
Mancata corrispondenza del dominio di firma DKIM	DKIM passa ma DMARC continua a non passare	Il valore DKIM d= (ad esempio, adatum.com) non è allineato al dominio From (contoso.com)	Configurare la firma DKIM personalizzata nel servizio usando il dominio
Cassetta postale condivisa o gruppo di distribuzione	Errore intermittente di DMARC	Risposta da o reindirizzamento modificano gli indirizzi della busta	Verificare che DKIM sia intatto; prendere in considerazione ARC per i servizi intermedi

Diagnosticare gli errori di allineamento dalle intestazioni dei messaggi

Passaggio 1: Apri le intestazioni del messaggio e individua l'intestazione Authentication-Results di Microsoft 365. L'esempio seguente mostra un'intestazione Authentication-Results in cui SPF e DKIM risultano entrambi validi singolarmente, ma DMARC non supera la verifica perché nessuno dei due domini è allineato al dominio dell'indirizzo From:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Passaggio 2: Identificare l'errore di allineamento:

Controlla	Campo dell'intestazione	Valore nell'esempio	È allineato con Da (contoso.com)?
Allineamento SPF	smtp.mailfrom=	bounces.adatum.com	❌ No (dominio dell'organizzazione diverso)
Allineamento DKIM	header.d=	adatum.com	❌ No (dominio dell'organizzazione diverso)
Risultato DMARC	dmarc=	fail	Entrambi i controlli non sono riusciti

Passaggio 3: Determinare la correzione rispondendo alle domande seguenti:

1. È possibile modificare l'indirizzo MAIL FROM nel dominio , ad esempio bounces.contoso.com anziché bounces.adatum.com?
   • Sì: configurare la modifica MAIL FROM nel servizio per correggere l'allineamento SPF.
   • No: usare invece l'allineamento DKIM (andare al passaggio 2).
2. Il servizio può firmare con il tuo dominio (d=contoso.com)?
   • Sì: configurare la firma DKIM personalizzata nel servizio.
   • No: si consideri una strategia di sottodominio:
     • Inviare da un sottodominio (ad esempio, sub.contoso.com).
     • Pubblicare un record DMARC separato per tale sottodominio.
     • Fare in modo che il servizio firmi DKIM con d=sub.contoso.com.

Controllare l'allineamento per i messaggi recenti in PowerShell

Connettersi a Exchange Online PowerShell ed eseguire i comandi seguenti:

# Get recent messages and check authentication results
$messages = Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -PageSize 100

foreach ($msg in $messages) {
    $details = Get-MessageTraceDetail -MessageTraceId $msg.MessageTraceId -RecipientAddress $msg.RecipientAddress
    $authEvent = $details | Where-Object { $_.Event -eq "Receive" }
    if ($authEvent.Detail -match "dmarc=fail") {
        Write-Output "DMARC FAIL: From=$($msg.SenderAddress), Subject=$($msg.Subject)"
    }
}

Effetto dei criteri DMARC sul comportamento di Microsoft 365

Come descritto in DMARC per la posta in ingresso, il comportamento di Microsoft 365 dipende dall'impostazione dei criteri dei record Honor DMARC . Per informazioni complete, vedi Protezione da spoofing e criteri DMARC del mittente.

Il riepilogo seguente mostra il comportamento generale dei messaggi in ingresso che non superano DMARC quando Rispetta il criterio del record DMARC è Attivato (scelta consigliata):

Politica DMARC del mittente	Gestione dei messaggi	Authentication-Results	CompAuth
p=none	Nessuna azione specifica di DMARC. Si applicano ancora altri filtri.	dmarc=fail action=none	Basato sull'autenticazione combinata (SPF, DKIM, analisi dello spoofing)
p=quarantine	Cartella Email indesiderata (configurabile per la quarantena)	dmarc=fail action=quarantine	compauth=fail reason=100
p=reject	Rifiutato durante SMTP (550 5.7.1)	dmarc=fail action=oreject	compauth=fail reason=100

Attenzione

Prestare attenzione quando si esegue l'override p=reject per i mittenti legittimi. Se l'organizzazione riceve legittimo la posta da un mittente il cui DMARC ha esito negativo (ad esempio, posta inoltrata, mailing list), usare uno di questi approcci:

• Configurare il mittente come firmatario ARC attendibile (scelta consigliata).
• Creare una regola del flusso di posta con condizioni specifiche (indirizzo IP mittente e dominio mittente) per ignorare il filtro della posta indesiderata.
• Aggiungere una voce di autorizzazione nell'Elenco Consenti/Blocca tenant (temporanea, scade tra 30 giorni).

Valori di azione DMARC in Authentication-Results

Nell'intestazione Authentication-Results potrebbero essere visualizzati questi valori di azione DMARC:

Valore dell'azione	Significato
action=none	Mittente pubblicato p=none; nessuna azione eseguita
action=quarantine	Mittente pubblicato p=quarantine; messaggio in quarantena o indesiderato
action=oreject	Il mittente ha pubblicato p=reject; messaggio rifiutato ("o" = origine)
action=pct.quarantine	Il mittente ha pubblicato p=quarantine con pct= inferiore a 100; questo messaggio rientrava nella percentuale campionata
action=pct.reject	Il mittente ha pubblicato p=reject con pct= inferiore a 100; questo messaggio rientrava nella percentuale campionata

Interpretazione del report DMARC

Questa sezione ti aiuta a interpretare i report aggregati DMARC e i report forensi che i server destinatari inviano ai tuoi indirizzi rua e ruf. Per informazioni sulla configurazione dei valori rua e ruf nel record TXT DMARC, vedi Sintassi dei record TXT DMARC.

Report aggregati

Nell'esempio seguente viene illustrata la struttura XML di un report di aggregazione:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>microsoft.com</org_name>           <!-- Reporting organization -->
    <email>dmarceng@microsoft.com</email>
    <report_id>unique-report-id</report_id>
    <date_range>
      <begin>1700000000</begin>                   <!-- Unix timestamp: start -->
      <end>1700086400</end>                       <!-- Unix timestamp: end -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>contoso.com</domain>                  <!-- Your domain -->
    <adkim>r</adkim>                              <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                <!-- SPF alignment mode -->
    <p>reject</p>                                 <!-- Domain policy -->
    <sp>quarantine</sp>                           <!-- Subdomain policy -->
    <pct>100</pct>                                <!-- Percentage -->
  </policy_published>

  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>        <!-- Sending IP -->
      <count>1523</count>                         <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>           <!-- What receiver did -->
        <dkim>pass</dkim>                         <!-- DKIM alignment result -->
        <spf>fail</spf>                           <!-- SPF alignment result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contoso.com</header_from>      <!-- From address domain -->
      <envelope_from>bounces.adatum.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contoso.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>bounces.adatum.com</domain>
        <result>pass</result>                     <!-- SPF passed but... -->
      </spf>
    </auth_results>
  </record>
</feedback>

Leggi i report aggregati

Usare la tabella seguente per interpretare i campi più importanti in un report di aggregazione DMARC e determinare l'azione da intraprendere per la risoluzione dei problemi.

elemento XML	Cosa ti dice	Azione di risoluzione dei problemi
<source_ip>	Indirizzo IP che ha inviato i messaggi	Identificare se si tratta di un mittente legittimo o non autorizzato
<count>	Numero di messaggi da questa origine	Conteggio elevato da un IP sconosciuto = potenziale spoofing
<disposition>	Azione eseguita dal ricevitore (none, quarantine, reject)	Verificare che il ricevitore rispetti i criteri
<dkim> alla voce <policy_evaluated>	Indica se DKIM è allineato (non solo superato)	fail = Il dominio DKIM non corrisponde al dominio del campo From
<spf> alla voce <policy_evaluated>	Indica se SPF è allineato (non solo superato)	fail = Il dominio MAIL FROM non corrisponde al dominio From
<domain> alla voce <auth_results><spf>	Dominio su cui è stato eseguito il controllo di SPF	Se diverso dal dominio del mittente = problema di allineamento
<domain> alla voce <auth_results><dkim>	Dominio di firma DKIM	Deve corrispondere al dominio Da per l'allineamento DMARC
<result> alla voce <auth_results>	Esito grezzo SPF/DKIM: superato/non superato (prima della verifica dell'allineamento)	pass + allineamento fail = problema di allineamento classico

Consiglio

Le informazioni dettagliate più importanti dei report aggregati sono l'identificazione del divario tra il passaggio di autenticazione e il passaggio di allineamento:

• <auth_results><spf><result>pass</result> + <policy_evaluated><spf>fail</spf> = SPF passato ma i domini non sono allineati.
• Questa combinazione indica che il mittente è autorizzato (passaggio SPF), ma non è configurato correttamente per DMARC (errore di allineamento).

Modelli e correzioni comuni per i report aggregati

La tabella seguente illustra i modelli comuni che è possibile trovare nei report aggregati e nelle azioni che in genere richiedono.

Modello nel report	Interpretazione	Correzione
IP noto, SPF auth=pass, SPF aligned=fail	Servizio legittimo con dominio MAIL FROM errato	Configura il servizio per usare il tuo dominio nel MAIL FROM oppure configura la firma DKIM con il tuo dominio
IP noto, DKIM auth=pass, DKIM aligned=fail	Il servizio firma DKIM con il proprio dominio	Configurare DKIM personalizzato nel servizio con d=contoso.com
IP sconosciuto, volume elevato, tutto ha esito negativo	Potenziale campagna di spoofing/phishing	Non è necessaria alcuna azione. I criteri DMARC proteggono i destinatari.
IP noto (Microsoft 365), SPF aligned=pass	Normale flusso di posta di Microsoft 365	Sano. Non è necessaria alcuna azione.
Volume ridotto dal servizio legittimo, errore SPF+DKIM	Servizio non incluso in SPF e non firma DKIM	Aggiungere il servizio al record SPF e/o configurare DKIM
Posta inoltrata (indirizzi IP della mailing list), tutto ha esito negativo	L'inoltro delle email compromette SPF; la modifica del corpo del messaggio compromette DKIM	Normale per la posta inoltrata. Usare ARC o accettare alcuni errori.

Report forensi

Come indicato nella sezione DMARC per la posta in ingresso , Microsoft 365 non invia report forensi. Tuttavia, è possibile riceverli da altri provider. Nella tabella seguente vengono confrontati i due tipi di report:

Aspetto	Report aggregati (rua)	Rapporti di analisi forense (ruf)
Frequenza	Ogni giorno (in genere)	Near real-time (per errore)
Contenuto	Statistiche di riepilogo per IP di origine	Dettagli dei singoli messaggi
Volume	Un report al giorno per ogni giornalista	Un report per ogni guasto (il volume può essere elevato)
Privacy	Solo indirizzi IP e conteggi	Potrebbe includere le intestazioni e il corpo del messaggio (oscurati)
Supporto tecnico	Ampiamente supportato dai ricevitori	Supporto limitato (molti ricevitori non inviano ruf)
Caso d'uso	Analisi delle tendenze, identificazione di mittenti sconosciuti	Debug di errori specifici, analisi forense

Nota

Se sono necessari dettagli sugli errori per messaggio da Microsoft 365, usare l'analisi della traccia dei messaggi e dell'intestazione del messaggio anziché i report forensi.

L'esempio seguente mostra la struttura di un report forense DMARC (formato AFRF/RFC 6591) che un ricevitore invia al tuo indirizzo ruf quando un messaggio non supera il controllo DMARC. Cerca i campi Feedback-Type, Source-IP e Authentication-Results per identificare i dettagli dell'errore:

From: noreply-dmarc-support@fabrikam.com
To: ruf@contoso.com
Subject: Report Domain: contoso.com Submitter: fabrikam.com

Feedback-Type: auth-failure
User-Agent: fabrikam.com/dmarc-reporter
Version: 1
Original-Mail-From: bounces@adatum.com
Arrival-Date: Mon, 15 Jan 2024 10:30:00 -0000
Source-IP: 198.51.100.10
Authentication-Results: fabrikam.com; dmarc=fail (p=reject)
  header.from=contoso.com
Reported-Domain: contoso.com
Original-Envelope-Id: <abc123@mail.adatum.com>

Procedure consigliate per i report DMARC

Usare le procedure consigliate seguenti per gestire in modo efficace i report DMARC.

Raccomandazione	Dettagli
Usa una casella di posta dedicata per rua	Creare una cassetta postale condivisa, dmarc-reports@contoso.comad esempio . Non usare cassette postali di singoli utenti.
Usare un gruppo di Microsoft 365	I gruppi offrono un migliore accesso condiviso e collaborazione per il team di sicurezza
Si consideri un servizio di reportistica DMARC	DMARC Reporting Services analizza il codice XML nei dashboard. Cercare DMARC nel catalogo MISA.
Inizia solo con rua	Se necessario, aggiungere ruf in un secondo momento. I report forensi possono generare un volume elevato di dati.
Monitorare regolarmente	Rivedere i report aggregati settimanalmente durante la distribuzione iniziale; mensilmente una volta stabilizzato il sistema
Impostare aspettative realistiche	Non tutti i ricevitori inviano report. La copertura è in genere del 70-90% del volume totale di posta

Creazione di report tra domini

Se l'indirizzo DMARC rua o ruf si trova in un dominio diverso dal dominio monitorato, il dominio destinatario deve pubblicare un record TXT DNS che autorizzi il recapito del report:

Esempio: DMARC per contoso.com invia report a dmarc@fabrikam.com

Per autorizzare fabrikam.com a ricevere report DMARC per conto di contoso.com, l'amministratore di fabrikam.com deve pubblicare il record TXT DNS seguente:

Hostname: contoso.com._report._dmarc
Type: TXT
Value: v=DMARC1;

Senza questo record, i ricevitori non recapitano i report DMARC all'indirizzo esterno.

Guida di riferimento rapido alla risoluzione dei problemi di DMARC

La tabella seguente fornisce un riferimento rapido per i sintomi DMARC comuni, le possibili cause, i passaggi diagnostici e le risoluzioni.

Sintomo	Probabile causa	Passaggio diagnostico	Risoluzione
dmarc=fail ma SPF e DKIM passano entrambi singolarmente	Errore di allineamento: i domini non corrispondono Da	Controllare smtp.mailfrom= e header.d= vs header.from= in Authentication-Results	Configurare SPF/DKIM con domini allineati
dmarc=bestguesspass	Nessun record DMARC pubblicato per il dominio From	Query _dmarc.domain.com record TXT	Microsoft deduce un passaggio. Pubblica un record DMARC esplicito.
dmarc=fail action=oreject ma il messaggio è stato recapitato	Honor DMARC disabilitato o elenco Consenti/override sul posto	Controllare le impostazioni dei criteri anti-phishing e l'elenco Consenti/Blocca tenant	Abilita Rispetta i criteri del record DMARC se si desidera un'applicazione rigorosa
dmarc=fail per i messaggi inoltrati	L'inoltro interrompe l'allineamento SPF; le modifiche al corpo del messaggio invalidano DKIM	Verificare se il messaggio è transitato attraverso un intermediario (header X-MS-Exchange)	Configurare il firmatario ARC attendibile per il servizio di inoltro
dmarc=fail per mittente SaaS non Microsoft	Il servizio usa il proprio dominio in MAIL FROM e DKIM d=	Verificare i report aggregati relativi all'IP del servizio	Configurare la firma DKIM personalizzata nel servizio + allineare MAIL FROM
dmarc=temperror o dmarc=permerror	Problemi DNS durante il recupero del record DMARC (timeout, errore di sintassi)	Convalidare la sintassi del record DMARC con nslookup -type=TXT _dmarc.domain.com	Correggere gli errori di sintassi DNS; verificare che esista un _dmarc solo record TXT
compauth=fail reason=000	Autenticazione composita non riuscita (errore esplicito)	Controllare tutti i risultati dell'autenticazione (SPF, DKIM, DMARC, ARC)	Risolvere i problemi SPF/DKIM/DMARC alla base
compauth=fail reason=100	Fallimento esplicito di DMARC con applicazione dei criteri	Il criterio DMARC del mittente ha causato l'errore	Correggere l'allineamento all'origine o configurare ARC/override se legittimo
Report aggregati non ricevuti	rua indirizzo non raggiungibile o autenticazione tra domini mancante	Verificare l'esistenza della cassetta postale e il record di autorizzazione DNS per i domini esterni	Correggi il routing delle caselle di posta; aggiungi domain._report._dmarc record TXT

Flusso di lavoro di diagnostica DMARC

Seguire questa procedura per diagnosticare un messaggio con dmarc=fail:

1. Identifica il dominio del mittente: Trova il valore header.from= nell'intestazione Authentication-Results.

2. Controllare l'allineamento SPF: il smtp.mailfrom= dominio corrisponde al header.from= dominio?

   • Sì (stesso dominio aziendale con aspf=r): SPF è allineato.
   • No: l'allineamento SPF non va a buon fine.
   • SPF ha avuto esito positivo almeno una volta (spf=pass vs spf=fail)? Se spf=fail, correggere prima l'SPF aggiungendo il mittente nel record SPF.

3. Controllare l'allineamento DKIM: il header.d= valore nel DKIM-Signature corrisponde al header.from= dominio?

   • Sì (stesso dominio aziendale con adkim=r): DKIM è allineato.
   • No: l'allineamento DKIM non riesce.
   • DKIM ha avuto esito positivo almeno una volta (dkim=pass vs dkim=fail)? Se dkim=fail, correggere DKIM pubblicando la chiave e verificando la firma.

4. Se entrambi gli allineamenti hanno esito negativo, DMARC ha esito negativo. Opzioni di risoluzione:

   • Correzione dell'allineamento SPF: modificare l'indirizzo MAIL FROM nel dominio.
   • Correzione dell'allineamento DKIM: Firmare con d=contoso.com.
   • Usare un sottodominio: inviare da sub.domain.com con il proprio record DMARC.
   • Se il messaggio viene inoltrato: configurare un firmatario ARC attendibile.

5. Controllare l'azione dei criteri:

   • p=none: nessun effetto sulla consegna (solo monitorare).
   • p=quarantine: il messaggio passa a Junk Email (se il criterio Honor DMARC è attivato).
   • p=reject: il messaggio viene rifiutato (se il criterio Honor DMARC è attivato). Se la posta legittima viene rifiutata, utilizzare ARC, una lista consentita o correggere l'autenticazione alla fonte.

Comandi di PowerShell utili per la risoluzione dei problemi di DMARC

Connettersi a Exchange Online PowerShell e usare i comandi seguenti per verificare le impostazioni DMARC dei criteri anti-phishing, controllare i record DNS DMARC e DKIM, esaminare gli errori DMARC recenti ed esaminare la configurazione ARC:

# Check your organization's anti-phishing policy DMARC settings
Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

# Verify DMARC record for a domain
Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

# Check DKIM configuration (alignment prerequisite)
Get-DkimSigningConfig | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

# Review messages that failed DMARC in the last 24 hours
Get-MailDetailSpamReport -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
  Where-Object { $_.MessageTraceId } |
  Select-Object Date, SenderAddress, RecipientAddress, Subject, SpamScore

# Check ARC configuration (for forwarding scenarios)
Get-ArcConfig | Format-List ArcTrustedSealers

# View anti-phishing policy DMARC override actions
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" |
  Select-Object HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

Consiglio

Durante la risoluzione degli errori DMARC per un mittente specifico:

1. Iniziare con l'intestazione Authentication-Results per identificare il tipo di errore.
2. Confronta con i tuoi report aggregati DMARC per vedere il volume e gli indirizzi IP di origine.
3. Usare Get-MessageTrace per trovare messaggi specifici e Get-MessageTraceDetail per esaminare gli eventi di recapito.
4. Se il mittente è legittimo, collaborate con il mittente per correggere l'allineamento SPF/DKIM prima di creare eccezioni.

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 i sigillatori ARC attendibili.

Per diagnosticare e correggere gli errori di autenticazione della posta elettronica, vedere Risolvere i problemi di autenticazione tramite posta elettronica in Microsoft 365.