Autenticazione della posta elettronica in Microsoft 365

Consiglio

Sapevi che puoi provare le funzionalità in Microsoft Defender XDR gratuitamente 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 dettagliate su chi può iscriversi e condizioni di provaqui.

Poiché un'organizzazione di Microsoft 365 con cassette postali in Exchange Online o un'organizzazione autonoma Exchange Online Protection (EOP) senza cassette postali Exchange Online, è importante proteggere l'integrità dei messaggi di posta elettronica dai mittenti nei domini. I destinatari devono essere certi che i messaggi provenienti dai mittenti del dominio provenivano effettivamente dai mittenti del dominio.

Email l'autenticazione (nota anche come convalida della posta elettronica) è un gruppo di standard per identificare e impedire il recapito di messaggi di posta elettronica da mittenti contraffatti (noto anche come spoofing). I mittenti spoofing sono comunemente usati in attacchi di compromissione della posta elettronica aziendale (BEC), phishing e altri attacchi di posta elettronica. Questi standard includono:

  • Sender Policy Framework (SPF): specifica i server di posta elettronica di origine autorizzati a inviare messaggi di posta elettronica per il dominio.
  • DomainKeys Identified Mail (DKIM): usa un dominio per firmare digitalmente elementi importanti del messaggio per assicurarsi che il messaggio non sia stato modificato durante il transito.
  • Autenticazione dei messaggi basata su dominio, creazione di report e conformità (DMARC): specifica l'azione per i messaggi che non soddisfano i controlli SPF o DKIM per i mittenti nel dominio e specifica dove inviare i risultati DMARC (report).
  • Catena ricevuta autenticata (ARC): mantiene le informazioni di autenticazione della posta elettronica originali dai servizi noti che modificano i messaggi in transito. Il server di posta elettronica di destinazione può usare queste informazioni per autenticare i messaggi che altrimenti avrebbero esito negativo in DMARC.

È importante rendersi conto che questi standard sono blocchi predefiniti interdipendenti che interagiscono per offrire la migliore protezione possibile dalla posta elettronica dagli attacchi di spoofing e phishing. Qualsiasi valore inferiore a tutti i metodi di autenticazione della posta elettronica comporta una protezione non standard.

Per configurare l'autenticazione tramite posta elettronica per la posta inviata da organizzazioni di Microsoft 365 con cassette postali in organizzazioni Exchange Online o autonome Exchange Online Protection (EOP) senza cassette postali Exchange Online, vedere gli articoli seguenti:

Per evitare errori di autenticazione della posta elettronica dovuti ai servizi che modificano la posta in ingresso inviata all'organizzazione di Microsoft 365, vedere Configurare sealer ARC attendibili.

Il resto di questo articolo spiega:

Perché la posta elettronica Internet richiede l'autenticazione

Per impostazione predefinita, la posta elettronica SMTP (Simple Mail Transfer Protocol) su Internet non fa alcuno sforzo per verificare che il mittente del messaggio sia quello che dichiara di essere.

Un messaggio di posta elettronica SMTP standard è costituito da una busta del messaggio e dal contenuto del messaggio:

  • La busta del messaggio contiene informazioni per la trasmissione e la ricezione del messaggio tra server SMTP. La busta del messaggio è descritta in RFC 5321. I destinatari non vedono mai la busta del messaggio perché viene generata durante il processo di trasmissione del messaggio.
  • Il contenuto del messaggio include i campi di intestazione del messaggio (denominati collettivamente intestazione del messaggio) e il corpo del messaggio. L'intestazione del messaggio è descritta in RFC 5322.

A causa di questa progettazione, un messaggio ha più valori del mittente:

  • L'indirizzo MAIL FROM (noto anche come 5321.MailFrom indirizzo, mittente P1 o mittente della busta) è l'indirizzo di posta elettronica usato nella trasmissione del messaggio tra server di posta elettronica SMTP. Questo indirizzo viene in genere registrato nel campo intestazione Return-Path nell'intestazione del messaggio (anche se il server di posta elettronica di origine può designare un indirizzo di posta elettronica Return-Path diverso). Questo indirizzo di posta elettronica viene usato nei report di mancato recapito (noti anche come rapporti di mancato recapito o messaggi di mancato recapito).
  • L'indirizzo Da (noto anche come 5322.From indirizzo o mittente P2) è l'indirizzo di posta elettronica nel campo Intestazione Da ed è l'indirizzo di posta elettronica del mittente visualizzato nei client di posta elettronica.

L'esempio seguente illustra la trascrizione semplificata di una trasmissione di messaggi valida tra due server di posta elettronica SMTP:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

In questo esempio:

  • Il server di posta elettronica di origine si identifica come woodgrovebank.com al server di posta elettronica di destinazione tailspintoys.com nel comando HELO.
  • Il destinatario del messaggio è astobes@tailspintoys.com.
  • L'indirizzo MAIL FROM nella busta del messaggio (usato per trasmettere il messaggio tra server di posta elettronica SMTP) è dubious@proseware.com.
  • L'indirizzo From visualizzato nel client di posta elettronica del destinatario è security@woodgrovebank.com.

Anche se questo messaggio è valido in base a SMTP, il dominio dell'indirizzo MAIL FROM (proseware.com) non corrisponde al dominio nell'indirizzo From (woodgrovebank.com). Questo messaggio è un classico esempio di spoofing, in cui è probabile che la finalità ingannerà il destinatario mascherando la vera origine del messaggio da usare in un attacco di phishing.

Chiaramente, l'e-mail SMTP deve essere utile per verificare che i mittenti dei messaggi siano quelli che dichiarano di essere.

Funzionamento di SPF, DKIM e DMARC per autenticare i mittenti dei messaggi di posta elettronica

Questa sezione descrive perché sono necessari SPF, DKIM e DMARC per i domini su Internet.

  • SPF: come illustrato in Configurare SPF per identificare origini di posta elettronica valide per il dominio di Microsoft 365, SPF usa un record TXT in DNS per identificare le origini di posta elettronica valide dal dominio MAIL FROM e cosa fare se il server di posta elettronica di destinazione riceve la posta da un'origine non definita ('hard fail' per rifiutare il messaggio; 'soft fail' per accettare e contrassegnare il messaggio).

    Problemi di SPF:

    • SPF convalida le origini solo per i mittenti nel dominio MAIL FROM. SPF non considera il dominio nell'indirizzo From o nell'allineamento tra i domini MAIL FROM e From:

      • Un utente malintenzionato può inviare un messaggio di posta elettronica che supera l'autenticazione SPF (falso negativo) seguendo questa procedura:
        • Registrare un dominio (ad esempio, proseware.com) e configurare SPF per il dominio.
        • Inviare un messaggio di posta elettronica da un'origine valida per il dominio registrato, con gli indirizzi di posta elettronica Da in un dominio diverso , ad esempio woodgrovebank.com.
      • Un servizio di posta elettronica legittimo che invia posta per conto di altri domini potrebbe controllare l'indirizzo MAIL FROM. Gli altri domini e il dominio MAIL FROM non corrispondono, quindi i messaggi non possono passare l'autenticazione SPF (un falso positivo).

    • SPF si interrompe dopo che i messaggi riscontrano l'inoltro di posta elettronica basato sul server che reindirizza o inoltra i messaggi.

      • L'inoltro di posta elettronica basato sul server modifica l'origine del messaggio dal server originale al server di inoltro.
      • Il server di inoltro non è autorizzato a inviare posta dal dominio MAIL FROM originale, quindi il messaggio non può passare l'autenticazione SPF (falso positivo).

    • Ogni dominio e qualsiasi sottodominio richiedono i propri singoli record SPF. I sottodomini non ereditano il record SPF del dominio padre. Questo comportamento diventa problematico se si vuole consentire la posta elettronica da sottodomini definiti e usati, ma impedire alla posta elettronica di sottodomini indefiniti e inutilizzati.

  • DKIM: come illustrato in Configurare DKIM per firmare la posta elettronica dal dominio di Microsoft 365, DKIM usa un dominio per firmare digitalmente elementi importanti del messaggio (incluso l'indirizzo Da) e archivia la firma nell'intestazione del messaggio. Il server di destinazione verifica che gli elementi firmati del messaggio non siano stati modificati.

    Come DKIM aiuta SPF: DKIM può convalidare i messaggi che hanno esito negativo SPF. Ad esempio:

    • Messaggi provenienti da un servizio di hosting di posta elettronica in cui viene usato lo stesso indirizzo MAIL FROM per la posta da altri domini.
    • Messaggi che riscontrano l'inoltro di posta elettronica basato su server.

    Poiché la firma DKIM nell'intestazione del messaggio non è interessata o modificata in questi scenari, questi messaggi possono passare DKIM.

    Problemi DKIM: il dominio usato da DKIM per firmare un messaggio non deve corrispondere al dominio nell'indirizzo Da visualizzato nei client di posta elettronica.

    Analogamente a SPF, un utente malintenzionato può inviare messaggi di posta elettronica che passano l'autenticazione DKIM (un falso negativo) seguendo questa procedura:

    • Registrare un dominio (ad esempio, proseware.com) e configurare DKIM per il dominio.
    • Inviare un messaggio di posta elettronica con gli indirizzi di posta elettronica From in un dominio diverso, ad esempio woodgrovebank.com.

  • DMARC: come illustrato in Configurare DMARC per convalidare il dominio Indirizzo da per i mittenti in Microsoft 365, DMARC usa SPF e DKIM per verificare l'allineamento tra i domini negli indirizzi MAIL FROM e From. DMARC specifica anche l'azione che il sistema di posta elettronica di destinazione deve eseguire sui messaggi che hanno esito negativo di DMARC e identifica dove inviare i risultati DMARC (sia pass che fail).

    Come DMARC aiuta SPF e DKIM: come descritto in precedenza, SPF non esegue alcun tentativo di corrispondenza con il dominio MAIL FROM e dagli indirizzi. DKIM non si preoccupa se il dominio che ha firmato il messaggio corrisponde al dominio nell'indirizzo Da.

    DMARC risolve queste carenze usando SPF e DKIM per verificare che i domini negli indirizzi MAIL FROM e From corrispondano.

    Problemi di DMARC: servizi legittimi che modificano i messaggi in transito prima dell'interruzione del recapito SPF, DKIM e quindi controlli DMARC.

  • ARC: come illustrato in Configurare sealer ARC attendibili, i servizi legittimi che modificano i messaggi in transito possono usare ARC per mantenere le informazioni di autenticazione della posta elettronica originali dei messaggi modificati.

    Come ARC aiuta DMARC: il sistema di posta elettronica di destinazione può identificare il servizio come sealer ARC attendibile. ARC può quindi usare le informazioni di autenticazione della posta elettronica conservate per convalidare il messaggio.

Autenticazione della posta elettronica in ingresso per la posta inviata a Microsoft 365

A causa di problemi di phishing e dell'adozione non completa dei criteri di autenticazione della posta elettronica avanzata da parte dei mittenti di posta elettronica su Internet, Microsoft 365 usa l'autenticazione implicita della posta elettronica per controllare la posta elettronica in ingresso. L'autenticazione tramite posta elettronica implicita estende i normali controlli SPF, DKIM e DMARC usando segnali provenienti da altre origini per valutare la posta elettronica in ingresso. Queste origini includono:

  • Reputazione del mittente.
  • Cronologia del mittente.
  • Cronologia destinatari.
  • Analisi comportamentale.
  • Altre tecniche avanzate.

Per visualizzare l'annuncio originale di Microsoft sull'autenticazione implicita, vedere A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365.To see Microsoft's original announcement about implicit authentication, see A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365.

Usando questi altri segnali, i messaggi che altrimenti non riuscirebbero a controllare l'autenticazione della posta elettronica tradizionale possono passare l'autenticazione implicita ed essere consentiti in Microsoft 365.

Autenticazione composita

I risultati dei controlli di autenticazione implicita di Microsoft 365 vengono combinati e archiviati in un singolo valore denominato autenticazione composita o compauth in breve. Il valore compauth viene indicato nell'intestazione Authentication-Results nelle intestazioni dei messaggi. L'intestazione Authentication-Results usa la sintassi seguente:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Questi valori sono spiegati in Intestazione del messaggio Authentication-results.

Gli amministratori e gli utenti possono esaminare le intestazioni dei messaggi per scoprire in che modo Microsoft 365 ha identificato il mittente come mittente sospetto o legittimo.

Consiglio

È importante comprendere che un errore di autenticazione composita non comporta direttamente il blocco di un messaggio. Il sistema usa una strategia di valutazione olistica che considera la natura sospetta complessiva di un messaggio insieme ai risultati dell'autenticazione composita. Questo metodo è progettato per attenuare il rischio di bloccare erroneamente la posta elettronica legittima da domini che potrebbero non essere strettamente conformi ai protocolli di autenticazione della posta elettronica. Questo approccio bilanciato consente di distinguere la posta elettronica autenticamente dannosa dai mittenti dei messaggi che semplicemente non sono conformi alle procedure standard di autenticazione della posta elettronica.

Gli esempi seguenti si concentrano solo sui risultati dell'autenticazione tramite posta elettronica (il valore e il compauth motivo). Altre tecnologie di protezione di Microsoft 365 possono identificare i messaggi che passano l'autenticazione tramite posta elettronica come spoofing o identificare i messaggi che non eseguono l'autenticazione tramite posta elettronica come legittimi.

  • Scenario: il dominio nel record SPF o nella firma DKIM non corrisponde al dominio nell'indirizzo Da.

  • Risultato: il messaggio può non riuscire con l'autenticazione composita. Nonostante l'errore di autenticazione composita, il messaggio potrebbe essere comunque consentito se altre valutazioni non indicano una natura sospetta:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • Scenario: il dominio fabrikam.com non ha record SPF, DKIM o DMARC.

  • Risultato: i messaggi provenienti da mittenti nel dominio fabrikam.com possono non riuscire con l'autenticazione composita:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scenario: il dominio fabrikam.com ha un record SPF e nessun record DKIM. I domini negli indirizzi MAIL FROM e From corrispondono.

  • Risultato: il messaggio può passare l'autenticazione composita, perché il dominio che ha passato SPF corrisponde al dominio nell'indirizzo Da:

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scenario: il dominio fabrikam.com ha un record DKIM senza un record SPF. Il dominio che DKIM ha firmato il messaggio corrisponde al dominio nell'indirizzo Da.

  • Risultato: il messaggio può passare l'autenticazione composita, perché il dominio nella firma DKIM corrisponde al dominio nell'indirizzo Da:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scenario: il dominio nel record SPF o nella firma DKIM non corrisponde al dominio nell'indirizzo Da.

  • Risultato: il messaggio può non riuscire con l'autenticazione composita:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Come evitare errori di autenticazione della posta elettronica durante l'invio di posta elettronica a Microsoft 365

Consiglio

I clienti di Microsoft 365 possono usare i metodi seguenti per consentire i messaggi provenienti da mittenti identificati come errori di spoofing o autenticazione:

  • Configurare record SPF, DKIM e DMARC per i domini: usare le informazioni di configurazione fornite dal registrar o dal servizio di hosting DNS. Ci sono anche società di terze parti dedicate ad aiutare a configurare i record di autenticazione della posta elettronica.

    Molte aziende non pubblicano record SPF perché non conoscono tutte le origini di posta elettronica per i messaggi nel proprio dominio.

    1. Per iniziare, pubblicare un record SPF che contiene tutte le origini di posta elettronica note (in particolare dove si trova il traffico aziendale) e usare il valore della regola di imposizione "soft fail" (~all). Ad esempio:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Se si crea questo record SPF, Microsoft 365 considera la posta elettronica in ingresso dall'infrastruttura aziendale come autenticata, ma la posta elettronica proveniente da origini non identificate potrebbe comunque essere contrassegnata come spoofing se l'autenticazione composita non riesce. Tuttavia, questo comportamento è ancora un miglioramento rispetto a tutti i messaggi di posta elettronica provenienti dai mittenti nel dominio contrassegnati come spoofing da Microsoft 365. In genere, il sistema di posta elettronica di destinazione accetta messaggi da mittenti nel dominio da origini non identificate quando SPF è configurato con una regola di imposizione degli errori soft.

    2. Individuare e includere altre origini di posta elettronica per i messaggi. Ad esempio:

      • Server di posta elettronica locali.
      • Messaggi di posta elettronica inviati da un provider di software come un servizio (SaaS).
      • Messaggi di posta elettronica inviati da un servizio di hosting cloud (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services e così via).

      Dopo aver identificato tutte le origini di posta elettronica per il dominio, è possibile aggiornare il record SPF per usare il valore della regola di imposizione "hard fail" (-all).

    3. Configurare DKIM per firmare digitalmente i messaggi.

    4. Configurare DMARC per verificare che i domini negli indirizzi MAIL FROM e From corrispondano, per specificare cosa fare con i messaggi che non superano i controlli DMARC (rifiuto o quarantena) e per identificare i servizi di report per monitorare i risultati di DMARC.

    5. Se si usano mittenti bulk per inviare messaggi di posta elettronica per conto dell'utente, verificare che il dominio nell'indirizzo Da corrisponda al dominio che passa SPF o DMARC.

  • Si ospita la posta elettronica di un dominio o si fornisce un'infrastruttura di hosting in grado di inviare messaggi di posta elettronica:

    • Assicurarsi che i clienti dispongano di documentazione che spiega come configurare SPF per i propri domini.
    • Prendere in considerazione la firma DKIM di posta in uscita DKIM, anche se il cliente non configura in modo esplicito DKIM nel proprio dominio (firma con un dominio predefinito). È anche possibile firmare due volte il messaggio di posta elettronica con firme DKIM (con il dominio aziendale e il dominio del cliente se/quando è disponibile).

    La consegna a Microsoft non è garantita, anche se si autenticano messaggi di posta elettronica provenienti dalla piattaforma. Tuttavia, l'autenticazione tramite posta elettronica garantisce che Microsoft non esegua automaticamente la posta indesiderata dai domini dei clienti semplicemente perché non è autenticata.