Configurare DMARC per convalidare il dominio Dell'indirizzo per i mittenti cloud

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.

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 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 per la 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 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).
  • 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 mancato recapito).

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:

  • 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 sealer ARC attendibili impediscono ai messaggi modificati di non riuscire automaticamente i controlli DMARC. Per altre informazioni, vedere la sezione Passaggi successivi alla fine di questo articolo.

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 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 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 in 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 è possibile sostituire 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à di sicurezza predefinite seguenti per tutte le cassette postali cloud influiscono sui controlli DMARC sulla posta in arrivo:

  • 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 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 nell'introduzione alla convalida DMARC, un messaggio passa DMARC se almeno un controllo di allineamento ha esito positivo (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 predefiniti per r (rilassato), ma s (strict) è disponibile anche. Ad esempio:

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)	Strict (s)
user@contoso.com	contoso.com	✅ Passare	✅ Passare
user@contoso.com	bounces.contoso.com	✅ Passare	❌ Fallire
user@marketing.contoso.com	contoso.com	✅ Passare	❌ Fallire
user@contoso.com	contoso.onmicrosoft.com	❌ Fallire	❌ Fallire
user@contoso.com	adatum.net	❌ Fallire	❌ Fallire

Scenari di errore di allineamento comuni

Scenario	Sintomo	Causa radice	Risoluzione
Il servizio non Microsoft invia per conto dell'utente	SPF passa per adatum.com ma DMARC ha esito negativo	MAIL FROM usa il dominio del servizio (ad esempio , bounce.adatum.com) e nessuna firma DKIM con il 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	Inoltro delle modifiche al mittente della busta; La firma DKIM potrebbe interrompersi	Usare sealer attendibili ARC nella destinazione o usare DKIM (sopravvive all'inoltro se il corpo 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 supera ma DMARC continua a non riuscire	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	Indirizzi della busta per le modifiche di risposta o reindirizzamento	Verificare che DKIM sia intatto; prendere in considerazione ARC per i servizi intermedi

Diagnosticare gli errori di allineamento dalle intestazioni dei messaggi

Passaggio 1: Aprire le intestazioni dei messaggi e individuare l'intestazione Authentication-Results da Microsoft 365:

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:

Assegno	Campo di intestazione	Valore nell'esempio	Si allinea a 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 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 dettagliate, vedere Protezione spoofing e criteri DMARC del mittente.

Il riepilogo seguente mostra il comportamento generale per i messaggi in ingresso che hanno esito negativo in DMARC quando i criteri di record Honor DMARC sono attivati (scelta consigliata):

Criteri DMARC del mittente	Eliminazione dei messaggi	Authentication-Results	CompAuth
p=none	Nessuna azione specifica di DMARC. Si applicano ancora altri filtri.	dmarc=fail action=none	Basato sull'autenticazione composita (SPF, DKIM, intelligence per lo 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 sealer ARC attendibile (preferito).
• 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 allow nell'elenco tenant consentiti/bloccati (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 azione	Significato
action=none	Mittente pubblicato p=none; nessuna azione eseguita
action=quarantine	Mittente pubblicato p=quarantine; messaggio in quarantena o indesiderato
action=oreject	Mittente pubblicato p=reject; messaggio rifiutato ("o" = origine)
action=pct.quarantine	Mittente pubblicato p=quarantine con pct= meno di 100; questo messaggio era nella percentuale campionata
action=pct.reject	Mittente pubblicato p=reject con pct= meno di 100; questo messaggio era nella percentuale campionata

Interpretazione del report DMARC

Questa sezione consente di interpretare i report aggregati e forensi DMARC inviati dai ricevitori agli rua indirizzi e ruf .

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>

Leggere i report aggregati

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	Numero elevato da IP sconosciuto = potenziale spoofing
<disposition>	Azione eseguita dal ricevitore (none, quarantine, reject)	Verificare che il ricevitore rispetti i criteri
<dkim> Sotto <policy_evaluated>	Indica se DKIM è allineato (non solo passato)	fail = Il dominio DKIM non corrisponde al dominio da
<spf> Sotto <policy_evaluated>	Indica se SPF è allineato (non solo passato)	fail = Il dominio MAIL FROM non corrisponde al dominio
<domain> Sotto <auth_results><spf>	Dominio su cui è stato eseguito il controllo di SPF	Se diverso da Da dominio = problema di allineamento
<domain> Sotto <auth_results><dkim>	Dominio di firma DKIM	Deve corrispondere a Da dominio per l'allineamento DMARC
<result> Sotto <auth_results>	Passaggio/errore SPF/DKIM non elaborato (prima del controllo 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 di report aggregati

Modello nel report	Interpretazione	Correzione
IP noto, SPF auth=pass, SPF aligned=fail	Servizio legittimo con dominio MAIL FROM errato	Configurare il servizio per l'uso del dominio in MAIL FROM o configurare la firma DKIM con il dominio
IP noto, DKIM auth=pass, DKIM aligned=fail	Il servizio firma DKIM con il proprio dominio	Configurare DKIM personalizzato al 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 della posta interrompe SPF; modifica del corpo interrompe 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)	Report forensi (ruf)
Frequenza	Giornaliero (in genere)	Quasi in tempo reale (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 errore (può essere un volume elevato)
Privacy	Solo indirizzi IP e conteggi	Potrebbe includere intestazioni/corpo del messaggio (con redacted)
Supporto tecnico	Ampiamente supportato dai ricevitori	Supporto limitato (molti ricevitori non inviano ruf)
Use Case	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.

Struttura del report forense (formato AFRF/RFC 6591):

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

Consiglio	Dettagli
Usare una cassetta postale 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 creazione di report 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 volumi elevati.
Monitorare regolarmente	Esaminare i report aggregati ogni settimana durante la distribuzione iniziale; mensile una volta stabile
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 O ruf DMARC rua si trova in un dominio diverso da quello monitorato, il dominio ricevente deve pubblicare un record TXT DNS che autorizza il recapito del report:

Esempio: DMARC per l'invio contoso.com di report a dmarc@fabrikam.com

Record DNS obbligatorio in fabrikam.com:

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

Sintomo	Probabile causa	Passaggio di diagnostica	Risoluzione
dmarc=fail ma SPF e DKIM passano entrambi singolarmente	Errore di allineamento: i domini non corrispondono a Da	Archivia 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	Eseguire query sul _dmarc.domain.com record TXT	Microsoft deduce un passaggio. Pubblicare un record DMARC esplicito.
dmarc=fail action=oreject ma messaggio recapitato	Honor DMARC disabilitato o consenti l'elenco/override sul posto	Controllare le impostazioni dei criteri anti-phishing e l'elenco tenant consentiti/bloccati	Abilitare i criteri di record Honor DMARC se si desidera un'imposizione rigorosa
dmarc=fail per i messaggi inoltrati	L'inoltro interrompe l'allineamento SPF; le modifiche al corpo interrompono DKIM	Verificare se il messaggio è stato attraversato dall'intermediario (intestazioni X-MS-Exchange)	Configurare il sealer 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=	Controllare i report aggregati per l'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 sottostanti
compauth=fail reason=100	Errore esplicito di DMARC con imposizione 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	Correzione del routing delle cassette postali; aggiungere domain._report._dmarc un record TXT

Flusso di lavoro di diagnostica DMARC

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

1. Identificare il dominio Da: trovare il header.from= valore 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 riesce.
   • SPF è passato a tutti (spf=pass vs spf=fail)? Se spf=fail, correggere prima SPF aggiungendo il mittente al 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 è passato a tutti (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 sealer ARC attendibile.

5. Controllare l'azione dei criteri:

   • p=none: nessun effetto sul recapito (solo monitoraggio).
   • 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, usare ARC, un elenco consenti o correggere l'autenticazione nell'origine.

Comandi di PowerShell utili per la risoluzione dei problemi di DMARC

Connettersi a Exchange Online PowerShell ed eseguire i comandi seguenti:

# 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. Riferimento incrociato con i report di aggregazione DMARC per visualizzare 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, collaborare con loro per correggere l'allineamento SPF/DKIM prima di creare le sostituzioni.

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.

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