L’inoltro e-mail non funziona: diagnosi in 6 passaggi

L'inoltro delle email non funziona. Mancano messaggi, il mittente non vede notifiche di errore e le regole sembrano corrette nei pannelli consultati. Senza un errore visibile, occorre seguire il percorso del messaggio e raccogliere le tracce disponibili.

Un inoltro email che non funziona può dipendere da regola, indirizzo, policy o autenticazione SPF, DKIM e DMARC. Il destinatario vede l'IP del server intermedio, che potrebbe non essere autorizzato dal dominio originale. Secondo controlli e policy, può esserci rifiuto, classificazione come spam o scarto senza avviso visibile. I risultati reali aiutano a distinguere questi casi.

Segui questa lista prima di cambiare DNS. La guida completa alla configurazione e alla correzione degli inoltri spiega le limitazioni di SPF e il ruolo di SRS e ARC. Qui trovi una sequenza rapida per diagnosticare un problema in corso.

Perché un inoltro può fallire senza errore visibile

L'esito dipende dal server e dal momento del problema. Un rifiuto SMTP può generare un avviso; dopo l'accettazione possono esserci notifica successiva, quarantena o scarto secondo la policy. L'avviso segue il mittente di busta, che non è necessariamente quello visualizzato. Consulta log e code: l'assenza di avviso non dimostra da sola un errore DMARC.

Intestazioni e log sono utili quando non appare un errore. Una regola attiva non esclude filtri a destinazione o messaggi ancora in coda. Le sei verifiche seguenti offrono un ordine pratico di diagnosi. Controllare prima lo spam può evitare, per esempio, 45 minuti di modifiche DNS estranee al problema.

Diagnosi in 60 secondi: identifica il sintomo

Dedica 60 secondi, come orientamento, a classificare il sintomo prima di modificare le impostazioni. Indica da dove partire, senza confermare da solo una causa. Questi quattro casi suggeriscono la prima verifica.

Lista di controllo dell'inoltro email

Inizia dal passaggio 1 e dal passaggio 2: spam e avvisi di mancato recapito danno indizi senza cambiare DNS. Può evitare, per esempio, 45 minuti di modifiche inutili. Segui la sequenza e fermati quando le prove identificano la causa.

Passaggio 1: controlla lo spam a destinazione

Verifica iniziale  |  Sintomo: nessun messaggio né avviso

Senza avviso, il messaggio può essere nello spam, ma anche in quarantena o in coda. Inoltrando da client@gmail.com a you@outlook.com, il destinatario può vedere l'IP del server intermedio invece di uno autorizzato dallo SPF originale. SPF può fallire; una firma DKIM preservata, valida e allineata può comunque soddisfare DMARC. La classificazione dipende poi dai controlli e dalla policy del destinatario.

Azione: accedi alla casella finale e controlla spam e posta indesiderata.

Correzione: marca il messaggio legittimo come “Non indesiderato”. Sul server, Sender Rewriting Scheme (SRS) può riscrivere il mittente di busta affinché SPF valuti il dominio intermedio. Il dominio non si allinea automaticamente al From originale. Senza SRS, DKIM allineato può comunque soddisfare DMARC; la configurazione non elimina tutti i filtri futuri.

Passaggio 2: leggi l'avviso di mancato recapito e il codice NDR

Lettura dell'errore  |  Sintomo: notifica di “Mancato recapito”

Il codice SMTP e il testo aiutano a orientare la ricerca. Controlla anche quale server ha emesso l'errore e l'indirizzo interessato. L'oggetto, o un codice privo di contesto, non identifica sempre una causa unica.

Passaggio 3: verifica l'allineamento DMARC

Verifica di autenticazione verso Gmail, Yahoo e Outlook  |  Sintomo: assenza o rifiuto

DMARC può essere la causa. Pubblicare p=reject non implica che gli inoltri falliscano nel 100% dei casi senza SRS o ARC: DKIM può restare valido e allineato. DMARC passa se SPF o DKIM verifica con un dominio allineato al From visibile. Il destinatario applica la sua policy; SRS non allinea automaticamente la busta riscritta al From originale.

Interroga la policy DMARC del dominio originale da un terminale:

dig _dmarc.originalsender.com TXT +short

Trovare p=reject non dimostra il rifiuto di quel messaggio. Esamina i risultati: SPF può fallire per l'IP intermedio, mentre DKIM può sopravvivere o fallire se cambia il contenuto firmato. L'allineamento confronta i domini autenticati con il From, non il mittente di busta con la firma DKIM.

Correzione: valuta inoltro sul server con SRS e supporto ARC quando opportuno. ARC consente di verificare una catena di risultati precedenti; il destinatario decide se fidarsi del server intermedio e come usarli, senza garanzia di passare DMARC o recapitare. Filtri Gmail, regole Outlook e reindirizzamenti cPanel hanno implementazioni diverse; cPanel può inoltrare sul server. Verifica le capacità effettive del servizio.

Passaggio 4: esamina l'inoltro in uscita di Microsoft 365

Verifica delle policy Office 365  |  Sintomo: NDR 550 5.7.520

Una policy Microsoft 365 può bloccare intenzionalmente l'inoltro esterno per limitare l'uscita non autorizzata di dati. Una regola utente non supera i vincoli dell'organizzazione. Conferma destinatario, necessità e approvazione prima di abilitare. Il percorso seguente è indicativo e può cambiare; non estendere la policy predefinita all'intero tenant senza motivo.

1. Accedi con autorizzazione a Microsoft 365 Defender
2. Cerca Posta elettronica e collaborazione → Criteri e regole → Criteri per le minacce → Antispam
3. Esamina il criterio antispam in uscita e il suo ambito; preferisci un'eccezione specifica approvata a estendere Default indiscriminatamente
4. Consulta Modifica impostazioni di protezione
5. Solo nell'ambito approvato, valuta Regole di inoltro automatico e Attivato: l'inoltro è abilitato

Un'opzione non disponibile può dipendere da permessi o policy organizzativa. Chiedi l'intervento dell'amministratore autorizzato, senza aggirare il vincolo con una regola personale. Verifica poi l'effetto e conserva l'approvazione.

Passaggio 5: cerca cicli di routing

Verifica dei percorsi  |  Sintomo: errore 5.4.14 o copie multiple

Un ciclo può nascere quando A inoltra a B e B restituisce ad A. Il messaggio può circolare finché un limite di salti o un altro controllo lo ferma. Esamina, per esempio, un catch-all del dominio A diretto a B e una regola di B che restituisce certi indirizzi ad A.

Cerca queste intestazioni nei messaggi ritardati o duplicati:

• X-Loop
• X-MS-Exchange-Inbox-Rules-Loop
• Delivered-To ripetuto con lo stesso indirizzo

La guida al routing catch-all di dominio aiuta a progettare percorsi senza cicli. Una destinazione finale esplicita facilita la verifica. Un alias o un altro server intermedio non causa necessariamente un ciclo, ma richiede di controllare l'intera catena e i suoi limiti.

Passaggio 6: conferma il destinatario in Gmail

Verifica di attivazione  |  Sintomo: regola presente ma inattiva

In Gmail personale può mancare la conferma dell'indirizzo di destinazione. Controlla lo stato della verifica e poi che l'inoltro sia selezionato nelle impostazioni. Un indirizzo salvato non basta ad attivarlo.

Azione: cerca la conferma “Gmail Team” nella casella destinataria, anche nello spam. Verifica che la richiesta sia legittima e autorizzata prima di aprire il link. Se manca o è scaduta, consulta Impostazioni Gmail → Inoltro e POP/IMAP e ripeti la verifica secondo il flusso attuale.

Leggi le intestazioni per diagnosticare l'inoltro

Un messaggio nello spam è arrivato alla casella. Autenticazione, reputazione, contenuto e altri segnali possono spiegare la classificazione. Authentication-Results offre risultati di verifica, non la spiegazione di ogni fallimento. Controlla il server che ha aggiunto l'intestazione e confronta con i log; un'intestazione proveniente da fonte non affidabile non costituisce prova.

Come consultare le intestazioni, secondo la versione del client:

• Gmail: apri il messaggio → menu a tre punti → “Mostra originale”
• Outlook: File → Proprietà → Intestazioni Internet nelle versioni compatibili

Esempio illustrativo di risultati con SRS e ARC, non un modello canonico di intestazione né una prova di recapito. Verifica autenticazione, allineamento e catena ARC effettivi:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)

Il prefisso SRS0= in Return-Path indica una forma comune di riscrittura. La sua assenza non dimostra che tutti gli inoltri falliscano; esamina busta e implementazione. Gmail, Yahoo e Outlook applicano regole diverse. I requisiti Google per mittenti di grandi volumi del 2024 non rappresentano tutti i domini aziendali né tutti i destinatari.

Quando un inoltro fallito incide sull'attività

Un'email cliente, un contratto o una richiesta di assistenza non ricevuta può ritardare una relazione commerciale. A volte il problema emerge solo quando qualcuno sollecita la risposta. Avvisi, log e test aiutano a trovare queste lacune.

La diagnosi manuale è utile, ma più domini richiedono monitoraggio continuo. Cambiamenti di autenticazione o policy possono alterare l'esito. Google Postmaster Tools mostra dati aggregati su reputazione, segnalazioni di spam e altri indicatori per traffico idoneo verso Gmail personale, con vincoli di volume e ritardi. Un errore di autenticazione non genera automaticamente una segnalazione né influenza necessariamente tutto l'invio.

Riduci i problemi ricorrenti

Se gli inoltri falliscono spesso, valuta infrastruttura, conservazione di DKIM e supporto SRS e ARC oltre alle regole. Una progettazione adeguata può ridurre diagnosi ripetute, ma richiede ancora monitoraggio e revisione delle policy.

Gestione frammentata: esaminare regole Gmail o cPanel, indagare SPF per dominio e richiedere cambiamenti autorizzati delle policy M365 quando cambiano i requisiti.

Modello TrekMail: definire percorsi nel pannello e verificare il trattamento SRS e ARC sul server secondo le funzioni disponibili. Il recapito dipende ancora dal destinatario e dalle impostazioni.

TrekMail descrive inoltro a livello Postfix, con riscrittura SRS e sigillatura ARC prima dell'invio successivo. Conferma il funzionamento attuale e la conservazione delle firme DKIM originali durante le modifiche. ARC riporta risultati precedenti; non mantiene da solo una firma valida dopo cambiamenti al contenuto firmato e non garantisce accettazione da Gmail, Outlook o Yahoo.

Per un'agenzia con decine di domini, centralizzare può semplificare il lavoro. Invece di aprire, per esempio, 30 pannelli, configura e verifica ogni percorso con i permessi adeguati. La guida alla gestione della posta dei clienti spiega catene multidominio senza cicli A→B→A come al passaggio 5.

La descrizione storica colloca l'inoltro ARC e SRS in Pro a $10/mese (100 domini, 50GB) e Agency a $23.25/mese (1,000+ domini), con prova di 14 giorni. Verifica funzioni, quote, copertura della prova e necessità della carta prima di acquistare: confronta i piani su trekmail.net/pricing.

Riduci le richieste ricorrenti con configurazione verificata e monitoraggio. Scopri il trattamento SRS e ARC di TrekMail e verifica le funzioni attuali.