Dal gateway antispam direttamente a Microsoft 365.
Un gruppo di laboratori clinici e di genetica riceveva la posta attraverso un gateway antispam in sede e un relay Postfix interno. Dopo un incidente di sicurezza grave abbiamo tolto il gateway e portato tutto su Exchange Online.
La posta in ingresso passava da un gateway antispam on-premise, LibraESVA, e da un relay Postfix interno. Dopo un incidente di sicurezza di massima priorità, in cui il gateway veniva usato come relay SMTP da terzi, il gruppo ha deciso di rimuoverlo. Abbiamo gestito DNS, SPF, DKIM e DMARC su 8 domini, coordinando il fornitore DNS esterno e l'IT del gruppo: il 7 maggio 2026 la posta in ingresso è passata su Exchange Online. La seconda fase riguarda i sistemi interni che inviano posta.
Contesto
Le caselle del gruppo sono su Microsoft 365, ma la posta in ingresso faceva un giro più lungo: dal gateway antispam in sede al relay Postfix interno, poi a Exchange Online. Sullo stesso relay si appoggiano gli strumenti di laboratorio, i server di bioinformatica e il centralino, che alimenta un sistema di BI. I DNS dei domini sono gestiti da un fornitore esterno.
Il problema
Ogni passaggio in più è un punto da proteggere. Già prima dell'incidente avevamo ricondotto alcune email falsificate al relay: accettava qualsiasi mittente esterno e inoltrava anche la posta che falliva i controlli DMARC, come abbiamo dimostrato con test SMTP dal vivo. L'abuso del gateway come relay ha poi reso la decisione inevitabile. Il passaggio però tocca 8 domini, un fornitore DNS esterno e sistemi che inviano posta da anni con le stesse impostazioni: un record sbagliato e la posta legittima si ferma.
Cosa abbiamo fatto
- 01
Prima le prove
Test SMTP dal vivo sul relay per mostrare cosa accettava e cosa inoltrava. Con le evidenze in mano, il gruppo ha potuto decidere su fatti e non su ipotesi.
- 02
Otto domini in ordine
Per ogni dominio MX verso Exchange Online Protection, record SPF rivisti e CNAME DKIM di Microsoft aggiunti. Le modifiche sono passate dal fornitore DNS esterno, coordinate con l'IT del gruppo.
- 03
Cambio in una finestra concordata
Il 7 maggio 2026 la posta in ingresso è passata su Exchange Online, nella finestra stabilita con il gruppo. Il gateway è uscito dal percorso della posta.
- 04
DMARC fino a p=reject
La policy DMARC è salita da p=none a p=reject con pct=100: la posta che finge di arrivare dai domini del gruppo viene respinta.
- 05
I sistemi che inviano
Strumenti di laboratorio, server di bioinformatica e centralino inviano attraverso il relay Postfix: lo smarthost passa dal gateway a Microsoft 365 e su tre sistemi cambia l'indirizzo mittente.
- 06
Un rollback, poi la correzione
Il primo passaggio della posta in uscita, il 16 giugno 2026, è stato annullato perché Microsoft 365 segnava la posta come spam: l'IP pubblico del relay mancava nell'SPF di diversi domini. Lo abbiamo aggiunto su 3 domini e pianificato il nuovo passaggio a settembre 2026.
Com'è andata
La posta in ingresso arriva direttamente su Exchange Online, senza gateway in sede, e i domini respingono i messaggi falsificati. Il rollback del 16 giugno ha protetto la posta dei sistemi interni mentre si correggeva l'SPF: un passaggio si può annullare, la posta finita nello spam dei destinatari no.
Strumenti
Domande frequenti
Con Microsoft 365 serve ancora un gateway antispam?
Non sempre. Exchange Online Protection filtra la posta in ingresso; un gateway in più ha senso solo se aggiunge controlli che servono davvero, e va tenuto aggiornato e chiuso come ogni altro server esposto.
Perché la posta è finita nello spam dopo il cambio?
Perché l'IP da cui partiva non era autorizzato nell'SPF di alcuni domini. Con DMARC in p=reject, un mittente non allineato viene trattato come sospetto anche quando è legittimo.
Cosa cambia per gli strumenti che inviano email?
Continuano a inviare al relay interno, che consegna a Microsoft 365. Cambiano lo smarthost del relay e, dove serve, l'indirizzo mittente.