L'inoltro email è probabilmente una delle prime funzioni che configuri quando possiedi un dominio. Ed è spesso anche la prima a smettere di funzionare senza dare segnali.
In apparenza è semplice: prendere i messaggi inviati a info@yourdomain.com e reindirizzarli al tuo account @gmail.com. In pratica, l'inoltro è un'operazione da intermediario che entra direttamente in conflitto con i principali modelli di fiducia di Internet moderno: SPF, DKIM e DMARC. Se la configuri male, l'email non genera necessariamente un errore evidente. Semplicemente scompare.
Per il fondatore di un'azienda, un inoltro guasto può significare perdere le email degli investitori. Per un MSP che gestisce 50 domini di clienti, può significare una valanga di ticket il lunedì mattina.
Questa guida spiega come funziona davvero l'inoltro email a livello di protocollo, perché si guasta secondo schemi prevedibili e come creare una configurazione capace di gestire criteri DMARC rigorosi nel 2026.
Il modello mentale: perché l'inoltro email è più complesso di quanto sembri
Prima di correggere un inoltro guasto, devi capire cosa accade a livello SMTP. Non è come passare un biglietto, ma come spedire nuovamente una lettera, e la differenza è fondamentale.
Quando il server A invia un'email al tuo server, il server B che effettua l'inoltro, e il server B la trasmette alla destinazione finale, il server C, avviene un cambio di identità cruciale. Il server destinatario vede l'indirizzo IP del server B, non quello del server A. È la causa di quasi tutti i problemi di inoltro.
Envelope e header: le due identità di un'email
Ogni email presenta due livelli distinti di identità, che l'inoltro può rendere incoerenti:
- Envelope (P1): ciò che i server di posta usano per instradare materialmente il messaggio. Contiene il
Return-Path, che viene convalidato da SPF. - Header (P2): ciò che il client di posta mostra come indirizzo del mittente. Le verifiche di allineamento DKIM e DMARC usano questo livello.
Ecco cosa si rompe. Quando il tuo server inoltra un messaggio, apre una nuova connessione SMTP verso la destinazione. SPF verifica l'IP di invio rispetto al record SPF del mittente originale, ma l'IP del server di inoltro non è autorizzato in quel record. SPF fallisce. Se il mittente originale applica un criterio DMARC rigoroso (p=reject) e non hai implementato SRS, il server destinatario rifiuta direttamente il messaggio.
Un'analogia concreta: Alice invia una lettera a Bob. Bob mette la lettera di Alice in una nuova busta con il proprio indirizzo di ritorno e la spedisce a Carol. Carol chiede ad Alice se l'ha inviata dall'indirizzo di Bob. Alice risponde di no. Questo è un errore DMARC, e il server di posta di Carol si comporta di conseguenza.
Comprendere la separazione tra envelope e header è essenziale. Tutte le soluzioni illustrate in questa guida partono da qui.
Inoltro email, alias e catch-all: le differenze
Gli amministratori confondono continuamente questi tre metodi di instradamento. Scegliere quello sbagliato è il modo più rapido per ricevere un ticket per un'email scomparsa che richiederà tre ore di diagnosi.
Inoltro email
Prende un'email inviata a un indirizzo e la consegna a un server completamente diverso, per esempio contact@startup.com → founder@gmail.com. Avviene un passaggio di rete. Le catene di autenticazione si interrompono se non vengono gestite esplicitamente. È indicato per concentrare più domini in un'unica casella. Rischio: elevato senza una corretta gestione SRS/ARC. Consulta il nostro approfondimento sui compromessi tra alias e inoltro email.
Alias email
È un altro nome per una casella esistente sullo stesso server. support@company.com recapita nella stessa casella di admin@company.com, senza passaggi di rete né cambiamenti nell'autenticazione. È ideale per una persona che ricopre più ruoli. Rischio: basso. Per capire meglio quando gli alias non bastano e serve una casella completa, consulta la nostra guida alla scelta tra alias e casella.
Catch-all (instradamento con carattere jolly)
Accetta tutte le email inviate a indirizzi inesistenti del dominio, cioè *@domain.com. È utile per intercettare errori di battitura o indirizzi temporanei per campagne. Rischio: critico se punta direttamente a Gmail. Ogni messaggio spam diretto al dominio finisce nella tua casella e, con il tempo, Gmail potrebbe considerare il server di inoltro una fonte di spam. Se usi un catch-all, isolalo. La nostra guida alla configurazione dell'email aziendale esamina tutti i compromessi.
| Metodo | Passaggio di rete? | Rischio di autenticazione | Uso ideale |
|---|---|---|---|
| Inoltro | Sì | Alto (SPF/DMARC si interrompono) | Instradamento tra domini o provider |
| Alias | No | Nessuno | Più ruoli, stessa casella |
| Catch-all | Dipende dalla configurazione | Critico (attira spam) | Errori di battitura, indirizzi temporanei |
Modelli di configurazione: quello valido, quelli problematici e quello inaffidabile
Esistono tre modi per configurare l'inoltro email. Due possono causare problemi. Uno è affidabile negli ambienti di produzione.
1. Instradamento lato provider (il metodo corretto)
Avviene a livello MTA, prima che il messaggio raggiunga una casella. Il server riceve l'email, riscrive l'envelope tramite SRS e la trasmette subito. Non serve una licenza a pagamento per una casella e non viene occupato spazio di archiviazione. SPF e ARC sono gestiti a livello di infrastruttura.
È l'approccio su cui vale la pena costruire. Le route di inoltro di TrekMail funzionano così: definisci la destinazione e l'infrastruttura gestisce gli header di autenticazione. Consulta la guida alla configurazione dell'inoltro delle caselle per i passaggi esatti.
2. Regole della casella (il vecchio metodo)
Crei un account utente completo, pagando $6-$30/month per una licenza che in realtà non ti serve, accedi e imposti una regola: "Quando arriva un messaggio, inoltralo a X".
In alcuni casi limite può avere senso: inoltro condizionale ("inoltra solo le fatture"), requisiti di audit o necessità di archiviare localmente il messaggio prima dell'inoltro. Nella maggior parte delle configurazioni, però, stai pagando una postazione solo per instradare la posta. Anche questo metodo interrompe DMARC come qualsiasi altro inoltro e Microsoft 365 blocca per impostazione predefinita l'inoltro automatico. Ne parleremo nella sezione sui problemi.
3. Inoltro lato client (da evitare del tutto)
È una regola impostata in Outlook Desktop o Apple Mail sul computer locale. Perché l'inoltro avvenga, il portatile deve essere acceso, attivo e connesso a Internet. Non funziona mentre sei in viaggio, durante un riavvio o alle 2am, quando arriva un'email importante.
Non esiste uno scenario di produzione in cui sia la scelta giusta. Se la stai usando, correggi subito la configurazione.
Checklist per una configurazione sicura
Prima di attivare una route di inoltro, esegui questi quattro controlli. Saltarne anche uno prima o poi creerà problemi.
1. Test del loop
Verifica che l'indirizzo di destinazione non inoltri nuovamente alla sorgente. A→B→A è un loop infinito. I server moderni lo rilevano con limiti al numero di passaggi e restituiscono un NDR 5.4.14 hop count exceeded, ma a quel punto hai già danneggiato la reputazione di invio. Mappa le route prima dell'attivazione.
2. Test di ispezione degli header
Invia un messaggio di prova da un account esterno, come Gmail personale, Yahoo o qualsiasi indirizzo fuori dal tuo dominio, all'indirizzo inoltrato. Alla destinazione, apri gli header completi e individua Authentication-Results. Dovresti vedere spf=pass, grazie alla riscrittura SRS, oppure dkim=pass. Se compare dmarc=fail, la configurazione non è pronta per la produzione.
3. Test Reply-To
Rispondi a un messaggio inoltrato. La risposta viene inviata al mittente originale o all'indirizzo del server di inoltro? Deve raggiungere il mittente originale. Se va al server di inoltro, la configurazione dell'envelope è errata e creerà una cronologia delle conversazioni confusa per tutti.
4. Controllo dei criteri in uscita
Se usi Microsoft 365 o Google Workspace come destinazione del relay, verifica che l'inoltro automatico sia consentito nelle impostazioni del filtro antispam in uscita. M365 lo blocca per impostazione predefinita. Se l'opzione non è configurata correttamente, i messaggi inoltrati possono essere eliminati senza avvisare il mittente originale.
Problemi comuni
Quando l'inoltro email si interrompe, quasi sempre il problema rientra in uno di questi casi specifici. Riconoscere lo schema evita un'ora di analisi disordinata degli header.
1. Scarto silenzioso dovuto a DMARC
Nel 2026 è la causa più comune delle email scomparse ed è invisibile: nessun NDR, nessun errore, niente. Il messaggio semplicemente non arriva.
Lo scenario: una banca, un gestore di pagamenti o un fornitore SaaS invia al tuo dominio un'email con criterio DMARC rigoroso p=reject. Tu la inoltri a Gmail. L'IP del server di inoltro fa fallire SPF. Se il server modifica anche il corpo, aggiungendo una liberatoria, o l'oggetto, aggiungendo [External], interrompe anche DKIM. SPF fallito + DKIM fallito = DMARC fallito. Gmail rifiuta il messaggio.
La soluzione consiste nell'implementare SRS sul server di inoltro affinché SPF passi e nell'evitare modifiche al contenuto per mantenere DKIM integro. Se non controlli l'infrastruttura, ti serve un provider di inoltro che lo gestisca. Per un'analisi più approfondita degli errori DMARC nelle catene di inoltro, consulta la nostra spiegazione di DMARC e della posta sicura.
2. Blocco Microsoft 550 5.7.520
Sintomo: il mittente originale riceve un NDR con il codice 550 5.7.520 Access denied, your organization does not allow external forwarding.
È il filtro antispam in uscita di M365 che svolge esattamente la sua funzione: bloccare l'inoltro automatico verso indirizzi esterni. Per risolvere, apri il portale Microsoft Defender → Email & Collaboration → Policies & Rules → Threat policies → Anti-spam policies → Edit the outbound policy → imposta "Automatic forwarding rules" su "On - forwarding is enabled".
Non è intuitivo e Microsoft nasconde l'opzione in profondità. Tuttavia, il codice di errore offre una diagnosi precisa: quando lo vedi, sai esattamente dove intervenire.
3. Loop della risposta automatica
L'utente A inoltra all'utente B. L'utente B imposta una risposta automatica. L'utente A scrive all'utente B. L'autoriposta di B torna ad A. Il server di A inoltra la risposta a B. Il server di B risponde di nuovo.
I server moderni usano header come X-Loop e X-Auto-Response-Suppress per rilevare e fermare il ciclo. Le configurazioni meno recenti o errate possono ancora generare migliaia di messaggi in pochi minuti. Controlla le autorisposte quando imposti l'inoltro tra account.
4. Modifica che invalida DKIM
DKIM firma un hash crittografico del contenuto del messaggio. Non appena cambia qualcosa nella parte firmata, anche solo l'aggiunta di un piè di pagina di una riga, la firma non è più valida. Molti sistemi di posta aziendali aggiungono liberatorie legali a ogni messaggio in uscita. Se la liberatoria viene aggiunta dopo la creazione della firma DKIM, alla destinazione la firma risulta non valida.
Se negli header di un messaggio inoltrato compare dkim=fail (body hash did not verify), quasi sempre questa è la causa.
Procedura di diagnosi: dal sintomo alla soluzione
| Sintomo | Causa probabile | Passaggio diagnostico |
|---|---|---|
Il mittente riceve l'NDR 5.7.1 |
SPF / relay negato | Controlla se l'IP del server di inoltro è in una blocklist. Verifica l'autenticazione SPF negli header. |
Il mittente riceve l'NDR 5.4.14 |
Loop di instradamento | Controlla tutte le regole di inoltro per individuare percorsi circolari (A → B → A). |
| Nessuna email e nessun NDR (eliminazione silenziosa) | Rifiuto DMARC / filtro antispam | Controlla la cartella spam o posta indesiderata della destinazione. Cerca dmarc=fail negli header. |
550 5.7.520 Access denied |
Blocco del criterio in uscita di M365 | Modifica il criterio antispam in uscita di M365 Defender: abilita l'inoltro automatico. |
| L'email arriva ma appare danneggiata | Errore dell'hash del corpo DKIM | Cerca dkim=fail (body hash did not verify) negli header. Disabilita l'inserimento di piè di pagina o liberatorie. |
| La risposta va al server di inoltro, non al mittente originale | Configurazione Reply-To / envelope errata | Verifica che l'inoltro conservi l'header Reply-To del mittente originale. |
Perché l'inoltro in produzione si interrompe: SRS e ARC
Le semplici regole di inoltro non bastano in un ambiente di produzione. Serve un'infrastruttura che comprenda SRS e ARC. Ecco cosa fa ciascuno e perché servono entrambi.
SRS: Sender Rewriting Scheme
SRS risolve l'errore SPF causato dal passaggio di rete. Il server di inoltro riscrive l'indirizzo del mittente nell'envelope, permettendo alla destinazione di convalidare SPF rispetto al tuo dominio anziché a quello del mittente originale.
Prima di SRS:
MAIL FROM: alice@bank.comDopo la riscrittura SRS:
MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.comIl server destinatario esegue SPF su forwarder.com, che passa perché il tuo server è autorizzato. I bounce continuano a tornare a alice@bank.com tramite l'indirizzo codificato. SPF viene rispettato senza interrompere il percorso dei bounce.
SRS è essenziale. Senza SRS, ogni messaggio inoltrato da un mittente con SPF rigoroso fallirà l'autenticazione alla destinazione. Per una spiegazione completa del funzionamento di SRS nelle catene di inoltro, consulta la nostra guida dettagliata alla configurazione dell'email con il tuo dominio. Se instradi specificamente verso Gmail, consulta la guida passo passo per inoltrare la posta del dominio a Gmail in modo sicuro, configurando SRS e Invia messaggio come.
ARC: Authenticated Received Chain
SRS risolve SPF, ma non elimina del tutto i problemi di allineamento DMARC. Qui entra in gioco ARC. ARC consente al server di inoltro di firmare crittograficamente il messaggio con un sigillo che dichiara: "Ho verificato l'autenticazione di questo messaggio quando l'ho ricevuto ed era valida".
Google e Microsoft riconoscono i sigilli ARC dei server intermedi affidabili. In presenza di un sigillo ARC attendibile, questi provider possono accettare il messaggio anche se i controlli SPF/DMARC originali sarebbero falliti a causa del passaggio di inoltro. È, in sostanza, una catena di custodia dell'autenticazione email.
ARC è definito nella RFC 8617 ed è lo standard attuale per preservare l'autenticazione negli scenari legittimi di inoltro. Senza ARC, un criterio DMARC rigoroso p=reject del mittente originale può far rifiutare i messaggi inoltrati dai principali provider, anche quando SRS è attivo.
La zona pericolosa del catch-all
L'inoltro viene spesso associato a una configurazione catch-all, e questa combinazione richiede un avvertimento specifico. Se punti un catch-all verso Gmail, ogni messaggio spam inviato a indirizzi casuali del dominio finisce a Gmail, che vede il server di inoltro come sorgente. Le segnalazioni di spam contro il tuo IP possono accumularsi rapidamente e danneggiare anche la reputazione del dominio per i messaggi legittimi.
Se ti serve un catch-all, isolalo in una casella dedicata con filtro antispam a livello server, invece di inoltrarlo a una casella personale. Il modello completo è descritto nella nostra guida alla configurazione dell'email sul tuo dominio.
Il ruolo di TrekMail
Il vecchio modo di gestire l'inoltro richiedeva di creare un MTA con supporto SRS e ARC oppure pagare licenze per utente solo per instradare la posta. Nessuna delle due opzioni era adatta a chi gestiva più di pochi domini.
Pagare Google o Microsoft $6/user/month, aver bisogno di 10 indirizzi di inoltro e potenzialmente pagare 10 postazioni inutilizzate, oppure raggiungere i limiti degli alias e ricorrere a soluzioni di ripiego: è un costo imposto al semplice instradamento.
L'approccio di TrekMail è un hosting a tariffa fissa. Paghi un piano, non le postazioni. Route di inoltro, alias e configurazione catch-all sono inclusi e gestiti a livello server, con inoltro conforme a SRS integrato nell'infrastruttura. Tu imposti la route; la piattaforma gestisce gli header di autenticazione, l'applicazione di TLS e la consegna. Nessun costo per indirizzo e nessuna lotta con i criteri antispam in uscita per ottenere funzioni di base.
Per chi lavora da solo significa instradare hello@yourdomain.com verso Gmail in meno di cinque minuti, senza configurare un server di posta completo. Per un team, ogni modifica avviene nella dashboard, senza dover ricostruire la storia del DNS. Per un'agenzia che gestisce 100+ domini di clienti, le regole vengono amministrate centralmente e applicate in modo uniforme, senza creare errori di autenticazione che si trasformano in escalation alle 6pm di venerdì.
Il piano Pro ($10/month, o $8/month con fatturazione annuale) include il catch-all esterno e l'inoltro delle caselle. Il piano Agency ($29/month) supporta 1,000+ domini e offre accesso API per gestire le route in blocco. Tutti i piani a pagamento includono una prova gratuita di 14-day (carta richiesta).
Scopri come TrekMail gestisce l'inoltro a ogni scala su trekmail.net.
Conclusione
L'inoltro email non è una funzione da impostare e dimenticare. È un'operazione di instradamento attiva che interagisce con i principali modelli di autenticazione di Internet. Gli errori sono prevedibili: SPF si interrompe quando cambia l'IP, DKIM quando viene modificato il contenuto e DMARC rifiuta in caso di mancato allineamento. Tutti possono essere risolti comprendendo ciò che avviene a livello di protocollo.
In pratica: usa l'inoltro lato server con SRS e ARC, mai regole lato client. Verifica gli header prima dell'attivazione. Fai attenzione al blocco del criterio in uscita di M365. Mantieni isolato il catch-all. Se gestisci l'inoltro su più domini, non pagare per postazione soltanto per instradare la posta.
Con l'infrastruttura corretta, l'inoltro email può funzionare in modo affidabile. Con una configurazione errata, i messaggi più importanti scompaiono senza lasciare traccia. La scelta non è complicata.
