Inoltrare la posta del dominio a Gmail: guida pratica

Hai impostato contact@yourdomain.com per inoltrare la posta del dominio a Gmail. Un cliente invia un contratto, una banca un avviso di sicurezza. Non vedi nessuno dei due messaggi.

Controlli lo spam, senza trovare nulla. Nel tuo account non ci sono tracce, errori o notifiche. Questo scenario non significa necessariamente che neppure il mittente abbia ricevuto un avviso.

Può essere un problema di autenticazione, non una semplice difficoltà di Gmail. Quando inoltri la posta del dominio a Gmail, il tuo server ritrasmette dall'IP di inoltro un messaggio originato da un altro dominio. Se mantiene il mittente della busta SMTP, Gmail può verificare SPF sul dominio originale, che non autorizza il tuo IP. Se SPF fallisce e non resta una verifica DKIM valida e allineata, una politica DMARC restrittiva (p=reject) può portare a un rifiuto con errore 550-5.7.26. Un rifiuto SMTP può generare un avviso al mittente originale, anche se tu non lo ricevi; non implica una cancellazione definitiva senza notifiche.

Per ridurre i rischi dell'inoltro, valuta la riscrittura del mittente della busta con SRS (Sender Rewriting Scheme) e la registrazione dei risultati di autenticazione con ARC (Authenticated Received Chain). Sono meccanismi complementari, non garanzie di consegna. Anche una firma DKIM originale valida e allineata può far superare DMARC.

La guida tratta la riscrittura SRS, la prevenzione dei cicli e «Invia messaggio come» di Gmail. Per il funzionamento di SPF, DKIM, DMARC e SRS durante l'inoltro, leggi la guida completa alla configurazione e alla risoluzione dei problemi di inoltro email.

Perché Gmail può rifiutare la posta inoltrata

L'inoltro può far fallire SPF perché l'IP del tuo server non è autorizzato dal dominio originale. SRS permette di verificare SPF sul dominio dell'inoltratore, purché questo autorizzi il server. Non ripristina da solo l'allineamento DMARC; l'esito dipende anche da DKIM, ARC e dalla politica del destinatario.

Ecco un possibile scenario quando client@bank.com viene inoltrato a you@gmail.com:

1. bank.com consegna al tuo server di inoltro
2. Il tuo server ritrasmette il messaggio a Gmail
3. Gmail verifica SPF sul mittente della busta: client@bank.com
4. Il record SPF di bank.com non autorizza l'IP del tuo server: SPF FAIL nello scenario
5. La politica DMARC è p=reject e non riesce una verifica allineata: Gmail può restituire 550-5.7.26
6. Il messaggio non viene consegnato. Tu potresti non ricevere un avviso, mentre il mittente può ricevere una notifica di errore.

DKIM può restare valido se l'inoltro non modifica le parti firmate, come corpo o oggetto coperti dalla firma. Evita piè di pagina antivirus e riscritture dell'oggetto. Una firma DKIM valida e allineata può far superare DMARC anche con SPF fallito. L'opzione aspf=s riguarda soltanto l'allineamento SPF, non quello DKIM. Le modifiche alle parti firmate possono invece invalidare DKIM. SRS aiuta con SPF, ma non è una soluzione garantita per DMARC o la consegna.

Tre modi per inoltrare la posta del dominio a Gmail

Le configurazioni non hanno tutte lo stesso rischio. Scegli l'architettura in base all'uso previsto.

Il catch-all può compromettere il recapito. Gli spammer provano indirizzi casuali, come abc123@yourdomain.com e junk@yourdomain.com. Il server può accettarli e inoltrare lo spam che supera i filtri. Se, nello scenario illustrativo, il 90% dei messaggi è spam, la reputazione dell'IP può peggiorare e anche la posta legittima finire nello spam. Non è una soglia ufficiale di Gmail né un blocco automatico; il recupero può richiedere settimane, ma non ha una durata fissa.

Per valutare alias e caselle, consulta i compromessi dell'inoltro da alias email. La guida alias email di dominio o casella approfondisce la scelta per un nuovo indirizzo.

SRS: perché è importante nell'inoltro verso Gmail

SRS (Sender Rewriting Scheme) affronta il problema SPF riscrivendo il mittente della busta SMTP, riportato nel Return-Path e usato per le notifiche di errore, dal dominio originale a quello dell'inoltratore. Gmail può così verificare SPF sul tuo dominio. Il risultato richiede una corretta autorizzazione dell'IP e non garantisce DMARC o la consegna.

Senza SRS (scenario problematico):
Mittente della busta: client@bank.com
IP di invio: 203.0.113.10 (il tuo server di inoltro)
Verifica SPF: record di bank.com → FAIL (203.0.113.10 non autorizzato)
DMARC: possibile FAIL (p=reject) se non riesce DKIM allineato → rifiuto e possibile notifica al mittente

Con SRS (mitigazione SPF):
Mittente della busta: SRS0=HASH=TT=bank.com=client@yourdomain.com
IP di invio: 203.0.113.10 (il tuo server di inoltro)
Verifica SPF: record di yourdomain.com → PASS nell'esempio (203.0.113.10 autorizzato)
From dell'intestazione: client@bank.com (invariato: vedi il mittente originale)

Il record SPF del dominio usato da SRS deve autorizzare l'IP del server di inoltro, direttamente o tramite meccanismi appropriati. Senza tale autorizzazione, SPF può fallire anche dopo la riscrittura. Un nome host, da solo, non costituisce necessariamente una voce SPF valida.

Un'infrastruttura di inoltro può inoltre aggiungere intestazioni ARC (Authenticated Received Chain). ARC registra in una catena firmata i risultati di autenticazione osservati nei passaggi precedenti. Il destinatario può valutarla in base alla fiducia nell'inoltratore. ARC richiede firme e chiavi pubblicate correttamente, ma non coincide con una normale firma DKIM del messaggio e non modifica l'allineamento DMARC. In un servizio gestito, verifica il supporto del fornitore.

SPF è definito nella RFC 7208. ARC, che documenta la catena di autenticazione nei diversi passaggi, è definito nella RFC 8617.

Prevenire i cicli: quattro controlli prima dell'avvio

I cicli di inoltro possono produrre errori 5.4.14 Hop count exceeded e impedire la consegna. Prima di usare l'inoltro in produzione, esegui questi quattro controlli.

1. Niente percorsi circolari. Verifica che you@gmail.com non abbia un filtro che rimanda a you@yourdomain.com lungo un percorso che ritorna a Gmail. Questa configurazione può creare un ciclo.
2. Controlla le risposte automatiche. Con un indirizzo funzionale (team@domain.com → più account Gmail), valuta la disattivazione delle risposte automatiche e le protezioni del server. Precedence: bulk può essere preso in considerazione da alcuni sistemi, ma non è una protezione universale contro i cicli.
3. Prova da un terzo account. Gmail può deduplicare i messaggi: un test dall'account di destinazione verso l'alias può essere visibile in Inviati ma non in Posta in arrivo. Usa un account esterno, per esempio Yahoo o Outlook, per una prova indipendente.
4. Politica in uscita di M365. Se il server di inoltro è Microsoft 365, un amministratore autorizzato deve verificare e, se approvato, consentire «Inoltro automatico» nella politica antispam in uscita. Se il tenant lo blocca, puoi ricevere 550 5.7.520. Non aggirare la politica di sicurezza.

Sono problemi frequenti al primo utilizzo dell'inoltro verso Gmail. I soli messaggi di errore non sempre ne chiariscono la causa.

Inoltrare la posta del dominio a Gmail con TrekMail

La fonte descrive TrekMail con riscrittura SRS e firme ARC a livello MTA per la posta inoltrata, configurando la destinazione nel pannello. Verifica il supporto effettivo e la documentazione attuale: l'applicazione automatica non garantisce l'accettazione da parte di Gmail.

Nella versione descritta, l'inoltro delle caselle è disponibile nei piani Pro e Agency, mentre Free e Starter richiedono un passaggio di piano per questa funzione. Verifica nomi e condizioni attuali. I passaggi documentati sono nelle istruzioni di inoltro delle caselle TrekMail:

1. Apri Caselle di posta nella dashboard
2. Seleziona Gestisci sulla casella interessata
3. Attiva Abilita inoltro
4. Inserisci l'indirizzo Gmail nel campo Inoltra a
5. Attiva Conserva una copia durante la configurazione iniziale
6. Seleziona Salva impostazioni di inoltro

«Conserva una copia» è importante: nel flusso descritto conserva il messaggio nella casella e tenta l'inoltro a Gmail. Non garantisce la consegna esterna né sostituisce un backup. Se disattivato, un messaggio rifiutato da Gmail può non essere disponibile nella casella locale, secondo il trattamento delle code e degli errori. Mantienilo attivo durante le verifiche e considera quota e conservazione.

La fonte descrive anche azioni collettive per le agenzie: selezionare più caselle e applicare una destinazione comune dal menu delle azioni in blocco, anche su un centinaio di domini. Verifica disponibilità, permessi e limiti attuali, e controlla le destinazioni prima di applicare la modifica.

Completare il flusso: «Invia messaggio come» in Gmail

L'inoltro gestisce la ricezione. Senza una configurazione di invio adeguata, le risposte possono partire dal tuo @gmail.com personale, anziché dal dominio. Il cliente vede Gmail invece di ceo@yourdomain.com.

Valuta «Invia messaggio come» con credenziali SMTP esterne autorizzate. Controlla il percorso di invio e l'opzione «Tratta come alias»: la casella selezionata non determina da sola il server utilizzato. Un percorso non correttamente autenticato può mostrare «via gmail.com» o causare problemi DMARC.

In Gmail, secondo l'interfaccia attuale: Impostazioni → Account e importazione → Invia messaggio come → Aggiungi un altro indirizzo email. Valuta «Tratta come alias» in base alla configurazione: deselezionarlo non è un requisito universale.

Impostazioni SMTP TrekMail nella fonte (piani Starter, Pro, Agency):

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

Piano Nano nella fonte: SMTP proprio (SES, SendGrid, Mailgun ecc.):

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

Nel flusso descritto, Gmail invia un codice di verifica alla casella dopo l'aggiunta dell'indirizzo. Confermalo e configura il mittente predefinito e il comportamento delle risposte. Verifica con un test che venga effettivamente mostrato l'indirizzo professionale.

Verificare il risultato: le intestazioni di autenticazione Gmail

Dopo aver ricevuto un messaggio di prova da un account esterno, controlla le intestazioni originali prima di affidarti alla configurazione in produzione.

In Gmail: apri il messaggio → menu con tre punti → Mostra originale. Cerca Authentication-Results.

Ecco un esempio illustrativo di risultati riusciti. Non dimostra da solo il superamento di DMARC o l'accettazione futura:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

Con spf=softfail o spf=fail, verifica il mittente riscritto, l'IP, il record SPF e le risposte DNS, tenendo conto di cache e TTL. arc=fail può dipendere da modifiche dopo la firma, ma anche da chiavi, firme o catena non valide. Consulta le indicazioni ufficiali di Google sull'inoltro verso Gmail per il trattamento del mittente della busta. SRS è uno dei meccanismi pertinenti.

Gestione autonoma o servizio gestito: il vero compromesso

Con Postfix gestito autonomamente puoi dover installare postsrsd, proteggere e gestire il file srs_secret, pianificarne la rotazione, integrare OpenARC con chiavi ARC corrette e monitorare la reputazione tramite Google Postmaster Tools, dove disponibile. Aggiornamenti, rotazioni errate o nuove politiche dei mittenti possono richiedere interventi: potresti ritrovarti a diagnosticare intestazioni alle 11 di sera.

Nel modello TrekMail descritto, SRS e ARC vengono gestiti nell'MTA dopo la configurazione della destinazione. Verifica comunque il supporto attuale, l'autenticazione DNS e i risultati di consegna; il servizio gestito non elimina ogni controllo operativo.

Come iniziare

La fonte presenta Nano come opzione per collegare un dominio senza carta, non come piano con inoltro incluso. Puoi iniziare a configurare il dominio e attendere le verifiche DNS. Per la funzione di inoltro e il supporto SRS gestito descritto, indica Pro da $10/mese fissi, senza costi per utente entro i limiti del piano. Verifica disponibilità e condizioni attuali.

Nella fonte, i piani a pagamento hanno una prova gratuita di 14 giorni con carta di credito richiesta. Consulta trekmail.net/pricing per i termini attuali, compresi quelli di Nano senza carta.

Quattro elementi da valutare sono la riscrittura SRS della busta, i risultati registrati da ARC, l'autorizzazione SPF dell'IP di inoltro e «Invia messaggio come» per le risposte. Non costituiscono una garanzia: controlla anche DKIM allineato, politica del destinatario, conservazione locale e log. Errori in questi punti possono causare mancati recapiti non visibili al destinatario, ma non sempre senza notifiche al mittente.

Configura con attenzione, verifica le intestazioni e continua a monitorare.