Inoltro email del dominio: diagnosi con SRS e ARC

L'inoltro delle email del dominio apre una nuova connessione SMTP verso la destinazione. Se il server conserva il mittente originale della busta, il suo IP potrebbe non essere autorizzato da quel dominio. Questa differenza può compromettere il recapito; la visibilità delle notifiche di mancata consegna dipende dal percorso e dai registri disponibili.

Senza un'autenticazione adeguata, i messaggi inoltrati possono essere filtrati da Gmail, rifiutati con codice 550 da Yahoo o bloccati dalle policy di Microsoft 365. I provider non reagiscono tutti allo stesso modo e un errore non è sempre visibile nella casella di destinazione.

Questa guida presenta tre schemi utili nel 2026, esempi di errori dei principali provider e una lista di controlli da eseguire in meno di dieci minuti. Per configurare l'intero percorso, consulta la nostra guida completa alla configurazione e alla risoluzione dei problemi di inoltro.

Perché l'inoltro delle email del dominio può far fallire SPF

SPF può fallire quando il tuo server effettua la nuova consegna SMTP ma il Return-Path conserva il dominio originale. La destinazione consulta il suo record SPF per verificare l'IP della connessione. Se non è autorizzato, il controllo può fallire. Una policy DMARC p=reject non comporta da sola l'eliminazione del messaggio: una firma DKIM originale valida e allineata può ancora consentire il superamento di DMARC.

Ecco un esempio della sequenza di errore:

1. alice@bank.com scrive a info@yourdomain.com. Il record SPF della banca autorizza i suoi server.
2. Il tuo server consegna nuovamente a you@gmail.com. Gmail vede il suo IP, ma il Return-Path indica ancora bank.com.
3. Se quell'IP non è autorizzato dal record SPF di bank.com, SPF può fallire.
4. Se il server modifica il corpo o un'intestazione firmata, anche DKIM può fallire, secondo la firma e la canonicalizzazione. Senza altri risultati validi e allineati, DMARC fallisce e il destinatario può applicare la sua policy di rifiuto.

Una notifica di mancata consegna può tornare al mittente della busta o comparire nei registri delle code. Verifica queste tracce prima di concludere che il messaggio sia sparito senza avviso.

Inoltrare un catch-all può amplificare il rischio. Anche lo spam ricevuto viene reinviato dall'IP del server di inoltro. Questo traffico può danneggiarne la reputazione e causare il filtraggio o il rifiuto di email legittime, ma non è un'evoluzione inevitabile né esclusiva di Gmail.

Se stai ancora valutando questa architettura, consulta vantaggi e limiti dell'inoltro tramite alias prima di scegliere la configurazione.

I 3 schemi di inoltro orientati al recapito

Questi tre schemi affrontano rischi diversi. Si possono combinare secondo l'infrastruttura e la policy del destinatario, ma non sono requisiti universali né garanzie di consegna. Conservare una firma DKIM originale valida e allineata è particolarmente importante.

1. Sender Rewriting Scheme (SRS)

SRS riscrive il mittente della busta usando il dominio del server di inoltro. La destinazione può quindi verificare SPF per quel dominio, che deve autorizzare l'IP in uscita. L'indirizzo codificato permette di restituire le notifiche di mancata consegna al mittente originale se implementazione e percorso sono configurati correttamente.

Prima di SRS:

MAIL FROM: <alice@bank.com>

Dopo SRS:

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

Il limite: SRS può risolvere il controllo SPF della busta, ma generalmente non fornisce l'allineamento SPF con il From originale per DMARC. Una firma DKIM valida e allineata può ancora far superare DMARC. Se quella firma diventa invalida, SRS da solo non ripristina l'allineamento.

2. Authenticated Received Chain (ARC)

ARC (RFC 8617) protegge la cronologia dei risultati di autenticazione attraverso gli intermediari. Il server aggiunge intestazioni firmate che registrano i suoi controlli; non dimostrano da sole che il mittente sia legittimo.

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

Google e Microsoft possono considerare una catena ARC valida proveniente da un intermediario attendibile quando decidono il recapito. Può essere utile se l'autenticazione finale fallisce, ma l'accettazione dipende dalla policy del destinatario e non è garantita.

La fiducia è essenziale: una firma ARC valida o un nuovo dominio non ottengono automaticamente la fiducia del destinatario. Possono influire la reputazione e il rapporto con l'intermediario.

3. Inoltro passivo: conservazione di DKIM

Conservare il messaggio originale è importante, con o senza SRS e ARC. Evita di aggiungere piè di pagina o riscrivere intestazioni firmate. DKIM firma il corpo e determinate intestazioni secondo regole di canonicalizzazione: modifiche rilevanti possono invalidare la firma, ma non ogni cambiamento di un byte invalida tutte le firme.

I guasti difficili da diagnosticare possono derivare da modifiche poco visibili. Un filtro aggiunge «Questo messaggio è stato analizzato da MailGuard» al corpo e può invalidarne la firma. I registri di invio potrebbero non segnalarlo; un dkim=fail (body hash did not verify) in Authentication-Results a destinazione offre un indizio, se hai accesso al messaggio.

Questo schema dipende dalla sopravvivenza di una firma DKIM valida e allineata lungo tutto il percorso. Se SPF non è allineato e DKIM diventa invalido, DMARC può fallire. Il destinatario decide comunque come trattare il messaggio e se considerare ARC.

Come i principali provider gestiscono gli errori di inoltro

Microsoft, Google e Yahoo possono bloccare l'inoltro tramite policy, rifiutare messaggi durante SMTP con codice 550 o filtrarli in seguito. Reputazione e autenticazione influiscono. I codici seguenti sono esempi: interpreta la diagnosi completa, la fase di consegna e i registri senza presumere una risposta universale.

Microsoft 365 (Exchange Online)

Una policy antispam in uscita di Defender può bloccare l'inoltro esterno automatico. Se il blocco avviene nel tenant di origine, il messaggio potrebbe non raggiungere il tuo server di inoltro. Verifica la policy effettiva prima di modificare l'autenticazione.

Una notifica 5.7.520 può andare al mittente della busta anziché alla casella di destinazione. Consulta il tracciamento del messaggio e i registri pertinenti; non presumere che la notifica sia sempre invisibile.

Google Workspace / Gmail

Un esempio di rifiuto esplicito è 550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy. Può comparire se DMARC fallisce per un dominio con p=reject. L'assenza di SRS o ARC non basta a prevederlo: DKIM originale valido e allineato può far superare DMARC, mentre SRS da solo non fornisce tale allineamento.

Inoltrare spam da un catch-all può danneggiare la reputazione dell'IP. Il risultato può essere filtraggio o rifiuto, con segnali diversi nelle risposte SMTP e nei registri. Non implica necessariamente una perdita silenziosa e progressiva di tutti i messaggi.

Yahoo / AOL

Yahoo può rifiutare con codice 550 i messaggi inoltrati che non rispettano le sue policy di autenticazione. Aggiungere [FWD] o [External] a un oggetto firmato può invalidare DKIM; senza SPF allineato, DMARC può fallire. Non significa che il 100% di quei messaggi venga rifiutato o che ogni installazione senza SRS/ARC perda tutta la posta: contano la firma conservata, la policy e la diagnosi completa.

Lista di controlli per diagnosticare l'inoltro

Quando l'inoltro delle email del dominio fallisce, segui questa sequenza prima di cambiare la configurazione:

1. Leggi Authentication-Results a destinazione («Mostra originale» in Gmail; sorgente del messaggio in Outlook), se il messaggio è disponibile.

   Authentication-Results: mx.google.com;
     spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
     dkim=fail (body hash did not verify)
     dmarc=fail (p=REJECT)

   spf=fail → verifica il dominio della busta, l'IP e SRS; il risultato da solo non identifica la causa.
   dkim=fail (body hash) → indaga sulle modifiche al corpo e sui problemi della firma.
   Entrambi gli errori possono far fallire DMARC senza altri risultati validi e allineati; il rifiuto dipende dal destinatario.
2. Cerca cicli di instradamento. 5.4.14 Hop count exceeded suggerisce un numero eccessivo di passaggi. Traccia tutto il percorso e cerca cicli come A→B→C→A.
3. Prova il comportamento di Reply-To. La risposta normalmente va a Reply-To se presente, altrimenti a From. Verifica la destinazione prevista ed entrambe le intestazioni prima di attribuire una risposta al server di inoltro alla riscrittura di From.
4. Controlla ogni componente che interviene sul messaggio. Filtri antispam, antivirus, mailing list e strumenti antiphishing possono modificare contenuti firmati. Verifica le trasformazioni e i registri di ogni passaggio.
5. Controlla il volume del catch-all. Un volume elevato di spam inoltrato può danneggiare reputazione e recapito, anche se alcuni messaggi superano i controlli di autenticazione.

Se sei indeciso tra inoltro e instradamento per indirizzo, confronta alias di dominio e caselle email. Rispondono a esigenze diverse e cambiano i rischi da gestire.

L'infrastruttura di inoltro di TrekMail

Con Postfix autogestito, un'architettura può includere postsrsd per SRS, OpenARC per ARC, rotazione delle chiavi RSA e conservazione del contenuto firmato. Sono componenti indipendenti da verificare separatamente; non sono tutti necessari in ogni architettura.

Una firma DKIM aggiuntiva del server di inoltro può far parte del progetto, ma non è un requisito universale di ARC. Non sostituisce la firma originale allineata né ripristina l'allineamento con il From originale se usa un altro dominio. Verifica la conservazione di DKIM, la catena ARC e la policy del destinatario invece di attribuire ogni errore all'assenza di una nuova firma.

Il progetto descritto per TrekMail combina OpenARC, una firma DKIM aggiuntiva e SRS, con un percorso che conserva il contenuto. Verifica l'implementazione attuale e le intestazioni dei messaggi di prova. Imposta la destinazione nelle impostazioni di inoltro della casella; la consegna dipende anche dal destinatario.

L'offerta descritta include l'inoltro nei piani Pro ($10/mese) e Agency ($23.25/mese), con una prova gratuita di 14 giorni che richiede una carta per iniziare. Nano ($0, 10 domini, SMTP fornito da te) e Starter ($3.50/mese, 50 domini) sono presentati senza inoltro. Conferma prezzi, limiti e funzionalità attuali nel confronto completo su trekmail.net/pricing.

Conclusione

Il recapito dell'inoltro delle email del dominio nel 2026 dipende dall'autenticazione e dal percorso. SRS può risolvere SPF della busta senza allineare il From originale; ARC offre una cronologia protetta che il destinatario può considerare; conservare DKIM originale valido e allineato aiuta a superare DMARC. Combina le misure adatte alla tua architettura senza considerarle garanzie di consegna.

Inizia da Authentication-Results per la diagnosi. Interpreta i risultati insieme alle intestazioni e ai registri di ogni passaggio: una singola intestazione non ricostruisce sempre tutto il percorso.

Se preferisci non amministrare Postfix, configurare email professionali sul tuo dominio con TrekMail può richiedere circa 15 minuti, secondo i prerequisiti. Verifica le funzionalità di inoltro attuali e prova il recapito alle tue destinazioni.