Problema di posta elettronica a livello di tenant

Nota: Questa risposta è stata tradotta automaticamente. Di conseguenza, può contenere errori grammaticali o espressioni strane.

Ciao @Pierpaolo Casarola

Innanzitutto voglio fare una breve nota: non siamo il Supporto Microsoft, questo è un forum da utente a utente. I moderatori non hanno accesso al backend e non possono intervenire direttamente nei servizi Microsoft; possiamo solo fornire indicazioni e raccomandazioni sulle migliori pratiche basate sull'esperienza.

Capisco che questo comportamento di inoltro sembri insolito. Poiché hai selezionato il tag Exchange Server, verifichiamo alcune cose sul tuo server Exchange. Se possibile, potresti anche confermare quale versione stai utilizzando (ad esempio, Exchange Server 2016 o 2019)?

1> Controlla i registri di tracciamento dei messaggi di Exchange: Esegui il seguente comando PowerShell sul tuo server Exchange per cercare i messaggi inoltrati inviati a COMMERCIALE@<dominio2> entro il periodo di tempo rilevante:

Get-MessageTrackingLog -Recipients COMMERCIALE@dominio2 -Start "2026-05-20 00:00:00" -End "2026-05-25 00:00:00" -MessageSubject "<subject snippet if known>" | ft Timestamp, EventId, Source, MessageSubject, RecipientStatus

Esamina l'output per eventuali voci dei messaggi inoltrati. Se le trovi, annota l'EventId. Ad esempio, se vedi un evento RECEIVE seguito da un DELETE o FAIL, ciò potrebbe indicare un'azione del filtro antispam. (Ad esempio, l'eliminazione da parte di un filtro dei contenuti potrebbe mostrare un motivo come "Messaggio eliminato dall'agente del filtro dei contenuti" o "Filtrato come Spam".) Se non ci sono voci del registro di tracciamento per i messaggi inoltrati, ciò potrebbe significare che sono stati bloccati prima di raggiungere il tuo server Exchange (possibilmente su un server Edge Transport o un gateway, prima che il tracciamento dei messaggi li registrasse).

2> Controllare i Log del Trasporto Edge/Gateway: Se hai un server di Trasporto Edge o un qualsiasi gateway di sicurezza email davanti a Exchange, controlla i suoi log SMTP per quei tentativi di inoltro dei messaggi. Nel log del protocollo di ricezione del Trasporto Edge (se abilitato), cerca eventuali eventi di connessione o rifiuto relativi al server di posta di Aruba. Un rifiuto DMARC o anti-spam potrebbe mostrare una linea come “rifiutato secondo la policy” o simile. Molti gateway registrano anche i fallimenti DMARC o i trigger anti-spoof, che possono mostrare se il messaggio è stato scartato durante la conversazione SMTP (prima che il server di casella lo accettasse).

3> Revisionare le impostazioni Anti-Spam di Exchange: Se gli agenti anti-spam integrati di Exchange sono abilitati (spesso su un server Edge), verificare le loro configurazioni:

• Agente filtro dei contenuti: Controlla le impostazioni della soglia dello spam usando PowerShell: Get-ContentFilterConfig | fl SCL*Enabled, SCL*Threshold Verifica se SCLDeleteEnabled è $true con una soglia SCLDeleteThreshold alta (ad esempio, 8 o 9). In tal caso, qualsiasi email contrassegnata con un punteggio di spam a quella soglia verrebbe eliminata silenziosamente senza NDR. Potresti disabilitare temporaneamente l'azione di eliminazione o aumentare la soglia per vedere se la posta inoltrata viene quindi inviata nella cartella Posta indesiderata invece di essere eliminata (per impostazione predefinita, questa eliminazione automatica è disattivata).
• ID mittente agente: Esegui Get-SenderIdConfig. Se SpoofedDomainAction o TempErrorAction sono impostati su Rifiuta (invece del valore predefinito StampStatus), un fallimento SPF sul messaggio inoltrato potrebbe causare un rifiuto completo. Assicurati che siano impostati solo su 'stampare' e non su 'rifiutare', in modo che i fallimenti SPF non facciano automaticamente cadere i messaggi.
• Regole di trasporto: Controlla di non avere regole di flusso di posta (trasporto) personalizzate che bloccano o reindirizzano involontariamente i messaggi da <dominio1> o al destinatario interno. Questo è improbabile a meno che non sia stata creata una regola specifica, ma vale la pena confermare che nessuna regola stia influenzando questi inoltri.

4> Verifica la configurazione del dominio e del connettore: Assicurati che <dominio1> (il dominio Aruba) non sia erroneamente configurato come dominio interno nella tua organizzazione Exchange. Utilizzando Get-AcceptedDomain, conferma che <dominio1> sia trattato come Esterno (non dovrebbe essere impostato come Autorevole o Relay Interno).

5> Regola il filtraggio per consentire la posta inoltrata da Aruba (se necessario):

Se i messaggi inoltrati vengono effettivamente filtrati come sospettato, puoi implementare un bypass sicuro per essi. Due approcci:

• Aggiungi Aruba alla lista bianca degli IP di inoltro: Aggiungi gli indirizzi IP dei server di posta in uscita di Aruba alla tua lista di consentiti di Exchange (o del gateway), in modo che la posta proveniente da quegli IP eviti il filtraggio antispam. Usa cautela e includi solo intervalli di IP specifici di cui ti fidi (dai server di Aruba). Evita una whitelist basata su dominio in modo ampio poiché, in questo scenario, l’indirizzo “Da” potrebbe essere qualsiasi dominio esterno (Aruba non lo riscrive), e vuoi solo consentire i server di Aruba come mittenti.
• Aggiungi un’eccezione a una regola di trasporto: Crea una regola di trasporto mirata in Exchange per identificare questi messaggi inoltrati e contrassegnarli come sicuri. Ad esempio, se noti che il Mittente o il Return-Path contiene <dominio1> (o qualche intestazione unica che Aruba aggiunge), la regola può impostare l’SCL del messaggio a -1 (saltando il filtraggio antispam). Tieni presente che, se il messaggio viene eliminato da un server Edge prima di raggiungere il ruolo della cassetta postale, potresti dover implementare una regola simile sul Transport Edge (regole di Transport Edge), poiché le regole di trasporto sul server della cassetta postale non vengono attivate se il messaggio non arriva fino a quel punto.

6> Coordinarsi con Aruba: Potrebbe essere utile contattare il supporto di Aruba per vedere se possono modificare il loro meccanismo di inoltro. Idealmente, se Aruba potesse riscrivere il mittente durante l’inoltro (ad esempio, inviare le mail inoltrate come provenienti da COMMERCIALE@<dominio1> invece che dal mittente originale), queste email supererebbero SPF e DMARC sul vostro lato. Alcuni provider utilizzano SRS (Sender Rewriting Scheme) o ARC (Authenticated Received Chain) per le mail inoltrate. Se Aruba supporta uno dei due, abilitarlo potrebbe risolvere il problema principale di autenticazione che causa le cancellazioni silenziose. Non è qualcosa che potete cambiare dal vostro lato, ma vale la pena chiedere ad Aruba se hanno un’opzione per inoltrare in un modo più compatibile con i filtri di Exchange.

7> Verifica SPF/DKIM per <dominio1>: Come buona prassi, assicurati che <dominio1> abbia un record SPF valido (autorizzando i server di posta di Aruba) e che Aruba firmi la posta in uscita con DKIM per <dominio1>. Questo non risolverà direttamente l'attuale problema di inoltro (dato che l'indirizzo From della posta inoltrata non è <dominio1> a meno che Aruba non lo riscriva), ma garantisce che gli inoltri di Aruba abbiano almeno una qualche autenticazione valida (quella del proprio dominio), il che potrebbe aiutare leggermente il modo in cui i tuoi filtri li trattano. Migliora anche la consegnabilità complessiva di qualsiasi posta diretta da <dominio1>.

Dopo aver eseguito questi passaggi, invia un altro messaggio di prova a INFO@<dominio1> o COMMERCIALE@<dominio1> e verifica se appare correttamente nella casella di posta COMMERCIALE@<dominio2> (o anche nella Posta Indesiderata). Questo confermerà se le modifiche hanno risolto il problema di inoltro.

Mi scuso per il lungo post e apprezzo davvero il tempo che dedicate a controllarlo. Per favore, fatemi sapere cosa trovate così posso aiutare a esaminare ulteriormente la questione.

Nota: Segui i passaggi in la nostra documentazione per abilitare le notifiche via e-mail se desideri ricevere la notifica correlata per questa discussione.