Inoltro da alias email: errori SPF, DMARC e soluzioni

Hai configurato l'inoltro da un alias email: contact@yourdomain.com recapita i messaggi su Gmail. Ha funzionato per mesi. Poi un cliente ti scrive per un contratto firmato, ma non vedi il messaggio. Lo scopri tre settimane dopo, quando l'occasione è ormai sfumata.

Nessuna notifica ricevuta, nessun messaggio nello spam. Soltanto un'email mancante e un'opportunità persa.

È uno dei possibili effetti della combinazione alias e inoltro quando incontra politiche DMARC restrittive. Il destinatario può non accorgersi del problema. Conoscere i protocolli aiuta a individuarlo e a ridurne il rischio. Questa guida descrive i punti critici, i codici da cercare nei log e due meccanismi che possono migliorare l'autenticazione dei messaggi inoltrati, senza garantire la consegna.

Se ti servono prima le basi, leggi la guida alla configurazione e alla risoluzione dei problemi di inoltro email. Qui ci concentriamo sui possibili guasti.

Che cosa fa davvero l'inoltro da un alias email

Un alias è un'etichetta di instradamento: non ha posta in arrivo, accesso o quota di archiviazione propri. Quando qualcuno scrive a sales@yourdomain.com, il server riceve il messaggio e lo indirizza altrove, spesso verso un account Gmail o Outlook personale. È una soluzione comune per gli indirizzi funzionali delle piccole imprese, ma può introdurre problemi di recapito poco visibili.

L'inoltro esterno da un alias apre una nuova connessione SMTP per inviare il messaggio alla destinazione. È questo passaggio a introdurre la difficoltà: il tuo server trasmette un messaggio originato altrove, con autenticazione riferita al mittente originale.

I due livelli di un'email

Ogni email contiene due livelli distinti, spesso trascurati. Comprenderli è essenziale per capire come l'inoltro possa compromettere l'autenticazione.

Quando client@bank.com scrive all'alias sales@yourdomain.com, è il server di bank.com a inviare il messaggio. Nell'esempio, SPF riesce perché bank.com autorizza il proprio IP di invio.

Quando il tuo server inoltra a founder@gmail.com, apre una nuova connessione SMTP. L'IP di connessione è ora quello del tuo server, mentre il mittente della busta può restare quello originale. L'intestazione continua a indicare client@bank.com.

Gmail verifica SPF per bank.com e vede l'IP del tuo server, non autorizzato da quel dominio. SPF può fallire. Se bank.com pubblica p=reject e non riesce nemmeno una verifica DKIM allineata, Gmail può rifiutare il messaggio secondo la propria politica. Un eventuale avviso può tornare al mittente originale, non a te; non si tratta necessariamente di una cancellazione silenziosa.

Tre problemi nell'inoltro da alias

L'inoltro può creare problemi a livelli diversi, ciascuno con sintomi e interventi differenti.

1. Errore SPF

SPF verifica se l'IP della connessione è autorizzato dai record DNS del dominio di MAIL FROM o HELO. Nel nuovo passaggio dell'inoltro, il tuo IP sostituisce quello originale come origine della connessione. Se mantieni il mittente originale e il tuo IP non è autorizzato, SPF può fallire alla destinazione.

2. Rifiuto DMARC

DMARC richiede che SPF o DKIM riesca e sia allineato al dominio From:. Se SPF fallisce, una firma DKIM valida e allineata può ancora far superare DMARC. Modifiche alle parti firmate del messaggio, come l'aggiunta di un piè di pagina o la riscrittura di determinate intestazioni, possono però invalidare DKIM. Se nessuna verifica allineata riesce, p=quarantine richiede un trattamento di quarantena e p=reject il rifiuto; il sistema ricevente decide come applicare la politica.

3. Perdita senza avviso al destinatario

Lo scenario peggiore è un messaggio scartato senza NDR, cioè senza rapporto di mancata consegna. Non è l'esito obbligatorio di un errore DMARC: un rifiuto SMTP può generare un avviso al mittente. In ogni caso il destinatario dell'alias potrebbe non vedere nulla, ed è questo a rendere i problemi difficili da individuare.

Codici da cercare nei log SMTP

Se mancano messaggi inoltrati, controlla i log SMTP o chiedi al fornitore i rapporti di mancata consegna. Questi tre codici possono aiutare a individuare problemi di inoltro, ma vanno interpretati nel loro contesto.

Blocco Microsoft 365 (5.7.520)

Exchange Online può bloccare l'inoltro automatico esterno tramite le politiche del tenant. La protezione contro l'esfiltrazione dei dati può bloccare anche un inoltro legittimo; verifica la configurazione effettiva e le indicazioni attuali.

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

Intervento: un amministratore autorizzato può valutare un'eccezione nella politica antispam in uscita del portale Microsoft 365, dopo aver verificato i rischi. Non considerare una regola di reindirizzamento un modo garantito per aggirare il blocco: controlla quali regole sono consentite dalle politiche del tenant.

Ciclo di instradamento (5.4.14 / 5.4.6)

Un ciclo può nascere quando due alias si inoltrano reciprocamente i messaggi, oppure quando un catch-all inoltra a un indirizzo che rimanda messaggi al dominio.

554 5.4.14 Hop count exceeded - possible mail loop

Intervento: controlla le regole di trasporto. Una configurazione da verificare è il catch-all *@yourdomain.com diretto a un indirizzo con risposte automatiche indiscriminate. Una risposta automatica non genera necessariamente un ciclo, ma percorsi ricorsivi o protezioni mancanti possono causarlo.

Errore di autenticazione DMARC (550 5.7.1)

In questo esempio il server di destinazione ha rifiutato il messaggio inoltrato per un problema di autenticazione DMARC.

550-5.7.1 Unauthenticated email from bank.com is not accepted due to domain's DMARC policy.

È un esempio di errore DMARC che può comparire nell'inoltro. Indaga i risultati SPF e DKIM: SRS e ARC a livello di server possono aiutare, ma non sono una garanzia né sostituiscono una corretta configurazione DNS.

Le mitigazioni: SRS e ARC

Non puoi imporre al server di destinazione un'eccezione alla sua politica. Per l'inoltro esterno, SRS e ARC sono meccanismi complementari implementati nell'MTA, il server di trasferimento della posta. Se non gestisci direttamente il server, chiedi al fornitore quali meccanismi supporta e come vengono applicati.

SRS (Sender Rewriting Scheme)

SRS riscrive il mittente della busta SMTP, riportato nel Return-Path, usando il dominio dell'inoltratore. SPF può così riuscire alla destinazione se i record di quel dominio autorizzano correttamente il server e le altre verifiche sono soddisfatte.

Senza SRS:
Mittente della busta: client@bank.com
IP di invio: il tuo server di inoltro
Risultato SPF: FAIL nell'esempio, perché l'IP non è autorizzato da bank.com

Con SRS:
Mittente della busta: SRS0=Hash=TT=bank.com=client@yourdomain.com
IP di invio: il tuo server di inoltro
Risultato SPF: PASS nell'esempio, perché l'IP è autorizzato da yourdomain.com

SRS incorpora anche un hash e un riferimento temporale nell'indirizzo riscritto, per verificarne la validità e limitarne l'abuso. La scadenza dipende dall'implementazione; non rende l'indirizzo immune dalla raccolta o da qualsiasi riutilizzo.

ARC (Authenticated Received Chain)

SRS può correggere SPF alla destinazione, ma non ripristina da solo l'allineamento DMARC di SPF. DMARC confronta il dominio From: (bank.com) con i domini autenticati. Dopo SRS, la busta indica yourdomain.com e From: resta bank.com: non coincidono. Una firma DKIM valida e allineata può comunque far superare DMARC.

ARC, definito nella RFC 8617, aggiunge una catena firmata dei risultati di autenticazione osservati nei passaggi precedenti. Il server sigilla il messaggio inoltrato e i risultati registrati: non afferma automaticamente che SPF e DKIM fossero entrambi validi, ma documenta ciò che ha verificato.

I sistemi riceventi, compresi Gmail e Outlook nelle configurazioni supportate, possono valutare ARC e la reputazione dell'inoltratore nelle proprie decisioni. Un sigillo valido non impone la fiducia né garantisce la consegna; ARC non modifica l'allineamento DMARC.

Nessuno dei due è una semplice impostazione DNS. Le riscritture SRS e i sigilli ARC richiedono supporto nel livello di trasporto; DNS corretto, DKIM integro e politica del destinatario restano importanti per l'inoltro esterno con DMARC restrittivo.

Due insidie operative

Anche con SRS e ARC, due configurazioni comuni possono creare problemi.

La perdita dell'identità nelle risposte

L'inoltro riguarda la ricezione, non configura automaticamente l'invio. Se rispondi da Gmail senza impostare un altro mittente, From può mostrare founder@gmail.com invece di sales@yourdomain.com. Il cliente vede così l'indirizzo personale.

Possibile soluzione: in Gmail configura «Invia messaggio come» nelle impostazioni degli account, secondo l'interfaccia attuale. Inserisci l'alias e credenziali SMTP autorizzate per il dominio. Nei percorsi supportati Gmail usa quel server per l'invio; verifica l'indirizzo mostrato nelle risposte. Per la connessione consulta le impostazioni SMTP gestite di TrekMail.

La configurazione può funzionare, ma la procedura della fonte aggiunge tre passaggi per account. Quando cambi la password SMTP, può essere necessario aggiornare anche Gmail.

Il rischio dell'inoltro catch-all

Evita di inoltrare un catch-all (*@yourdomain.com) all'esterno. Gli spammer provano spesso parti locali casuali sui domini noti, come billing@, admin@, noreply12345@. Un catch-all può raccoglierle e inoltrare anche lo spam che supera i filtri.

Un grande volume di spam inoltrato può compromettere la reputazione dell'IP del server. Anche posta legittima, compresa quella delle caselle reali, potrebbe finire nello spam. Ripristinare la reputazione può richiedere tempo; non è un esito automatico né ha una durata fissa.

Se serve un catch-all, indirizzalo preferibilmente a una casella locale isolata e controllala manualmente. La documentazione sull'inoltro delle caselle in TrekMail aiuta a valutare la configurazione senza moltiplicare inutilmente lo spam inoltrato.

Alias con inoltro o casella reale: quale usare

La guida ad alias email di dominio e caselle offre un quadro più completo. Ecco i criteri sintetici per l'inoltro:

Evita di usare l'inoltro da un alias come sostituto permanente di una casella solo per risparmiare. Con prezzi per utente può sembrare conveniente, ma bisogna valutare anche configurazione aggiuntiva, casi particolari e rischi di autenticazione.

Come TrekMail gestisce l'inoltro

Gestire SRS e ARC direttamente richiede interventi nella configurazione di trasporto, integrazione con Postfix, chiavi di firma ARC e loro rotazione. I dettagli dipendono dal sistema: è un compito da amministratore di server, non una semplice modifica di un alias.

La fonte descrive l'inoltro delle caselle sui piani Pro e Agency di TrekMail tramite un livello di trasporto con OpenARC, con applicazione automatica dei sigilli ARC al traffico inoltrato e destinazione impostata dalla dashboard. Verifica supporto, limiti e comportamento attuali nella documentazione. Questa descrizione non prova da sola il supporto SRS né garantisce la consegna; l'autenticazione DNS del dominio va comunque configurata correttamente.

In molti casi è più semplice evitare l'inoltro e usare una casella dedicata. Il modello a prezzo fisso descritto per TrekMail non aggiunge costi per utente o casella. Una casella support@yourdomain.com non cambia prezzo solo perché vi accede una persona anziché dieci, entro i limiti e con le modalità di accesso supportate. Confronta comunque le condizioni attuali e le esigenze di sicurezza prima di scegliere.

• Piccole e medie imprese: assegna a support@ un accesso IMAP dedicato e configura SMTP per l'invio. L'accesso diretto semplifica la separazione del mittente e riduce la necessità di aggiornare «Invia come» su servizi esterni.
• Agenzie: crea caselle dedicate agli indirizzi funzionali dei clienti, invece di inoltrare agli account personali del team. Con accessi autorizzati e client configurati correttamente, il team può rispondere dall'indirizzo professionale previsto.

Se stai anche configurando SPF, DKIM e DMARC da zero, la guida alla configurazione di sicurezza email per le aziende raccoglie gli elementi fondamentali dell'autenticazione.

In sintesi

L'inoltro da un alias email può andare bene per usi poco critici. Valuta soprattutto questi rischi:

1. Il mittente originale usa DMARC restrittivo (p=quarantine o p=reject) e non resta una verifica allineata valida
2. Il server di inoltro non usa SRS e SPF originale può fallire alla destinazione
3. Il server non usa ARC: mancano i risultati precedenti per la valutazione; SRS da solo non allinea SPF a DMARC, mentre DKIM allineato può bastare
4. Inoltri un catch-all all'esterno e puoi amplificare lo spam
5. Devi rispondere dall'alias: l'inoltro non configura nativamente il mittente in uscita

Le opzioni sono un fornitore con adeguato supporto dei protocolli, inclusi SRS e ARC dove necessari, oppure una casella reale con accesso diretto. L'inoltro può sembrare conveniente con costi per utente; nel modello a prezzo fisso di TrekMail descritto dalla fonte, non c'è una licenza aggiuntiva per casella entro i limiti del piano.

La fonte indica il piano Pro di TrekMail da $10/mese, con fino a 100 domini, inoltro delle caselle con sigilli ARC e nessun costo per casella entro i limiti previsti. Indica anche una prova gratuita di 14 giorni con carta di credito, non richiesta per Nano. Verifica prezzi e condizioni attuali.