Condividi tramite

Configurare SPF per identificare origini di posta elettronica valide per il dominio di Microsoft 365

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.

Sender Policy Framework (SPF) è un metodo di autenticazione tramite posta elettronica che consente di convalidare la posta inviata dall'organizzazione di Microsoft 365 per impedire mittenti contraffatti usati in attacchi di compromissione della posta elettronica aziendale, ransomware e altri attacchi di phishing.

Lo scopo principale di SPF è convalidare le origini di posta elettronica per un dominio. In particolare, SPF usa un record TXT in DNS per identificare origini di posta elettronica valide per il dominio. I sistemi di posta elettronica di ricezione usano il record TXT SPF per verificare che l'indirizzo di posta elettronica proveniente dall'indirizzo mittente utilizzato durante la trasmissione SMTP del messaggio (noto come indirizzo MAIL FROM, 5321.MailFrom indirizzo, mittente P1 o mittente della busta) provenirà da un'origine di posta elettronica nota e designata per tale dominio.

Ad esempio, se il dominio di posta elettronica in Microsoft 365 è contoso.com, creare un record TXT SPF in DNS per il dominio contoso.com per identificare Microsoft 365 come origine di posta elettronica autorizzata da contoso.com. I sistemi di posta elettronica di destinazione controllano il record TXT SPF in contoso.com per determinare se il messaggio proviene da un'origine autorizzata per contoso.com posta elettronica.

Prima di iniziare, ecco cosa è necessario sapere su SPF 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): non è necessario eseguire alcuna operazione. Il record TXT SPF è già configurato automaticamente. Microsoft è proprietario del dominio onmicrosoft.com, pertanto è responsabile della creazione e della gestione dei record DNS in tale dominio e sottodominio. 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): il processo di registrazione di Microsoft 365 ha già richiesto di creare o modificare il record TXT SPF in DNS per il dominio personalizzato per identificare Microsoft 365 come origine di posta elettronica autorizzata. Tuttavia, è necessario ancora più lavoro da fare per la massima protezione della posta elettronica:

    • Considerazioni sul sottodominio:

      • Per i servizi di posta elettronica che non sono sotto il controllo diretto (ad esempio, i servizi di posta elettronica in blocco), è consigliabile 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 dai dipendenti nel dominio di posta elettronica principale. Per altre informazioni sull'aggiunta di sottodomini, vedere È possibile aggiungere sottodomini personalizzati o più domini a Microsoft 365?.

      • Ogni sottodominio usato per inviare messaggi di posta elettronica da Microsoft 365 richiede il proprio record TXT SPF. Ad esempio, il record TXT SPF per contoso.com non copre marketing.contoso.com; marketing.contoso.com richiede un record TXT SPF personalizzato.

        Consiglio

        Email protezione dell'autenticazione per sottodomini non definiti è coperta da DMARC. Tutti i sottodomini (definiti o meno) ereditano le impostazioni DMARC del dominio padre (che possono essere sostituite per sottodominio). Per altre informazioni, vedere Configurare DMARC per convalidare il dominio Dell'indirizzo per i mittenti in Microsoft 365.

    • 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 SPF per indicare che nessun messaggio di posta elettronica deve mai provenire da tali domini, come descritto più avanti in questo articolo.

  • SPF da solo non è sufficiente. Per il livello migliore di protezione della posta elettronica per i domini personalizzati, è anche necessario configurare DKIM e DMARC come parte della strategia di autenticazione della posta elettronica complessiva. Per altre informazioni, vedere la sezione Passaggi successivi alla fine di questo articolo.

    Importante

    Nelle organizzazioni complesse in cui è difficile identificare tutte le origini di posta valide per il dominio, è importante configurare rapidamente la firma DKIM e DMARC (in modalità "non eseguire alcuna azione") per il dominio. Un servizio di report DMARC è molto utile per identificare le origini di posta elettronica e gli errori SPF per il dominio.

Il resto di questo articolo descrive i record TXT SPF che è necessario creare per i domini personalizzati in Microsoft 365.

Consiglio

Non sono disponibili portali di amministrazione o cmdlet di PowerShell in Microsoft 365 per gestire i record SPF nel dominio. Si crea invece il record TXT SPF 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. È possibile usare queste istruzioni come punto di partenza per creare il valore del record TXT SPF. 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 SPF

I record TXT SPF sono descritti in modo esaustivo in RFC 7208.

La sintassi di base del record TX SPF per un dominio personalizzato in Microsoft 365 è la seguente:

v=spf1 <valid mail sources> <enforcement rule>

Oppure:

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

Ad esempio:

v=spf1 ip4:192.168.0.10 ip4:192.168.0.12 include:spf.protection.outlook.com -all

  • v=spf1 identifica il record TXT come record TXT SPF.

  • Origini di posta valide: specifica origini di posta valide per il dominio. Usa domini, indirizzi IP o entrambi:

    • Domini: include: i valori specificano altri servizi o domini come origini di posta elettronica valide dal dominio originale. Questi valori in definitiva portano a un indirizzo IP usando ricerche DNS.

      La maggior parte delle organizzazioni di Microsoft 365 richiede include:spf.protection.outlook.com nel record TXT SPF per il dominio. Altri servizi di posta elettronica di terze parti spesso richiedono un valore aggiuntivo include: per identificare il servizio come origine valida di posta elettronica dal dominio originale.

    • Indirizzi IP: un valore di indirizzo IP include entrambi gli elementi seguenti:

      • Valore ip4: o ip6: per identificare il tipo di indirizzo IP.
      • Indirizzo IP risolvibile pubblicamente del sistema di posta elettronica di origine. Ad esempio:
        • Un singolo indirizzo IP , ad esempio 192.168.0.10.
        • Intervallo di indirizzi IP che usa la notazione CIDR (Classless Inter-Domain Routing), ad esempio 192.168.0.1/26. Assicurarsi che l'intervallo non sia troppo grande o troppo piccolo.

      In Microsoft 365 in genere si usano gli indirizzi IP nel record TXT SPF solo se si dispone di server di posta elettronica locali che inviano messaggi di posta elettronica dal dominio di Microsoft 365 (ad esempio, Exchange Server distribuzioni ibride). Alcuni servizi di posta elettronica di terze parti potrebbero anche usare un intervallo di indirizzi IP anziché un include: valore nel record TXT SPF.

  • Regola di imposizione: indica ai sistemi di posta elettronica di destinazione cosa fare con i messaggi provenienti da origini non specificate nel record TXT SPF per il dominio. I valori validi sono:

    • -all (hard fail): le origini non specificate nel record TXT SPF non sono autorizzate a inviare messaggi per il dominio, pertanto 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.

      Per i domini di Microsoft 365, è consigliabile -all (hard fail) perché è anche consigliabile usare DKIM e DMARC per il dominio. I criteri DMARC specificano le operazioni da eseguire per i messaggi che hanno esito negativo su SPF o DKIM e i report DMARC consentono di convalidare i risultati.

      Consiglio

      Come indicato in precedenza, DMARC configurato con un servizio di report DMARC consente di identificare in modo significativo le origini di posta elettronica e gli errori SPF per il dominio.

    • ~all (soft fail): le origini non specificate nel record TXT SPF probabilmente non sono autorizzate a inviare messaggi per il dominio, quindi 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.

      Poiché è consigliabile anche DKIM e DMARC per i domini di Microsoft 365, le differenze tra -all (hard fail) e ~all (soft fail) vengono eliminate in modo efficace (DMARC considera entrambi i risultati come un errore SPF). DMARC usa SPF per confermare l'allineamento dei domini negli indirizzi MAIL FROM e From e il messaggio proviene da un'origine valida per il dominio Da.

    Consiglio

    ?all (neutrale) è disponibile anche per suggerire alcuna azione specifica sui messaggi provenienti da origini non identificate. Questo valore viene usato per il test e non è consigliabile usare questo valore negli ambienti di produzione.

Punti importanti da ricordare:

  • Ogni dominio o sottodominio definito in DNS richiede un record TXT SPF e è consentito un solo record SPF per dominio o sottodominio. Email protezione dell'autenticazione per sottodomini non definiti è gestita al meglio da DMARC.
  • Non è possibile modificare il record TXT SPF esistente per il dominio *.onmicrosoft.com.
  • Quando il sistema di posta elettronica di destinazione controlla le origini di posta elettronica valide nel record SPF, la convalida SPF non riesce se il controllo richiede troppe ricerche DNS. Per altre informazioni, vedere la sezione Risoluzione dei problemi relativi ai record TXT SPF più avanti in questo articolo.

Record TXT SPF per domini personalizzati in Microsoft 365

Consiglio

Come indicato in precedenza in questo articolo, si crea il record TXT SPF per un dominio o un sottodominio nel registrar per il dominio. In Microsoft 365 non è disponibile alcuna configurazione del record TXT SPF.

  • Scenario: si usa contoso.com per la posta elettronica in Microsoft 365 e Microsoft 365 è l'unica origine di posta elettronica da contoso.com.

    Record TXT SPF per contoso.com in Microsoft 365 e Microsoft 365 Government Community Cloud (GCC):

    v=spf1 include:spf.protection.outlook.com -all

    Record TXT SPF per contoso.com in Microsoft 365 Government Community Cloud High (GCC High) e Microsoft 365 Department of Defense (DoD):

    v=spf1 include:spf.protection.office365.us -all

    Record TXT SPF per contoso.com in Microsoft 365 gestito da 21Vianet

    v=spf1 include:spf.protection.partner.outlook.cn -all

  • Scenario: si usa contoso.com per la posta elettronica in Microsoft 365 ed è già stato configurato il record TXT SPF in contoso.com con tutte le origini di posta elettronica dal dominio. Si possiedono anche i domini contoso.net e contoso.org, ma non vengono usati per la posta elettronica. Si vuole specificare che nessuno è autorizzato a inviare messaggi di posta elettronica da contoso.net o contoso.org.

    Record TXT SPF per contoso.net:

    v=spf1 -all

    Record TXT SPF per contoso.org:

    v=spf1 -all

  • Scenario: si usa contoso.com per la posta elettronica in Microsoft 365. Si prevede di inviare messaggi di posta elettronica dalle origini seguenti:

    • Server di posta elettronica locale con indirizzo di posta elettronica esterno 192.168.0.10. Poiché si ha il controllo diretto su questa origine di posta elettronica, è consigliabile usare il server per i mittenti nel dominio contoso.com.
    • Servizio di posta elettronica bulk Adatum. Poiché non si ha il controllo diretto su questa origine di posta elettronica, è consigliabile usare un sottodominio, quindi creare marketing.contoso.com a tale scopo. In base alla documentazione del servizio Adatum, è necessario aggiungere include:servers.adatum.com al record TXT SPF per il dominio.

    Record TXT SPF per contoso.com:

    v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all

    Record TXT SPF per marketing.contoso.com:

    v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all

Risoluzione dei problemi relativi ai record TXT SPF

  • Un record SPF per dominio o sottodominio: più record TXT SPF per lo stesso dominio o sottodominio causano un ciclo di ricerca DNS che causa l'esito negativo di SPF, quindi usare un solo record SPF per dominio o sottodominio.

  • Meno di 10 ricerche DNS: quando i sistemi di posta elettronica di destinazione eseguono query sul record TXT SPF per individuare origini valide per il dominio dell'indirizzo MAIL FROM, la query analizza gli indirizzi IP e include: le istruzioni nel record fino a quando l'origine del messaggio (in definitiva, un indirizzo IP) non corrisponde a una delle origini specificate. Se il numero di ricerche DNS (che possono essere diverse dal numero di query DNS) è maggiore di 10, il messaggio non riesce SPF con un errore permanente (noto anche come permerror). Il sistema di posta elettronica di destinazione rifiuta il messaggio in un report di mancato recapito (noto anche come NDR o messaggio di mancato recapito) con uno degli errori seguenti:

    • Il messaggio ha superato il numero massimo di hop.
    • Il messaggio ha richiesto un numero eccessivo di ricerche.

    Nel record TXT SPF i singoli indirizzi IP o intervalli di indirizzi IP non causano ricerche DNS. Ogni include: istruzione richiede almeno una ricerca DNS e potrebbero essere necessarie altre ricerche se il include: valore punta a risorse annidate. In altre parole, avere meno di 10 include: istruzioni non garantisce meno di 10 ricerche DNS.

    Tenere presente anche che i sistemi di posta elettronica di destinazione valutano le origini nel record TXT SPF da sinistra a destra. La valutazione si interrompe quando viene convalidata l'origine del messaggio e non vengono controllate altre origini. Di conseguenza, un record TXT SPF potrebbe contenere informazioni sufficienti per causare più di 10 ricerche DNS, ma la convalida di alcune origini di posta elettronica da parte di alcune destinazioni non viene sufficientemente approfondita nel record per generare un errore.

    Oltre a preservare la reputazione del dominio di posta elettronica principale, non superare il numero di ricerche DNS è un altro motivo per usare sottodomini per altri servizi di posta elettronica che non si controllano.

È possibile usare strumenti online gratuiti per visualizzare il record TXT SPF e altri record DNS per il dominio. Alcuni strumenti calcolano anche il numero di ricerche di record DNS richieste dal record TXT SPF.

Operazioni successive

Come descritto in Come SPF, DKIM e DMARC interagiscono per autenticare i mittenti dei messaggi di posta elettronica, SPF da solo non è sufficiente per impedire lo spoofing del dominio di Microsoft 365. È anche necessario configurare DKIM e DMARC per la migliore protezione possibile. Per istruzioni, vedere:

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.