Autenticazione della posta elettronica nelle organizzazioni cloud

In qualità di organizzazione con cassette postali cloud, è 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 falsificati vengono comunemente usati nelle frodi tramite compromissione della posta elettronica aziendale (BEC), nel phishing e in altri attacchi tramite 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 garantire che il messaggio rimanga inalterato 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).
• Authenticated Received Chain (ARC): preserva le informazioni originali di autenticazione delle email da parte di 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 cloud, 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
• Configurare DMARC per convalidare il dominio dell'indirizzo Da per i mittenti cloud

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.

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

Questo articolo illustra anche perché la posta elettronica Internet richiede l'autenticazione, il modo in cui SPF, DKIM e DMARC interagiscono per autenticare i mittenti di messaggi di posta elettronica, come Microsoft usa l'autenticazione implicita e composita della posta elettronica per controllare la posta in ingresso inviata a Microsoft 365 e come evitare errori di autenticazione della posta elettronica quando si inviano messaggi a Microsoft 365.

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 utilizzato per la 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 indirizzo 5322.From o mittente P2) è l'indirizzo di posta elettronica presente nel campo di intestazione Sa ed è visualizzato nei client di posta elettronica come indirizzo email del mittente.

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

I domini Internet necessitano di SPF, DKIM e DMARC per collaborare per un'autenticazione efficace della posta elettronica.

• SPF: come illustrato in Configurare SPF per identificare origini di posta elettronica valide per i domini cloud personalizzati, SPF usa un record TXT in DNS per:

  • Identificare origini di posta valide dal dominio MAIL FROM.
  • Cosa fare se il server di posta elettronica di destinazione riceve 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.
      • Invia un messaggio email da un'origine valida per il dominio registrato, con indirizzi email nel campo Da appartenenti a 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 non funziona più quando i messaggi passano attraverso l'inoltro delle email a livello di server che reindirizza o ritrasmette 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 cloud, 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 soggetti all'inoltro di posta elettronica basato sul server.

  Poiché la firma DKIM nell'intestazione del messaggio non è interessata o modificata durante l'inoltro della posta elettronica o quando un servizio di hosting usa lo stesso indirizzo MAIL FROM per più domini, questi messaggi sono in grado di 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 spiegato in Configurare DMARC per convalidare il dominio dell'indirizzo From per i mittenti di cassette postali cloud, DMARC utilizza SPF e DKIM per verificare l'allineamento tra i domini degli indirizzi MAIL FROM e From. DMARC specifica anche l'azione che il sistema di posta elettronica di destinazione deve intraprendere sui messaggi che non riescono a DMARC e identifica dove inviare i risultati DMARC (sia pass che fail).

  Come DMARC aiuta SPF e DKIM: Come descritto in precedenza, SPF non tenta di far corrispondere il dominio nel campo MAIL FROM con quello degli indirizzi From. DKIM non verifica se il dominio che ha firmato il messaggio corrisponde al dominio nel campo From.

  DMARC risolve la mancanza di controlli di allineamento del dominio in SPF e DKIM confermando che i domini negli indirizzi MAIL FROM e From corrispondono.

  Problemi di DMARC: i servizi legittimi che modificano i messaggi durante il transito prima della consegna compromettono SPF, DKIM e quindi i controlli DMARC.

  Quando i messaggi vengono inoltrati automaticamente tra domini o organizzazioni, l'allineamento DMARC può non riuscire anche per i mittenti del servizio legittimi. Ad esempio, se un dominio di un servizio Microsoft (come voicemail.microsoft.com) non supera DMARC dopo l'inoltro, usare una voce di autorizzazione con ambito limitato nell'Elenco tenant Consenti/Blocca oppure il relay autenticato, anziché autorizzare l'intero dominio mittente.

• 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 dei destinatari
• Analisi comportamentale.
• Altre tecniche avanzate.

Per leggere l'annuncio originale di Microsoft sull'autenticazione implicita, vedere 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. L'intestazione Authentication-Results è un campo di intestazione del messaggio che registra il risultato dei controlli di autenticazione della posta elettronica. 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 nell'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.

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 come falsificati i messaggi che superano l'autenticazione della posta elettronica oppure identificare come legittimi i messaggi che non superano l'autenticazione della posta elettronica.

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

• 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ò superare l'autenticazione composita, perché il dominio che ha superato il controllo SPF corrisponde al dominio nell'indirizzo del mittente:

  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 con cui DKIM ha firmato il messaggio corrisponde al dominio nell'indirizzo del mittente.

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

• 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

• Configurare record SPF, DKIM e DMARC per i domini: usare le informazioni di configurazione fornite dal registrar o dal servizio di hosting DNS. Sono inoltre disponibili servizi non Microsoft dedicati alla configurazione dei 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, pubblica un record SPF che contenga tutte le fonti email di cui sei a conoscenza (in particolare quelle da cui proviene il traffico aziendale) e usa il valore della regola di applicazione "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 autenticata la posta elettronica in ingresso dall'infrastruttura aziendale. Le email provenienti da fonti non identificate potrebbero comunque essere contrassegnate come spoof se non superano l'autenticazione composita. 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 non bloccanti.

  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 delle email per il tuo dominio, puoi aggiornare il record SPF per impostare il valore del criterio di applicazione "hard fail" (-all).

  3. Configurare DKIM per firmare digitalmente i messaggi.

  4. Configurare DMARC per convalidare i domini negli indirizzi MAIL FROM e From, 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 usi servizi di invio massivo per inviare email per tuo conto, verifica che il dominio nell'indirizzo del mittente corrisponda al dominio che supera i controlli 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.
  • Valutare la firma DKIM della posta in uscita, anche se il cliente non configura esplicitamente DKIM nel proprio dominio (firmando 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 della posta elettronica garantisce che Microsoft non consideri automaticamente come posta indesiderata i messaggi provenienti dai domini dei clienti semplicemente perché non sono autenticati.