Inoltrare email a un altro indirizzo: autenticazione e diagnosi

Imposti una regola di inoltro. Invii una prova. Funziona. Passi ad altro.

Poi un cliente dice di non aver ricevuto la tua risposta. Nessun messaggio di mancata consegna visibile. L'email sembra essersi persa tra i server; i log possono chiarire cosa è successo.

Questo può accadere quando inoltri email a un altro indirizzo: il tuo server apre una nuova connessione SMTP verso la destinazione. Questa verifica SPF con il tuo IP, non quello del mittente originale. Se l'IP non è autorizzato per il dominio del mittente della busta, SPF può fallire. Senza una firma DKIM valida e allineata, fallisce anche DMARC. Con p=reject, il destinatario può rifiutare il messaggio secondo la propria policy; non significa sempre eliminazione silenziosa o assenza di notifica.

Non è necessariamente un errore di configurazione. L'inoltro può entrare in conflitto con l'autenticazione moderna. La guida completa alla configurazione e alla risoluzione dei problemi di inoltro tratta i diversi scenari dall'inizio alla fine. Questo articolo approfondisce l'autenticazione: tipi di errore, codici e misure correttive.

Perché l'autenticazione può fallire durante l'inoltro

Quando inoltri un'email, il MTA destinatario verifica SPF con l'IP del server di inoltro, non quello del mittente originale. Ogni messaggio ha due livelli di identità che possono perdere l'allineamento. SPF verifica la busta; DMARC richiede SPF o DKIM valido e allineato con il dominio del mittente visibile.

Il percorso: il server A invia al server di inoltro B, che apre un'altra connessione TCP verso C. C vede l'IP di B. SPF interroga il DNS del dominio del mittente della busta: "Questo IP è autorizzato a inviare per il tuo dominio?" Se il dominio originale non autorizza B e la busta viene mantenuta, SPF può fallire. Non è un esito inevitabile di qualsiasi inoltro.

A DMARC basta un meccanismo SPF o DKIM valido e allineato. Una firma DKIM originale che rimane valida e allineata può quindi far passare DMARC. Modifiche alle parti firmate possono invalidare DKIM, secondo le intestazioni firmate e la canonicalizzazione. Senza un meccanismo valido e allineato, DMARC fallisce; p=reject richiede il rifiuto, subordinato alla policy locale del destinatario.

Tre tipi di problema da prevedere

Senza misure adeguate sul server, l'inoltro può incontrare questi tre problemi. I codici sono esempi che dipendono dal provider, non risposte obbligatorie per ogni errore. Riconoscere il caso aiuta a indirizzare la diagnosi.

1. Blocco in uscita di Microsoft 365 (550 5.7.520)

Microsoft 365 può bloccare l'inoltro esterno, considerato un rischio di esfiltrazione dei dati. Se una regola inoltra fuori dal tenant e la policy effettiva non lo consente, Exchange Online può bloccare il messaggio prima dell'uscita.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

È un blocco amministrativo, non un errore di protocollo. Un amministratore deve verificare l'ambito autorizzato:

1. Apri il portale Microsoft 365 Defender.
2. Vai a Email & collaboration → Policies & rules → Threat policies → Anti-spam.
3. Modifica la policy del filtro antispam in uscita applicabile agli utenti o gruppi autorizzati.
4. Imposta Automatic forwarding su On - Forwarding is enabled solo per quell'ambito approvato.

Abilitare l'inoltro globalmente aumenta l'esposizione se un account viene compromesso. Limita l'eccezione a chi ne ha bisogno, applica MFA e monitora il volume in uscita dopo la modifica. Verifica anche le altre restrizioni di inoltro vigenti.

2. Fallimento dei due meccanismi DMARC

Questo problema può essere difficile da rilevare dalla casella. SPF può fallire per il cambio di IP se viene conservato il mittente originale della busta. DKIM può ancora far passare DMARC con una firma valida e allineata. Una modifica rilevante del corpo o di un'intestazione firmata può invalidarla; non tutte le modifiche hanno questo effetto.

Modifiche che possono invalidare DKIM durante il transito:

• Un antivirus aggiunge un piè di pagina: "Scansionato da [Nome del prodotto]"
• Il gateway di destinazione aggiunge all'oggetto [EXT] o [EXTERNAL], se l'intestazione è firmata
• Vengono inseriti avvisi di "Mittente esterno" nel corpo HTML
• Il software di una mailing list riscrive intestazioni firmate o aggiunge un piè di pagina per disiscriversi

Se né SPF né DKIM forniscono un risultato valido e allineato, DMARC (RFC 7489) fallisce. Con p=reject, il dominio richiede il rifiuto, ma il destinatario sceglie il trattamento finale. Sono possibili rifiuto SMTP, quarantena o altre azioni locali; non si può presumere una cancellazione senza notifica. Consulta log e rapporti disponibili.

3. Loop di instradamento (554 5.4.14)

Un loop si crea quando i server si rimandano ripetutamente lo stesso messaggio fino al limite di passaggi. Può generare una notifica di mancata consegna, ma tempi e codici dipendono dal sistema. Può anche congestionare le code e ritardare altre email.

Situazioni da controllare:

• L'utente A inoltra a B; B ha una regola che inoltra di nuovo ad A.
• A inoltra a B, che ha una risposta di assenza. Se le regole consentono risposte ripetute e le protezioni sono insufficienti, la risposta può ripassare dall'inoltro e creare un loop; non accade automaticamente in tutti i sistemi.
• Un indirizzo catch-all inoltra a una casella che inoltra a un indirizzo inesistente dello stesso dominio, rientrando nel catch-all.

554 5.4.14 Hop count exceeded - possible mail loop

Verifica l'intero percorso, comprese le risposte automatiche e le destinazioni catch-all, prima di abilitare l'inoltro in produzione.

Le misure correttive: SRS e ARC

Due meccanismi sul server possono migliorare l'autenticazione delle email inoltrate, senza garantire la consegna. SRS riscrive il mittente della busta per consentire a SPF di passare con una configurazione corretta. ARC conserva una catena autenticata di risultati che il destinatario può decidere di usare nonostante un errore DMARC. Richiedono supporto sul server, non una semplice regola nel client.

SRS: Sender Rewriting Scheme

SRS riscrive il mittente della busta (P1) con un dominio che controlli. Invece di mantenere alice@bank.com, il cui dominio potrebbe non autorizzare il tuo server, il server di inoltro utilizza un Return-Path come questo:

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

SPF ora verifica il tuo dominio. Può passare se il record autorizza l'IP in uscita e la valutazione DNS si conclude correttamente. Questo non allinea automaticamente il dominio con il From visibile originale per DMARC.

Hash e timestamp permettono di validare e instradare le notifiche di mancata consegna: una notifica inviata a un indirizzo SRS valido può essere decodificata e restituita ad Alice. Questi indirizzi hanno validità limitata e uno scopo preciso. La validazione SRS non sostituisce i controlli su destinatari e relay necessari per evitare un relay aperto.

ARC: Authenticated Received Chain

SRS può correggere SPF senza ripristinare l'allineamento tra busta e intestazione. ARC (RFC 8617) non colma questa distanza. Il server aggiunge un sigillo crittografico che conserva i risultati di autenticazione osservati alla ricezione e permette di verificare la catena.

Google e Microsoft possono considerare ARC di intermediari ritenuti affidabili, secondo le proprie policy. Una catena ARC valida e una buona reputazione non garantiscono accettazione o arrivo nella posta in entrata: la decisione finale resta al destinatario.

Pensa ad ARC come a un registro della catena di custodia. Ogni intermediario partecipante aggiunge una dichiarazione firmata dei risultati osservati. I destinatari successivi possono verificare la catena e decidere di fidarsi quando l'allineamento SPF o DKIM non è più sufficiente per DMARC.

Gmail e Microsoft 365 supportano ARC in determinati flussi; controlla le intestazioni e la configurazione effettiva del percorso utilizzato. Senza ARC sul tuo server manca questo contesto aggiuntivo, ma DMARC può ancora passare grazie a una firma DKIM originale valida e allineata.

Implementazione: due percorsi

Per ridurre i problemi di autenticazione dell'inoltro, puoi gestire il tuo MTA oppure scegliere un provider che confermi supporto SRS e ARC per il tuo flusso. Nessuna opzione elimina tutti i rischi di consegna; servono comunque prove e monitoraggio.

Opzione A: Postfix + postsrsd (gestione autonoma)

Su un server Linux con Postfix, postsrsd può gestire SRS. Questo esempio mostra l'integrazione TCP delle versioni precedenti. Le versioni moderne usano socketmap, incompatibile con queste tabelle TCP; consulta la documentazione della versione installata, adatta la configurazione e provala prima di applicarla:

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Responsabilità di questo approccio:

• Gestire le chiavi segrete SRS. La divulgazione delle chiavi consente di falsificare indirizzi SRS; mantieni controlli indipendenti su relay e destinatari.
• Configurare le esclusioni dei domini locali secondo topologia e versione, evitando riscritture inappropriate delle email interne.
• Gestire la reputazione dell'IP in uscita, che influisce sulla consegna a Gmail e Outlook senza determinarla da sola.
• Configurare ARC separatamente: postsrsd non basta per firmare ARC.

È un'opzione praticabile con una configurazione validata. Richiede però manutenzione continua, che alcuni provider possono assumersi in parte.

Opzione B: TrekMail (inoltro gestito)

Se scegli TrekMail, conferma prima il supporto SRS automatico e ARC per il tuo piano e flusso di inoltro. Verifica anche quale traffico usa relay SMTP gestiti. Non presumere che queste funzioni siano incluse in ogni piano, né che reputazione e consegna siano garantite.

Per chi avvia un'attività da solo: pagare $6/mese per casella solo per inoltrare info@yourdomain.com alla posta personale può essere un costo per utente significativo. Il prezzo di riferimento di Starter è $3.50/mese per un massimo di 50 domini, senza costi per utente; conferma prezzo attuale, limiti e inclusione dell'inoltro esterno. Consulta come funziona l'inoltro delle caselle in TrekMail.

Per le agenzie che gestiscono DNS di più clienti, diagnosticare SPF può consumare tempo e margini. Un pannello comune può semplificare la gestione, purché supporti i flussi necessari. Se scegli tra alias e regole complete di casella, la guida all'inoltro tramite alias illustra i compromessi.

Checklist prima di inoltrare email a un altro indirizzo

Verifica questi quattro punti prima di attivare una regola in produzione. Riducono i rischi descritti, ma non sostituiscono le prove di consegna e l'analisi dei log.

1. SRS attivo quando necessario. Controlla l'intestazione Return-Path di una prova consegnata. Se il flusso usa SRS, deve mostrare il dominio di inoltro e un formato SRS valido; verifica anche SPF.
2. Evitare modifiche al contenuto firmato. Configura le protezioni perché non aggiungano note antivirus, tag nell'oggetto o avvisi di "Mittente esterno" che invalidano DKIM. Mantieni la scansione di sicurezza e protezioni equivalenti, ad esempio avvisi fuori dal contenuto firmato. Canonicalizzazione e intestazioni firmate determinano quali modifiche incidono sulla firma.
3. Protezione dai loop. Controlla regole inverse, risposte di assenza, destinazioni catch-all e limiti di passaggi. Una risposta automatica non crea necessariamente un loop, ma il comportamento effettivo va provato.
4. Policy in uscita M365. In Exchange Online, autorizza "Automatic Forwarding" solo per utenti o gruppi approvati nella policy in uscita di Defender. Verifica altre restrizioni ed evita l'abilitazione globale predefinita.

Quando non inoltrare email a un altro indirizzo

A volte non serve l'inoltro esterno. Per raccogliere email di più domini in una casella dello stesso sistema, un alias di dominio può evitare un passaggio SMTP esterno aggiuntivo. I domini devono comunque essere configurati correttamente; le responsabilità SPF/DKIM non scompaiono del tutto.

Il confronto tra alias di dominio e casella aiuta a scegliere tra alias e regola completa di inoltro. Se stai cambiando provider, verifica disponibilità e limiti dello strumento di migrazione IMAP di TrekMail: copiare i messaggi esistenti dal server di origine non sostituisce la transizione della ricezione delle nuove email.

Riepilogo

Durante l'inoltro, il destinatario vede l'IP del server intermediario. Se il mittente originale della busta viene mantenuto e quell'IP non è autorizzato, SPF può fallire. DMARC può ancora passare con DKIM valido e allineato. Senza un meccanismo di autenticazione allineato fallisce; il destinatario decide il trattamento e la presenza di una notifica dipende dal flusso.

Le misure sono sul server: SRS riscrive il mittente della busta con un dominio controllato e può consentire a SPF di passare; ARC offre contesto autenticato di cui il destinatario può decidere di fidarsi. Nessuno garantisce da solo allineamento DMARC o consegna. Puoi gestirli in Postfix o confermarne la disponibilità su una piattaforma.

Per delegare chiavi SRS, ARC e gestione della reputazione, conferma cosa include TrekMail per il tuo caso. Il prezzo di riferimento di Starter è $3.50/mese per un massimo di 50 domini, tariffa fissa senza costi per utente; verifica prezzi, funzioni e condizioni attuali. Vedi tutti i piani.