Configurare Sophos Email Gateway con Exchange on-premises

Con Exchange on-premises, il flusso ha due percorsi distinti: i messaggi in entrata raggiungono prima le destinazioni MX regionali di Sophos e vengono poi consegnati a Exchange. Exchange invia i messaggi in uscita tramite lo smart host Sophos regionale. Configura e verifica separatamente le due direzioni.

Questa guida non riguarda Microsoft 365 né la gestione automatica dei connettori di Sophos Mailflow. Un server Exchange locale richiede connettori di ricezione e invio propri; non replicare a questo scopo i connettori Microsoft 365.

Procedura rapida: registra configurazione attuale e percorso di rollback, configura il dominio in Sophos Central come Inbound and Outbound, limita la ricezione Exchange agli indirizzi IP regionali di consegna Sophos, crea un Send Connector verso l’Outbound Relay Host copiato, traccia entrambe le direzioni e solo dopo disattiva le vecchie route di filtro.

Preparare dati e percorso di rollback

Prima di ogni modifica, registra nel change:

dominio email, ad esempio example.org, e tutti i destinatari da proteggere;
destinazione Exchange pubblicamente raggiungibile come FQDN o indirizzo IP, ad esempio mail.example.org, e porta SMTP realmente usata;
indirizzi IP sorgente pubblici o reti CIDR usati da Exchange in uscita, ad esempio l’indirizzo di documentazione sostituibile 192.0.2.25/32;
destinazioni MX, IP di consegna, Outbound Relay Host e dominio SPF regionali di Sophos dalle dipendenze esterne attuali del tenant;
connettori di ricezione e invio esistenti, ambiti e precedenza, regole firewall e NAT;
valori MX e SPF correnti, inclusi i TTL.

I valori Sophos dipendono dalla regione. Copiali dal tuo tenant Sophos Central e usa gli elenchi correnti di IP di consegna Gateway, record MX, relay host in uscita e domini SPF. Il tenant mostra inoltre il relay in Gateway Domains > dominio > Configure External Dependencies > Outbound Settings. Conserva vecchi valori DNS e impostazioni per il rollback e riduci prima il TTL DNS. Sophos indica che le modifiche ai connettori possono richiedere fino a 24 ore per propagarsi; un test immediato non dimostra la propagazione completa.

Configurare dominio e percorso in entrata

Preparare Sophos Gateway

In Sophos Central vai a Global Settings > Products and Services > Email > Gateway Domains, quindi aggiungi o apri il dominio.
Inserisci dominio, direzione del traffico, destinazione di consegna e relativa porta SMTP. Il flusso completo richiede Inbound and Outbound.
Seleziona Verify Domain Ownership, pubblica il valore TXT specifico del dominio alla radice DNS e seleziona Verify. Come nome usa quello mostrato oppure @.
Prosegui solo dopo la conferma della verifica da parte di Sophos. Un errore indica in genere un valore TXT errato o una propagazione DNS incompleta.
Aggiungi o sincronizza le cassette postali che Sophos Email deve proteggere.

La destinazione di consegna è l’endpoint Exchange pubblicamente raggiungibile, non il nome MX Sophos. FQDN o indirizzo IP e porta devono corrispondere esattamente al servizio SMTP pubblicato e all’inoltro firewall.

Limitare la ricezione Exchange

Sul firewall e sul percorso di ricezione Exchange, consenti come sorgenti della route Sophos solo gli indirizzi IP regionali di consegna Sophos. Ricava gli indirizzi esatti dalle dipendenze esterne attuali del tenant. Ometterne uno può bloccare la consegna; aggiungere una rete estranea o troppo ampia indebolisce la protezione dal bypass.

Nel Receive Connector Exchange usato da Sophos, imposta il binding locale sull’indirizzo IP Exchange locale e sulla porta di ascolto previsti; separatamente, limita gli intervalli IP remoti ai soli IP regionali di consegna Sophos e non usare 0.0.0.0/0. La normale ricezione per destinatari nei domini accettati di Exchange è distinta dal permesso di relay SMTP: non richiede relay generale e questo connettore non deve riceverlo. Se più Receive Connectors si sovrappongono, determina prima del cutover quale corrisponderà a ogni sorgente Sophos.

Verifica prima la raggiungibilità del percorso senza rimuovere la protezione precedente. Sostituisci quindi presso il provider DNS i record MX con le destinazioni MX regionali di Sophos. Ortografia, preferenza e regione devono coincidere esattamente con i valori del tenant.

Configurare il percorso in uscita tramite Sophos

Autorizzare la sorgente in uscita in Sophos

Apri il dominio in Gateway Domains e seleziona Edit.
In Configure Domain, conferma Inbound and Outbound.
In Outbound Gateway, seleziona Custom Gateway.
Aggiungi almeno un indirizzo IP pubblico o una rete CIDR da cui Sophos vedrà realmente le connessioni in uscita, quindi salva. Gli indirizzi Exchange privati dietro NAT non sono qui la sorgente visibile.
Apri Configure External Dependencies > Outbound Settings e copia l’Outbound Relay Host regionale.

Mantieni gli intervalli sorgente più ristretti possibile. Un CIDR inutilmente ampio può autorizzare sistemi estranei; un indirizzo NAT errato causa invece rifiuti di relay.

Cambiare il Send Connector Exchange

In Exchange crea un Send Connector SMTP per destinatari Internet, seleziona Route mail through smart hosts e inserisci con Add l’Outbound Relay Host copiato. Ogni controllo ha uno scopo distinto: gli spazi indirizzi determinano i domini destinatari instradati; i server di trasporto sorgente sono i server Exchange che ospitano il connettore: i messaggi selezionati per il connettore vengono instradati a uno di essi, che stabilisce la consegna allo smart host; il costo risolve i pareggi tra spazi corrispondenti ugualmente specifici; l’opzione scoped limita la disponibilità del connettore nella topologia Exchange al sito Active Directory, non l’instradamento dei destinatari. Segui Microsoft per Exchange 2019, Exchange 2016 o Exchange 2013.

Durante accettazione e cutover, disattiva ogni vecchio Send Connector di filtro i cui spazi indirizzi si sovrappongono a quelli del connettore Sophos, indipendentemente dal suo elenco di server sorgente; conserva la configurazione documentata, non una route concorrente attiva, per il rollback. Se un pilota deve mantenerli entrambi attivi, assegna loro spazi indirizzi realmente non sovrapposti. Elenchi distinti di server sorgente non separano i messaggi in base al server Exchange di origine e non garantiscono un isolamento sicuro. Non affidarti al solo costo: Exchange valuta prima la specificità dello spazio indirizzi. Dopo il test, mantieni disattivato o rimuovi il vecchio connettore sovrapposto.

Verificare SPF, DKIM e le due direzioni

Quando Sophos consegna in uscita, aggiorna l’unico record TXT SPF con il valore regionale dell’elenco Sophos collegato. Una sostituzione solo Sophos ha esattamente la forma v=spf1 include:<spf-domain> -all. Nel funzionamento parallelo conserva tutti i meccanismi autorizzati esistenti e inserisci include:<spf-domain> prima dell’unico all terminale, ad esempio v=spf1 include:old.example include:<spf-domain> -all. Sostituisci <spf-domain> con il valore regionale; non pubblicare mai il placeholder, un secondo all terminale o un secondo record SPF. Scegli -all solo se sei certo che ogni mittente reale sia rappresentato, altrimenti usa ~all. La scelta dipende dalla copertura dei mittenti, non dall’esclusività di Sophos. Verifica DKIM separatamente.

Per i test usa oggetti univoci e registra mittente, destinatario e ora:

Entrata: invia da un dominio esterno a una casella protetta. Il messaggio deve apparire in Sophos Central > Reports > Message History, poi nel tracciamento Exchange e nella casella destinataria.
Uscita: invia da una casella protetta a un dominio esterno. Imposta Message History su outbound, controlla la voce, quindi conferma l’accettazione esterna e il tracciamento Exchange.
Bypass e relay: una consegna diretta a Exchange da una sorgente non autorizzata e un tentativo di relay verso un dominio estraneo non devono essere accettati dal percorso Sophos limitato.

Una voce in un solo sistema non dimostra il successo end-to-end. Correla tracciamento Exchange, cronologia Sophos ed esito del destinatario con timestamp e Message-ID.

Risolvere i problemi con metodo

Messaggio in entrata assente da Sophos: controlla destinazioni MX, preferenza, propagazione DNS e regione. Un vecchio MX può ancora aggirare il gateway.
Visibile in Sophos ma non in Exchange: controlla destinazione e porta, firewall/NAT, IP regionali di consegna Sophos, ambito del Receive Connector e code Exchange. Escludi anche una casella assente da Sophos.
Messaggio in uscita fermo in Exchange: controlla risoluzione DNS e raggiungibilità dell’Outbound Relay Host, Send Connector selezionato, server sorgente e code Exchange.
Relay rifiutato: determina l’IP sorgente pubblico visto da Sophos e confrontalo con i valori IP/CIDR in Custom Gateway. Non ampliare indiscriminatamente l’intervallo.
TLS non riesce: controlla nomi di smart host e destinazione, catena, validità e corrispondenza del certificato e negoziazione TLS supportata da entrambi. Non disattivare stabilmente TLS per nascondere il problema.
Alcuni messaggi usano il vecchio percorso o entrano in loop: controlla sovrapposizione degli spazi dei Send Connectors, costi/precedenza e vecchi connettori di filtro. Anche vecchi MX o relay a monte possono creare un loop.

Dopo ogni correzione ripeti il test della direzione interessata e confronta nuovi timestamp. Se il flusso manca ancora, raccogli Message-ID, intervallo temporale, stato connettore, errore di coda e voce Sophos Message History per l’escalation.

Eseguire un rollback sicuro

Ripristina solo la direzione guasta. Per incidenti in entrata, ripristina i vecchi MX salvati e mantieni attivo il precedente percorso di ricezione finché il DNS non è propagato. Per incidenti in uscita, ripristina prima i meccanismi mittente precedenti salvati unendoli nell’unico record SPF del dominio, mantieni temporaneamente include:<spf-domain> e considera la propagazione DNS prevista dal piano di modifica. Quindi riattiva il precedente Send Connector noto e disattiva senza ambiguità il nuovo Sophos Send Connector, evitando route concorrenti.

Rimuovi le modifiche a firewall e Receive Connector solo quando il percorso in entrata ripristinato funziona in modo dimostrabile. Rimuovi include:<spf-domain> dall’unico record SPF del dominio solo dopo aver convalidato la route in uscita ripristinata, conservando i meccanismi mittente ripristinati. Poi ritesta entrata e uscita, controlla entrambe le code e documenta le cache DNS residue. Il rollback parziale non diventa così un open relay o una seconda route di invio incontrollata.