Contenuto informativo basato su fonti istituzionali. L’applicazione concreta richiede una valutazione del contesto, del rischio e della normativa vigente.
Disegnare il flusso prima di creare connettori
La maggior parte delle organizzazioni Microsoft 365 non necessita di connettori per il flusso ordinario. Diventano necessari in scenari con server locali, partner, dispositivi o servizi cloud che filtrano, archiviano, firmano o trasformano i messaggi. Prima della configurazione bisogna rappresentare ogni passaggio in ingresso e in uscita.
Per ogni hop vanno documentati MX, smart host, certificati, IP, domini, regole di trasporto, responsabilità e comportamento in caso di indisponibilità. Un connettore non è soltanto routing: può imporre TLS, certificati o indirizzi ammessi e rifiutare messaggi che non rispettano le condizioni.
- Origine e destinazione di ogni passaggio
- Modifiche applicate al messaggio
- Identità usata per autenticare il servizio
- Percorso normale e percorso di emergenza
- Proprietario e procedura di verifica
Preservare segnali e autenticazione
Quando un filtro terzo precede Exchange Online, l'indirizzo visto dalla piattaforma può essere quello del servizio e non del mittente originario. Microsoft raccomanda Enhanced Filtering for Connectors nei relativi scenari, così da preservare i segnali utili a SPF, spoofing, anti-phishing e indagini.
I servizi che modificano il messaggio possono invalidare DKIM. Authenticated Received Chain può conservare i risultati di autenticazione attraverso intermediari fidati, ma il sealer deve essere valutato e configurato esplicitamente. Non va creato un bypass ampio basato su IP condivisi: potrebbe sottrarre messaggi ostili ai controlli previsti.
- Enhanced Filtering dove il routing nasconde l'origine
- Trusted ARC sealer soltanto per intermediari valutati
- TLS e restrizioni sul connettore
- Nessun bypass generico dei controlli antispam
- Verifica di SPF, DKIM e DMARC dopo le trasformazioni
Applicazioni, dispositivi e fornitori che inviano
Stampanti, gestionali e piattaforme SaaS devono usare uno scenario di invio supportato e coerente con i requisiti. Autenticazione client, SMTP relay e invio diretto hanno capacità e limiti differenti. La scelta dipende da destinatari, TLS, indirizzo mittente, disponibilità di credenziali e supporto del dispositivo.
Ogni nuovo servizio che usa il dominio richiede una revisione di SPF, DKIM e DMARC. Se il fornitore può firmare con un sottodominio dedicato, si separano meglio reputazione e gestione. Dopo l'attivazione si controllano intestazioni, tracciamento, consegna esterna, bounce, forwarding e report; alla dismissione si rimuovono autorizzazioni DNS, connettori e credenziali.
- Scenario Microsoft supportato e minimo privilegio
- Sottodominio dedicato quando opportuno
- Test su destinatari interni ed esterni
- Tracciamento e logging disponibili
- Procedura di uscita dal servizio
Domande frequenti
Ogni servizio esterno richiede un connettore?+
No. Dipende dallo scenario. Molti flussi standard non richiedono connettori; server, partner, filtri o servizi che modificano e reinstradano la posta possono richiederli.
Perché un filtro esterno può ridurre l'efficacia dei controlli Microsoft?+
Se nasconde l'origine reale o si applicano bypass troppo ampi, Exchange Online perde segnali utili. Enhanced Filtering e restrizioni corrette aiutano a preservare l'analisi.
ARC corregge automaticamente ogni problema DKIM o DMARC?+
No. ARC conserva una catena di risultati attraverso intermediari, ma richiede sealers fidati e non sostituisce una corretta configurazione di DKIM, DMARC, routing e connettori.