Guida alle operazioni di sicurezza per l'autenticazione tramite posta elettronica in Microsoft 365

L'autenticazione tramite posta elettronica in Microsoft 365 è un componente fondamentale della protezione delle comunicazioni nell'organizzazione. Quando viene ricevuto un messaggio di posta elettronica in Microsoft 365, il servizio aggiunge un'intestazione Authentication-Results . Questa intestazione mostra i risultati di vari controlli di autenticazione della posta elettronica, tra cui SPF, DKIM, DMARC e autenticazione composita (compauth).

Questa guida illustra gli scenari comuni che potrebbero verificarsi con questi risultati:

• Motivo per cui un messaggio ha superato o non ha superato l'autenticazione email.
• Indica se l'origine del messaggio di posta elettronica o la destinazione di posta elettronica è responsabile del risultato.
• Quali azioni (se presenti) è consigliabile per migliorare i risultati dell'autenticazione tramite posta elettronica.

Prima di tutto, ecco alcune definizioni chiave:

Scenari di esito positivo dell'autenticazione email

Questi scenari descrivono i messaggi che hanno superato i controlli di autenticazione della posta elettronica o sono stati accettati (a volte a causa di configurazioni specifiche). In generale, quando viene superta l'autenticazione tramite posta elettronica, non è necessaria alcuna azione correttiva. Tuttavia, alcuni scenari includono note cautelari in cui è consigliabile migliorare la configurazione per migliorare la sicurezza.

Il mittente fa riferimento agli amministratori dell'organizzazione di origine. Il destinatario fa riferimento agli amministratori dell'organizzazione di destinazione.

Tutti i controlli di autenticazione superati

Questo scenario si applica quando tutti i controlli di autenticazione della posta elettronica standard vengono superati correttamente.

• Esempio di intestazione: dmarc=pass (e in genere spf=pass e dkim=pass).
• Significato: tutti i controlli di autenticazione della posta elettronica (SPF, DKIM e DMARC) hanno avuto esito positivo. Questo risultato indica che il messaggio è completamente autenticato in base ai protocolli di autenticazione della posta elettronica standard.
• Chi è responsabile: il mittente.
• Azione consigliata: Nessuna. L'autenticazione Email è configurata correttamente e funziona come previsto. Il destinatario può considerare attendibile il dominio del mittente autenticato correttamente questo messaggio.

Autenticazione composita passata

Questo scenario descrive come Microsoft 365 può accettare un messaggio tramite l'autenticazione composita.

• Intestazione di esempio: compauth=pass (pass di autenticazione composita).

• Significato: il messaggio ha superato l'autenticazione composita di Microsoft 365:

  • Sono stati soddisfatti i requisiti DMARC: SPF o DKIM ha superato la verifica e gli indirizzi MAIL FROM e From sono allineati.

    Oppure

  • La logica di attendibilità implicita di Microsoft ha identificato il messaggio come legittimo. Ad esempio, un messaggio potrebbe superare l'autenticazione composita in base alla cronologia dei mittenti attendibili di Microsoft o a un'analisi di intteligence dello spoofing che indica che il mittente è attendibile.

• Chi è responsabile: il mittente.

• Azione consigliata: Nessuna. I controlli di autenticazione hanno avuto esito positivo e il sistema non ha rilevato problemi. In questo scenario non sono necessarie modifiche a SPF o DKIM.

Controllo DMARC superato senza criterio DMARC (nessun record DMARC)

Questo scenario illustra i messaggi che sembrano passare DMARC anche se il mittente non ha pubblicato un record DMARC.

• Esempio di intestazione: dmarc=bestguesspass action=none
• Significato: il messaggio ha passato DMARC per impostazione predefinita perché il dominio del mittente non ha un record DMARC pubblicato. Quando un dominio non dispone di un criterio DMARC, i server di posta elettronica di destinazione non possono rifiutare il messaggio in base a DMARC. In effetti, il controllo DMARC non si applica. DMARC=bestguesspass action=none significa che se il dominio aveva un record DMARC valido, il controllo DMARC per il messaggio passerebbe.
• Chi è responsabile: il mittente.
• Azione consigliata: il mittente deve pubblicare un record DMARC per il proprio dominio. Anche se il messaggio è stato accettato, l'assenza di un criterio DMARC non è un buon segno. È consigliabile che il proprietario del dominio imposti un record TXT DMARC per applicare un criterio DMARC (p=quarantine o p=reject) per i messaggi che non soddisfano la convalida DMARC. Per altre informazioni, vedere Sintassi per i record TXT DMARC.

Convalidata da ARC (scenari di routing complessi)

Questo scenario si applica ai messaggi accettati tramite la convalida ARC nell'inoltro o in altri percorsi di routing complessi.

• Esempio di intestazione: compauth=pass reason=130 (autenticazione composita superata grazie ad ARC).
• Cosa significa: il messaggio ha superato l'autenticazione grazie a un'eccezione ARC (Authenticated Received Chain). Questo risultato si verifica in genere in scenari complessi di routing della posta o inoltro di posta elettronica. Se un server di posta intermedia modifica il messaggio e causa l'esito negativo di SPF o DKIM, una firma ARC attendibile informa Microsoft 365 che l'autenticazione originale è valida. In questo caso, il sistema ha accettato il messaggio in base alla catena ARC valida, anche se i controlli SPF o DKIM diretti potrebbero non riuscire.
• Chi è responsabile: il mittente (mittente o intermediario originale).Who's responsible: The Sender (original sender or intermediary). Non ci sono errori di configurazione. Un intermediario che usa ARC ha elaborato il messaggio.
• Azione consigliata: se è previsto questo scenario, non è necessaria alcuna azione diretta , ad esempio il messaggio è stato elaborato da un servizio noto che implementa ARC. Se si gestisce un servizio intermedio non Microsoft, aggiungere intestazioni ARC e verificare che i server riceventi (ad esempio Microsoft 365) considerino attendibili le firme ARC. Questa configurazione consente ai messaggi in ingresso di superare la verifica compauth tramite ARC.

Messaggio recapitato a causa della presenza di voci di autorizzazione per mittenti falsificati nell'elenco di tenant consentiti/bloccati

Questo scenario spiega perché un messaggio spoofing può comunque essere recapitato quando l'organizzazione del destinatario lo consente in modo esplicito.

• Cosa significa: il messaggio ha aggirato le normali azioni previste in caso di errore di autenticazione perché nell'elenco Tenant Allow/Block List sono presenti voci consentite per mittenti falsificati. In Microsoft 365, una voce di autorizzazione per i mittenti contraffatti può sostituire gli errori. Anche quando i controlli di autenticazione della posta elettronica normalmente non riescono, il messaggio è consentito a causa di questa configurazione di attendibilità esplicita.

• Esempio di intestazione: compauth=fail reason=000 (ma un criterio organizzativo ha consentito il messaggio: Spoofing consentito nell'elenco di tenant consentiti/bloccati).

• Chi è responsabile: il destinatario. Gli amministratori dell'organizzazione del destinatario hanno configurato una voce di autorizzazione per lo spoofing nell'elenco di tenant consentiti/bloccati per questa specifica sintassi della coppia di domini per le voci del mittente falsificato. Il mittente deve risolvere i problemi di autenticazione per evitare problemi di recapito con altri destinatari.

• Azione consigliata: gli amministratori dei destinatari possono controllare la sezione Tutte le eccezioni nella pagina dell'entità di posta elettronica per verificare se è presente un'eccezione del Tenant Allow/Block List. Questi messaggi contengono Consentito dai criteri dell'organizzazione: spoofing consentito dall'elenco Consenti/Blocca dei tenant.

  In genere, non esiste un'azione immediata per questi messaggi, poiché sono intenzionalmente consentiti. Tuttavia, è buona prassi che gli amministratori riesaminino periodicamente le voci di autorizzazione per i mittenti falsificati per garantire che siano consentiti solo i mittenti necessari. L'uso eccessivo dell'elenco Tenant Consenti/Blocca può consentire il recapito di messaggi (potenzialmente dannosi) che normalmente non supererebbero i controlli di autenticazione.

Autenticato tramite allineamento PTR (DNS inverso)

Questo scenario descrive l'autenticazione di fallback basata su informazioni PTR (Reverse DNS) quando i controlli standard sono inconcludenti.

• Esempio di intestazione: compauth=pass con codici come reason=116 o reason=111 per indicare l'uso del record PTR.
• Cosa significa: il messaggio ha superato l'autenticazione in base alla convalida del PTR (DNS inverso) come soluzione di riserva. In alcuni casi, quando i controlli SPF e DKIM non producono un passaggio conclusivo, Microsoft 365 può esaminare il record PTR del mittente. Se l'indirizzo IP del server di invio ha un record PTR (DNS inverso) corrispondente al dominio nell'indirizzo From del messaggio, il sistema potrebbe considerare il messaggio come autenticato.
• Chi è responsabile: il mittente. Il server di posta elettronica del mittente è stato verificato tramite record PTR in DNS. Questo risultato indica in genere che SPF e DKIM non sono stati configurati correttamente e il sistema ha fatto ricorso alla ricerca PTR.
• Azione consigliata: il mittente deve assicurarsi che SPF e DKIM siano configurati correttamente per il dominio. Un record DNS inverso corretto (PTR) che esegue il mapping del dominio di invio all'indirizzo IP di invio è valido, ma non sostituisce l'allineamento DMARC. I mittenti devono considerare il passaggio PTR come un indicatore per migliorare la configurazione SPF e DKIM. Non esiste alcuna azione per il destinatario, ad eccezione della notifica ai mittenti quando notano questo risultato.

scenari di errore di autenticazione Email

Questi scenari riguardano i controlli di autenticazione non riusciti o altre condizioni in cui il messaggio è contrassegnato come non autenticato. L'esito negativo di un controllo di autenticazione non significa sempre che il messaggio sia stato rifiutato. Alcuni errori comportano la messa in quarantena o il recapito del messaggio con avvisi. Gli scenari seguenti descrivono il motivo per cui si è verificato l'errore, chi deve risolverlo e come risolvere il problema sottostante.

Il mittente fa riferimento agli amministratori dell'organizzazione di origine. Il destinatario fa riferimento agli amministratori dell'organizzazione di destinazione.

DMARC non riuscito (messaggio rifiutato o messo in quarantena)

Questo scenario illustra come interpretare un errore DMARC che porta alla quarantena o al rifiuto del messaggio.

• Esempio di intestazione: dmarc=fail action=quarantine (o action=reject); spesso accompagnato da compauth=fail con un codice (ad esempio, reason=000, reason=001 o reason=601).

• Significato: convalida DMARC non riuscita per il messaggio. Questo risultato significa:

  • SPF o DKIM non hanno superato il controllo con allineamento rispetto al dominio dell'indirizzo nel campo Da.

    E

  • Il record DMARC del dominio dell'indirizzo From contiene un criterio p=quarantine o un criterio p=reject.

  Di conseguenza, Microsoft 365 ha contrassegnato il messaggio per l'azione del criterio specificata: recapitarlo nella cartella Posta indesiderata, metterlo in quarantena o rifiutarlo.

• Chi è responsabile: il mittente o il destinatario. L'errore è dovuto al fatto che il dominio del mittente non passa DMARC o la configurazione del destinatario per l'integrazione di servizi di sicurezza non Microsoft con Microsoft 365 che ha causato l'esito negativo di DMARC.

  Anche se i mittenti sono responsabili della corretta configurazione di SPF, DKIM e DMARC per il proprio dominio, gli errori di autenticazione possono talvolta causare problemi nell'organizzazione del destinatario. Ad esempio:

  • L'organizzazione del destinatario usa un servizio di filtro non Microsoft tra Internet Microsoft 365 senza configurare il filtro avanzato per i connettori. La convalida SPF potrebbe non riuscire quando Microsoft 365 riceve il messaggio.
  • Se il servizio di filtro non Microsoft modifica il messaggio prima del recapito, DKIM potrebbe non riuscire, anche se il record DKIM del mittente è configurato correttamente.

  Di conseguenza, è importante distinguere tra il verdetto nel punto di ricezione iniziale (record MX) e il verdetto quando il messaggio raggiunge la cassetta postale del destinatario.

• Azione consigliata:

  • Il mittente deve correggere la configurazione dell'autenticazione tramite posta elettronica. In particolare, il mittente deve seguire questa procedura:

    • Assicurarsi che il record SPF includa tutti gli indirizzi IP di origine legittimi per la posta elettronica dal dominio.
    • Configurare DKIM per il dominio e verificare che le firme siano applicate correttamente alla posta in uscita.
    • Verificare che SPF o DKIM (o entrambi) superino il controllo e siano inoltre allineati con il dominio dell'indirizzo From, come richiesto da DMARC.
    • Verificare la sintassi del record DMARC e il criterio DMARC. Ad esempio, p=quarantine o p=reject.

  • Il destinatario deve correggere la configurazione complessa del routing della posta. In particolare, il destinatario deve seguire questa procedura:

    • Configurare il filtro avanzato per i connettori
    • Se disponibile, configurare firmatari ARC attendibili per superare gli errori causati da modifiche del messaggio durante il transito.
    • È consigliabile usare Microsoft 365 per applicare modifiche ai messaggi (piè di pagina, dichiarazioni di non responsabilità, oggetto e così via) anziché servizi non Microsoft.

Controllo SPF non riuscito

Questo scenario consente di diagnosticare i messaggi che non superano la valutazione SPF.

• Esempio di intestazione: spf=fail o spf=softfail. Verificare la presenza di spf=temperror, che indica problemi DNS temporanei, o di spf=permerror, che indica problemi di configurazione SPF.

• Che cosa significa: una delle seguenti possibilità:

  • L'indirizzo IP del server di invio non è autorizzato dal record SPF del dominio, quindi la restituzione di SPF ha esito negativo.
  • Il controllo SPF non è stato completato correttamente. Ad esempio, un problema di ricerca DNS (spf=temperror) o un numero eccessivo di reindirizzamenti (spf=permerror).

  Un errore SPF senza un passaggio DMARC comporta anche un errore DMARC.

• Chi è responsabile: il mittente. Il problema risiede nella configurazione del record SPF del dominio del mittente o nella configurazione del server di invio.

• Azione consigliata: il mittente deve aggiornare e correggere il record SPF del dominio:

  • Verificare che tutti gli indirizzi IP di origine legittimi per il dominio siano inclusi nel record SPF.
  • Se DMARC non supera il controllo a causa di un mancato allineamento dei domini (il dominio dell'indirizzo MAIL FROM è diverso dal dominio dell'indirizzo From), puoi risolvere il problema eseguendo una o entrambe le operazioni seguenti:
    • Allineare i domini usati negli indirizzi MAIL FROM e From.
    • Configurare la firma DKIM dei messaggi in uscita usando un dominio corrispondente al dominio dell'indirizzo From. DMARC richiede la convalida SPF o DKIM, non entrambe.
  • spf=temperror indica in genere che il destinatario ha riscontrato un problema durante la risoluzione del record SPF( ad esempio, problemi DNS temporanei). Il mittente deve verificare che i server DNS per il dominio siano integri e raggiungibili. Se il valore TTL (Time-to-Live) è troppo basso e causa timeout frequenti, valutare la possibilità di aumentare il TTL ad almeno un'ora.
  • spf=permerror in genere indica un problema con il record SPF stesso, inclusa la risoluzione dei problemi relativi ai record TXT SPF che richiedono più di 10 ricerche DNS. Semplificare il record SPF rimuovendo le istruzioni non necessarie include: e correggendo eventuali errori di sintassi.

La risoluzione dei problemi SPF significa che è più probabile che i messaggi superino l'autenticazione DMARC. I destinatari devono notificare ai mittenti gli errori SPF e le azioni consigliate per risolvere i problemi.

Controllo DKIM non riuscito (nessuna chiave per la firma)

Questo scenario illustra gli errori DKIM causati da chiavi pubbliche mancanti o non corrispondenti nel DNS.

• Esempio di intestazione: dkim=fail (nessuna chiave per la firma) se la chiave pubblica era mancante.

• Che cosa significa: una delle seguenti possibilità:

  • C'era una firma DKIM, ma il destinatario non è riuscito a trovare una chiave pubblica corrispondente in DNS (nessuna chiave).

    Oppure

  • La chiave non corrisponde alla firma (non è stato possibile verificare la firma).

• Chi è responsabile: il mittente. Il dominio del mittente ha una configurazione DKIM interrotta:

  • Una chiave pubblica non è presente nel record CNAME O TXT DKIM in DNS.

    Oppure

  • Si è verificato un problema DNS sul lato del mittente o sul lato del ricevitore.

• Azione consigliata: il mittente deve correggere la configurazione DKIM per il dominio seguendo questa procedura:

  • Pubblicare la chiave pubblica DKIM in DNS. Verificare che il record DKIM CNAME o TXT contenga un selettore valido , ad esempio , selector._domainkey.contoso.comcorrispondente alla chiave privata usata per firmare i messaggi.
  • Se la chiave è pubblicata, è probabile che si sia verificato un timeout quando Microsoft 365 ha tentato di interrogare il record. Verificare che il valore TTL (Time-to-Live) sia impostato su almeno un'ora.

Una volta che DKIM è configurato e allineato correttamente, i destinatari visualizzano dkim=pass per i tuoi messaggi, il che aiuta anche i messaggi a superare DMARC.

DKIM non riuscito dopo la modifica (firma non verificata)

Questo scenario illustra gli errori DKIM causati dalle modifiche dell'intestazione dopo la firma.

• Intestazione di esempio: dkim=fail (La firma non è stata verificata).
• Significato: il messaggio conteneva una firma DKIM valida, ma la verifica DKIM del messaggio non è riuscita perché un'intestazione inclusa nella firma DKIM è stata modificata in transito dopo la firma. Questa modifica si verifica in genere quando un intermediario (ad esempio, una mailing list, un servizio di inoltro o un'appliance di sicurezza) modifica un'intestazione firmata (ad esempio , Subject:, From:o To:) dopo l'applicazione originale della firma DKIM. Il valore h= nell'intestazione DKIM-Signature identifica i campi di intestazione inclusi nell'hash originale. La modifica di una di queste intestazioni comporta un errore DKIM.
• Chi è responsabile: il mittente o l'intermediario che ha modificato le intestazioni del messaggio. Il mittente originale ha firmato correttamente il messaggio, ma un intermediario potrebbe essere responsabile della firma DKIM interrotta.
• Azione consigliata: non apportare modifiche alle intestazioni dopo la firma di un messaggio da parte di DKIM:
  • Mittenti: verificare che le intestazioni firmate rimangano invariate dal momento in cui il messaggio viene firmato con DKIM fino a prima che lasci l'ambiente.
  • Intermediari: Consenti ai clienti di configurare il tuo servizio come firmatario ARC attendibile per ignorare gli errori DKIM causati dalla modifica dei messaggi durante il transito.

Verifica DKIM non riuscita dopo la modifica (verifica dell'hash del corpo non riuscita)

Questo scenario illustra gli errori DKIM causati dalle modifiche apportate al corpo del messaggio dopo la firma.

• Esempio di intestazione: dkim=fail (errore hash del corpo).
• Significato: il messaggio conteneva una firma DKIM valida, ma la verifica DKIM del messaggio non è riuscita perché il corpo del messaggio è stato modificato in transito dopo la firma. Questa modifica si verifica in genere quando un intermediario (ad esempio, una lista di distribuzione, un servizio di inoltro o un'appliance di sicurezza) modifica il contenuto del corpo del messaggio dopo l'applicazione originale della firma DKIM. Il risultato è che l'hash calcolato dal sistema di posta elettronica ricevente non corrisponde all'hash nella firma DKIM, quindi il controllo DKIM non riesce.
• Chi è responsabile: il mittente o l'intermediario che ha modificato il messaggio. Il mittente originale ha firmato correttamente il messaggio, ma un intermediario potrebbe essere responsabile della firma DKIM interrotta.
• Azione consigliata: assicurarsi che non vengano apportate modifiche impreviste al contenuto del messaggio di posta elettronica dopo la firma:
  • Mittenti: seguire questa procedura:
    • Verificate che le intestazioni firmate rimangano invariate dal momento in cui il messaggio viene firmato con DKIM fino a quando il messaggio non esce dal vostro ambiente.
    • È consigliabile usare Microsoft 365 per applicare modifiche ai messaggi (piè di pagina, dichiarazioni di non responsabilità, oggetto e così via) anziché servizi non Microsoft.
  • Intermediari: Consenti ai clienti di configurare il tuo servizio come firmatario ARC attendibile per ignorare gli errori DKIM causati dalla modifica dei messaggi durante il transito.

Tabella di riferimento rapido per gli scenari di autenticazione tramite posta elettronica

La tabella seguente riepiloga gli scenari di autenticazione della posta elettronica, le soluzioni consigliate e i collegamenti ad articoli pertinenti per altre informazioni.

Il mittente si riferisce agli amministratori del dominio di invio. Il destinatario si riferisce agli amministratori dell'organizzazione ricevente.

Procedure consigliate e suggerimenti

Usare le procedure consigliate seguenti per rafforzare e mantenere l'autenticazione tramite posta elettronica.

• Implementare SPF, DKIM e DMARC: queste tecnologie si integrano a vicenda e offrono una difesa approfondita. Qualsiasi cosa di meno lascia lacune nella protezione.

• Gestisci record DNS: mantenere aggiornati i record SPF con tutte le origini di posta elettronica. Ruotare e gestire le chiavi DKIM in base alle esigenze e monitorare i report DMARC per identificare gli errori di autenticazione.

• Monitora i risultati dell'autenticazione: controlla regolarmente le intestazioni Authentication-Results o usa strumenti o report (ad esempio, le informazioni dettagliate sull'intelligence per lo spoofing di Microsoft 365) per verificare come vengono trattati i messaggi in arrivo. Questa attività può rivelare i partner che non hanno configurato SPF/DKIM o se l'autenticazione del proprio messaggio non riesce.

• Usare ARC per scenari di inoltro: se l'organizzazione esegue l'inoltro di posta elettronica o usa servizi non Microsoft che modificano i messaggi, valutare la possibilità di configurare sealer ARC attendibili in Microsoft 365. ARC consente di mantenere l'autenticazione ed evitare errori falsi durante il transito di messaggi tramite intermediari.

• Prestare attenzione agli elenchi consentiti: quando possibile, affidarsi ai risultati dell'autenticazione standard anziché alle voci consentite dall'organizzazione. Le voci consentite devono essere eccezioni e devono essere controllate periodicamente per rimuovere le voci non necessarie.

• Rimanere informati: seguire queste risorse:

  • Blog di Microsoft Defender per Office 365
  • Blog del team di Exchange
  • Novità di Microsoft Defender per Office 365
  • Centro messaggi di Microsoft 365.