Office 365: Configurare Sender Policy Framework & DomainKeys Identified Mail

Autore: Andrea Gallazzi

Lo standard DKIM (DomainKeys Identified Mail) è una metodologia di crittografia basata su chiave pubblica che funziona in congiunzione con Sender Policy Framework (SPF), prevenendo lo spoofing tramite l’aggiunta di una firma digitale alle intestazioni dei messaggi.

In informatica, per “spoofing” si intende la manipolazione dei dati trasmessi in una rete, consiste nella falsificazione del proprio indirizzo IP, oppure nell’utilizzo abusivo di username e password di altri utenti, o anche nel camuffamento di file nocivi al fine di renderli irriconoscibili.

SPF e DKIM permettono ai mail server di verificare l’autenticità del mittente e validare la posta elettronica in ingresso, valutando correttamente quale identificare come spam e quale invece considerare come legittima. Al fine di evitare che le proprie email vengano erroneamente classificate come spam è fondamentale configurare il proprio dominio implementando alcuni record denominati SPF (Sender Policy Framework) e DKIM (DomainKeys Identified Mail).

Figura 1 – Funzionamento Validazione Mail Server

Entrambi questi record, se configurati correttamente, consentono di implementare una tecnologia di autenticazione che verrà utilizzata dai filtri anti-spam per certificare l’identità del mittente. Il mail server ricevente verificherà il dominio del mittente che risulta nel campo FROM e verificherà quale sia il dominio del mittente nell’header RETURN PATH. Per entrambi, il server interrogherà i rispettivi DNS al fine di verificare che l’IP da cui l’email proviene sia in realtà tra quelli autorizzati. Se questa corrispondenza non viene rispettata, il messaggio verrà rifiutato oppure segnalato come potenziale spam assegnando un punteggio SCL (Spam Confidence Level) più alto. Quando un messaggio di posta elettronica passa attraverso il filtro di posta indesiderata viene assegnato un determinato punteggio. Tale punteggio viene mappato con una classificazione di probabilità di spam (Spam Confidence Level “SCL”) e contrassegnato nell’header con “X-Forefront-Antispam-Report”. Nella tabella seguente viene illustrata la modalità di interpretazione del filtro EOP (Exchange Online Protection) indicando la “Default Action” in base al valore del parametro SCL.

Tabella 1 – Gestione EOP

Il record SPF associato ad un nome di dominio è un parametro molto importante nella configurazione di un server DNS dato che consente di identificare i mail server che sono autorizzati ad inviare per conto del proprio dominio. In assenza dell’applicazione di queste tecniche risulta piuttosto semplice inviare messaggi da indirizzi email falsi, che spesso riportano estensioni uguali a nomi a dominio molto noti o addirittura realmente esistenti.

Per configurare un record SPF è necessario creare un record TXT nel DNS che contenga la sintassi seguente:

v=spf1 ip4:IP include:example.com –all

dove con il comando “ip4” si specificano gli indirizzi IPv4 degli host autorizzati ad inviare email in uscita per un determinato dominio e con il comando “include” si indicano invece eventuali nomi di dominio per cui valgono le medesime regole per il nome di dominio che si sta configurando. Il comando “-all” indica che tutti gli altri server mail, eccetto quelli indicati, non sono autorizzati all’invio. Prendiamo in esempio un’altra tipologia di record SPF:

v=spf1 mx a:mail.example.it include:example.com –all

dove con il comando “mx” si indicano i server riceventi (MX) del dominio che sono autorizzati anche a spedire i messaggi, “a:mail.example.it” indica che la macchina attestata su mail.example.it è autorizzata all’invio, mentre il comando “-all” continua ad indicare che tutti gli altri server mail, eccetto quelli indicati, non sono autorizzati all’invio. Al posto del qualificatore “-“ è possibile utilizzare il qualificatore “~”, che sta ad indicare che sono esclusi dall’autorizzazione tutti gli indirizzi IP non specificati, ma che il messaggio può essere accettato purché venga contrassegnato e il filtro antispam effettui ulteriori controlli sull’IP di provenienza (Soft Fail).

Una configurazione errata del record SPF può portare al rifiuto della gran parte delle email considerate “legittime”.  Per verificare che la configurazione del DNS sia corretta è possibile ricorrere all’utilizzo di strumenti online come ad esempio MXToolBox.

I record DKIM, rappresentano una specie di firma digitale del proprio dominio che viene aggiunta all’intestazione del messaggio. I destinatari delle mail possono verificare che la firma coincida con il nome a dominio dei mittenti “conosciuti” e che non sia stata modificata da eventuali spammer.

Una mail “solo” firmata non è comunque sinonimo di posta elettronica legittima. Configurare SPF e DKIM non sono quindi due tecniche antispam alternative ma piuttosto devono essere implementate contemporaneamente.

DKIM in Office 365

Lo spoofing è una sfida comune che le imprese odierne devono affrontare, che può portare ad un aumento considerevole dello spam e addirittura potrebbe contribuire all’intensificazione del phishing. Al fine di contrastare queste pratiche e fornire un’esperienza utente più sicura, Office 365 supporta la validazione sia in entrata e in uscita di DomainKeys Identified Mail (DKIM) su IPv4/IPv6 e Domain-based Message Authentication, Reporting & Conformance (DMARC).

Per la convalida in entrata, non abbiamo bisogno di fare nulla, dato che Exchange Online Protection (EOP) convalida automaticamente DKIM attraverso l’intestazione DKIM-Signature, come è possibile osservare nell’header di un messaggio inviato verso Office 365 – tabella 2.

Tabella 2 – Esempio Mail in Entrata

Dove “a” corrisponde all’algoritmo di firma, “d” al dominio corrispondente alla firma, “h” alla lista degli header inclusi nella firma mentre “b” alla firma stessa. Se un messaggio fallisce la verifica DKIM, l’intestazione restituirà DKIM = Fail in aggiunta alla ragione del fallimento tra parentesi, tra i motivi: invalid body hash, key query timeout, no key for signature.

Possiamo notare che in “Authentication-Results” si legge anche il valore dkim=pass (signature was verified). Questo perché Microsoft sta aggiungendo ai tenant la firma DKIM alle email in ingresso. Nella tabella 3, prestiamo attenzione alla firma apposta in una email che questa volta è stata inviata da O365 verso Gmail.

Tabella 3 – Mail verso Gmail

Notare che la firma riguarda solamente il nome del tenant in quanto non risulta ancora implementata una firma per il dominio vero e proprio dato che, naturalmente, Microsoft non ha accesso al dominio example.it per poter implementare i record DNS necessari.

Abilitare la Firma DKIM per un Dominio Ospitato su Office 365

Con i servizi di posta elettronica di “terze parti”, abbiamo l’onere di pubblicare la chiave pubblica nel DNS e configurare i server per firmare i messaggi con la propria chiave privata. Una differenza importante nel modo in cui Office 365 implementa DKIM è che i clienti devono solo pubblicare due record CNAME delegando il namespace ad Office 365.

Dunque al fine di consentire la firma dei messaggi in uscita abbiamo bisogno di pubblicare i record CNAME di cui sopra ed illustrati nella tabella 4.

Tabella 4 – Configurazione DNS

Dove <domain_O365_MX> sta ad indicare la prima parte dell’MX attribuito al vostro tenant in Office 365, in questo caso “example-it.mail.protection.outlook.com”, quindi “example-it”. Potete facilmente reperire il nome del vostro MX utilizzando ad esempio mxtoolbox.com (figura 2) e <original_signup_Domain> sta per il dominio assegnato in fase di sottoscrizione del tenant.

Figura 2 – mxtoolbox.com

In figura 3 possiamo osservare i record CNAME configurati dal pannello di gestione del DNS presso l’hoster in cui è ospitato il dominio (selector1-example-it._domainkey.tenatdomain.onmicrosoft.com.).

Figura 3 – Impostazione CNAME Pubblici

I due selettori verranno utilizzati alternativamente per firmare i messaggi in uscita delegando ad EOP la rotazione. Importante ricordare che in un’implementazione DKIM standard, il selettore corrisponde ad un record TXT contenente la chiave pubblica con cui i destinatari valideranno la firma. Essendo Office 365 un ambiente “Hosted”, si rende necessario pubblicare i relativi record CNAME che di fatto reindirizzano le query DNS al “selettore” del dominio <tenant_orginal>.onmicrosoft.com che a sua volta contiene la chiave pubblica. (Figura 8).

Figura 4 – Chiave Pubblica

Come è facile immaginare ogni dominio possiede le proprie e univoche chiavi DKIM che non sono condivise tra i tenant o altri domini all’interno dello stesso tenant. Non resta che connettersi al proprio tenant e abilitare DKIM per il dominio interessato, come mostra la figura 5.

Figura 5 – Attivazione DKIM in Office 365

Nel caso in cui non abbiate configurato a dovere entrambi i record CNAME, riceverete un errore simile a questo: “CNAME record does not exist for this config. Please publish a CNAME record first”. Non rimane che inviare una email verso un altro dominio e verificare che la configurazione implementata sia effettivamente attiva e funzionante.  Analizzando l’header di una email inviata ad un determinato destinatario, tabella 5, si evince che “d” corrisponde al dominio “ufficiale” e che in questo passaggio viene effettivamente usata la chiave corrispondente al dominio “d” example.it.

Tabella 5 – Analisi Header

Continuando ad analizzare l’header, tabella 6, in “Authentication-Results” troviamo la verifica che ci aspettavamo nonché “dkim=pass (signature was verified)”.

Tabella 6 – Analisi Header

Conclusioni

Avere Office 365 non ci rende immuni da rischi di mancato recapito di mail né ci mette al sicuro da falsi positivi, generati da server obsoleti o non in linea con i nuovi standard, ecco perché queste piccole operazioni possono metterci al sicuro nello scambio di mail business.