Hai configurato un alias e-mail di dominio - sales@yourcompany.com verso la tua casella, support@ verso l'assistenza. Nel pannello amministrativo sembrava tutto a posto. Poi le richieste sono diminuite, un cliente ha segnalato un messaggio respinto e hai scoperto che rispondevi dal tuo indirizzo personale da tre settimane.
Quando un alias di dominio non funziona, verifica gli errori di battitura e l'interazione fra l'instradamento e l'autenticazione moderna - SPF, DKIM, DMARC -. Una vecchia regola può entrare in conflitto con i controlli del destinatario.
Se compare 550 5.7.520, 554 5.4.14 o i messaggi spariscono nonostante un cortese 250 OK del server, smetti di procedere per tentativi. Questa guida presenta cinque errori comuni, i relativi codici e le correzioni da verificare.
Per capire prima l'architettura - cosa distingue un alias da una casella -, leggi alias e-mail di dominio e casella di posta a confronto prima di continuare.
Il tuo alias e-mail di dominio è davvero guasto? Parti da qui
Questi cinque schemi sono punti di partenza per la diagnosi. Ognuno offre sintomi e codici utili. Individua la riga pertinente prima di modificare DNS, instradamento o criteri amministrativi: il codice orienta la diagnosi, ma non dimostra da solo la causa.
| Sintomo | Codice di errore | Possibile causa | Dove intervenire |
|---|---|---|---|
| Il mittente riceve "Access Denied" | 550 5.7.520 |
Il criterio predefinito di M365 blocca l'inoltro esterno automatico | Criterio antispam in uscita |
| Il mittente riceve "Hop Count Exceeded" | 554 5.4.14 |
Ciclo di instradamento - due regole inoltrano l'una all'altra | Regole della posta in arrivo nella casella di destinazione |
| Il mittente riceve "User Unknown" | 550 5.1.1 |
Casella di destinazione eliminata o mai creata | Verificare la destinazione nella mappa degli alias |
| La posta sembra sparire | Nessuno (250 OK) |
Un errore SPF/DMARC può causare la quarantena a destinazione | Controllare spam e intestazioni complete |
| La risposta mostra un indirizzo From errato | Non applicabile | Il client invia dalla casella principale, non dall'alias | Verificare "Send As" e l'identità di invio |
Perché gli alias creano problemi: i due indirizzi del mittente
Un messaggio può avere due indirizzi del mittente con funzioni diverse; la loro differenza non costituisce di per sé un errore. Il mittente della busta (RFC 5321 MAIL FROM) serve a instradare le notifiche di mancata consegna ed è l'identità verificata da SPF. Il mittente dell'intestazione (RFC 5322 From:) è quello visibile al destinatario in Gmail o Outlook e fornisce il dominio con cui DMARC richiede l'allineamento.
L'instradamento interno - da sales@ a bob@ sullo stesso server - non aggiunge necessariamente un passaggio SMTP esterno, ma non garantisce l'autenticazione. Con l'inoltro esterno, il ricevente vede l'IP del server che inoltra e può verificare SPF sul dominio originale. Se quell'IP non è autorizzato, SPF fallisce. Con p=reject, un errore DMARC può comportare un rifiuto o un altro trattamento secondo il ricevente; una firma DKIM valida, allineata e preservata può comunque far superare DMARC. Rifiuti, quarantena e notifiche dipendono dai criteri e dalla fase SMTP.
Errore di configurazione 1: inoltro esterno senza SRS
Inoltrare un alias verso Gmail, Yahoo o un indirizzo personale Outlook.com può far fallire SPF; l'esito DMARC dipende anche da DKIM e dal suo allineamento. È un problema rilevante nel periodo 2025-2026, soprattutto quando i mittenti pubblicano p=reject, non una garanzia che qualsiasi inoltro fallisca.
Esempio: la cliente alice@bank.com scrive a contact@yourdomain.com. Il tuo server inoltra a you@gmail.com. Gmail consulta SPF per bank.com. L'IP del server di inoltro non compare nel record e SPF fallisce. La banca pubblica p=reject. Se non passa neppure una firma DKIM allineata, il ricevente può rifiutare il messaggio. Il tuo server potrebbe aver già risposto 250 OK al passaggio precedente, ma questo non conferma la consegna finale né esclude una successiva notifica di mancata consegna.
La correzione per la busta: Sender Rewriting Scheme (SRS). SRS riscrive il mittente della busta con il tuo dominio prima dell'inoltro:
Busta originale:alice@bank.com
Dopo la riscrittura SRS:SRS0=hash=TT=bank.com=alice@yourdomain.com
Ora Gmail verifica SPF per yourdomain.com. Se il server è autorizzato, SPF può passare per la busta riscritta. SRS si abilita sul server tramite il provider o l'amministratore. Postfix ed Exim dispongono di moduli SRS; occorre verificarne la configurazione.
Avvertenza importante: SRS può risolvere l'autorizzazione SPF della busta inoltrata, ma non ripristina l'allineamento DMARC con il dominio From originale. Una firma DKIM originale, valida, allineata e conservata può bastare per l'allineamento DMARC. ARC (Authenticated Received Chain) offre informazioni che il ricevente può valutare dopo aver convalidato la catena e verificato l'affidabilità del servizio che la sigilla; non crea allineamento né garantisce la consegna. Firmare con un dominio diverso non corregge l'allineamento con il mittente originale.
Un'alternativa più semplice: evitare l'inoltro a provider esterni. Usa una vera casella IMAP sul tuo dominio e consultala da un client mobile. L'inoltro esterno, già comune nel 2012, oggi richiede attenzione all'autenticazione, pur restando adatto ad alcuni utilizzi.
Errore di configurazione 2: Microsoft 365 blocca l'inoltro esterno
Se l'alias inoltra all'esterno e il mittente riceve 550 5.7.520 Access denied, verifica i criteri Microsoft. L'opzione predefinita "Automatic - System-controlled" del filtro antispam in uscita di Exchange Online corrisponde al blocco dell'inoltro esterno automatico. La misura mira a limitare l'esfiltrazione di dati; controlla il criterio effettivo della tua organizzazione.
Correzione nel portale amministrativo: abilita l'inoltro solo con l'autorizzazione della tua organizzazione. I passaggi seguenti modificano il criterio predefinito e possono interessare tutti gli account a cui si applica.
- Apri il portale Microsoft 365 Defender
- Vai a: Email & collaboration → Policies & rules → Threat policies → Anti-spam
- Modifica Anti-spam outbound policy (Default)
- Imposta "Automatic forwarding rules" su On - Forwarding is enabled
Per abilitare l'inoltro solo per utenti specifici - una scelta più circoscritta -, crea un criterio in uscita destinato a quelle caselle anziché modificare l'impostazione dell'intera organizzazione.
Alternativa PowerShell:
Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On
Errore di configurazione 3: il ciclo di instradamento
Un ciclo può produrre 554 5.4.14 Hop Count Exceeded. Il messaggio passa fra due indirizzi fino al limite del server - per esempio 15-20 passaggi se questa è la configurazione -, poi l'elaborazione si arresta. Il mittente può ricevere una notifica di mancata consegna e il destinatario previsto non ricevere nulla. La soglia dipende dal sistema.
Verifica se una regola dimenticata nella casella di destinazione sta causando il ciclo:
Alias del server:info@→admin@
Regola della casellaadmin@: inoltrare tutto ainfo@per l'archiviazione
Risultato: ciclo fino al superamento del limite di passaggi
Controlla anche ciò che si dimentica facilmente: un risponditore automatico di due anni fa o una regola "archivia tutto su info@". Verifica gli alias del server e le regole dei client. In Exchange, controlla le regole di trasporto nel centro amministrativo. In Google Workspace, esamina "Filtri e indirizzi bloccati" di ogni account interessato.
Correzione strutturale: verifica quando vengono espansi gli alias e applicate le regole delle caselle. A seconda del server, un reindirizzamento che preserva il destinatario originale può riattivare l'alias. Definisci percorsi di consegna senza cicli e collaudali; i nomi "redirect" o "deliver to" non garantiscono da soli il risultato.
Errore di configurazione 4: esposizione dell'identità nell'invio da alias
Un alias che riceve soltanto potrebbe non soddisfare il tuo bisogno di identità. Se rispondi a un messaggio inviato a sales@yourcompany.com e il destinatario vede bob.smith@yourcompany.com nel campo From, non stai usando l'indirizzo previsto. L'esposizione può passare inosservata dal tuo lato.
Verifica in Google Workspace:
- Apri le impostazioni utente → Account → "Invia messaggio come"
- Aggiungi l'indirizzo alias
- Valuta "Considera come un alias" in base all'uso dell'identità. Deselezionarlo può essere adatto a un'identità distinta, ma non garantisce riservatezza. Controlla From, Reply-To e le intestazioni di un messaggio di prova.
Verifica in Microsoft 365:
In M365, "Bob per conto di Sales" può indicare autorizzazioni di invio per conto di altri. L'invio da alias è una funzione distinta dalle autorizzazioni "Send As" e da quelle di invio per conto di altri. Per abilitare la funzione degli alias nell'organizzazione:
Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true
L'opzione riguarda Exchange Online, non Exchange locale. Non elimina universalmente l'indicazione "per conto di": verifica autorizzazioni, tipo di indirizzo e supporto del client.
Errore di configurazione 5: conflitto con il catch-all
Un catch-all (*@domain.com) raccoglie i messaggi per indirizzi senza corrispondenza specifica. Se il sistema privilegia una corrispondenza generica prima di un alias esplicito, può inviare la posta alla casella sbagliata senza un errore evidente.
Nelle mappe indicizzate di Postfix, virtual_alias_maps cerca l'indirizzo esatto prima del catch-all del dominio; non dipende semplicemente dall'ordine delle righe. L'esempio colloca gli alias espliciti prima per leggibilità:
# /etc/postfix/virtual
billing@yourdomain.com finance@yourdomain.com
support@yourdomain.com helpdesk@yourdomain.com
@yourdomain.com catchall@yourdomain.com
postmap /etc/postfix/virtual && postfix reload
La posizione finale del catch-all è illustrativa, non una regola universale di valutazione; nelle mappe PCRE può contare l'ordine dei pattern. Prima di applicare l'esempio, salva un backup della configurazione e delle mappe esistenti, prova le corrispondenze dei destinatari e convalida configurazione e rotte con l'autorizzazione dell'amministratore prima del reload. Per le mappe MySQL, controlla le query e la precedenza effettiva della ricerca dell'indirizzo specifico rispetto al dominio; l'ordine delle righe non garantisce da solo tale priorità.
Diagnosi avanzata: leggi le intestazioni complete
Quando un messaggio sembra sparire senza notifica, le intestazioni di uno arrivato nello spam possono aiutare. Authentication-Results descrive le verifiche effettuate da quel ricevente. Confrontale con log e tracciamento della consegna: non spiegano necessariamente tutti i passaggi.
In Gmail: apri il messaggio → menu con tre punti → "Mostra originale". Cerca il blocco di autenticazione:
Esempio di errore - SRS assente:
Authentication-Results: mx.google.com;
spf=softfail (domain of transition does not designate
192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
dmarc=fail action=quarantine header.from=bank.com;
smtp.mailfrom è ancora alice@bank.com. Se l'IP appartiene al server di inoltro, l'esempio indica che la busta non è stata riscritta con SRS.
Esempio riuscito - SRS attivo e autenticazione allineata conservata:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
dmarc=pass header.from=bank.com;
La busta è stata riscritta e SPF passa per yourdomain.com. Questo SPF non è allineato al From originale. Per spiegare il risultato DMARC con DKIM serve una firma valida e allineata, non mostrata in questo estratto; SRS da solo non lo spiega.
Per verificare come risponde il server a un indirizzo alias, usa swaks solo con autorizzazione su server e domini sotto il tuo controllo. Sostituisci i valori di esempio con tuoi indirizzi di prova, non con quelli di terzi: il comando può inviare un messaggio di prova.
swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com
250 OK conferma l'accettazione in quella fase SMTP, non l'esistenza di una casella né la consegna finale; possono accettare l'indirizzo anche un catch-all o una verifica differita. 550 User Unknown indica che il server ha respinto l'indirizzo come sconosciuto durante quella prova. Esamina mappe, criteri e log.
Prevenzione: semplifica le rotte e riduci i passaggi
Per limitare gli errori, elimina quando possibile i modelli che li favoriscono. Queste due linee guida coprono buona parte dei casi precedenti.
Regola 1: evitare inoltri esterni non necessari. Mantieni la posta aziendale sul suo dominio e consulta la casella con un client IMAP sul telefono. L'inoltro può complicare SPF e DMARC, far transitare dati su infrastrutture di terzi e richiedere un'altra identità di invio. Se è necessario, valuta le implicazioni e configura l'autenticazione.
Regola 2: ridurre le catene di alias a un passaggio.
| Da evitare | Da preferire |
|---|---|
contact@ → info@ → bob@ |
contact@ → bob@ e info@ → bob@ |
Ogni passaggio aggiunge un'occasione di ciclo, modifica delle intestazioni o errore di autenticazione. Un solo passaggio è un obiettivo architetturale utile, non un requisito universale.
Per indirizzi temporanei o dedicati a campagne, considera l'indirizzamento con il segno più - bob+newsletter@domain.com - invece di creare sempre un nuovo alias. Verifica supporto e impostazioni attuali di TrekMail, Gmail ed Exchange: dipendono dal provider e dalla configurazione. Alcuni moduli web rifiutano il carattere +, quindi nemmeno questa soluzione funziona ovunque.
Per confrontare in dettaglio alias e inoltro, leggi inoltro tramite alias e-mail.
Quando il problema è il modello tariffario
Parte di questa complessità nasce quando il prezzo per utente rende costose le caselle indipendenti. Crei alias per evitare un'altra licenza e poi trascorri ore a esaminare intestazioni SRS e criteri di inoltro PowerShell.
Il confronto storico di TrekMail qui presentato contrappone un canone del servizio alla fatturazione per ogni casella. Il piano Starter ($3.50/mese) è un esempio di un'offerta precedente con sales@, support@ e billing@ come vere caselle IMAP indipendenti, con accessi e identità propri. Verifica il canone attuale, i limiti di domini e caselle e le quote condivise dell'account. Per rispondere da ogni identità, controlla le autorizzazioni e la configurazione del client SMTP; caselle indipendenti non garantiscono che nessuna intestazione riveli un'altra identità. Nel modello Nano con SMTP proprio, questo serve per tutti i messaggi in uscita, risposte comprese; i piani a pagamento possono offrire SMTP gestito secondo le funzionalità incluse.
| Esempio per utente (M365 / Workspace) | Esempio di canone del servizio TrekMail | |
|---|---|---|
Aggiungere una casella support@ |
+$6/mese se occorre un'altra licenza; un alias o una casella condivisa può evitarla, secondo l'edizione | Inclusa nell'esempio; verificare i limiti attuali |
Aggiungere una casella billing@ |
+$6/mese se occorre un'altra licenza, secondo il piano e il tipo di indirizzo | Inclusa nell'esempio |
| Identità nella risposta | Può richiedere la configurazione "Send As" | Indirizzo proprio della casella, secondo il client |
| Complessità delle rotte | Mappe degli alias, SRS e criteri di inoltro | Una casella indipendente può semplificarle |
Per le agenzie, anche il piano Pro ($10/mese) per 100 domini è un riferimento all'offerta precedente. Verifica le condizioni attuali prima di aggiungere clienti. Lo strumento di migrazione IMAP descritto può copiare messaggi da Gmail o cPanel con accesso autorizzato e compatibilità verificata. Controlla cartelle e conteggi, coordina il cambio DNS e una copia finale dei nuovi messaggi; IMAP non sostituisce un backup né migra da solo contatti e calendari.
Se configuri per la prima volta la posta su un dominio, come creare e-mail con il tuo dominio illustra il processo. Consulta i prezzi TrekMail per confermare il canone dell'account, i limiti e le condizioni di prova. L'offerta precedente prevedeva una prova del piano a pagamento di 14 giorni con carta obbligatoria; controlla le condizioni in vigore prima di registrarti.
Conclusione
Gli alias possono incontrare errori SPF nell'inoltro senza SRS, blocchi Microsoft 365, cicli dovuti a regole dimenticate, identità di invio mal configurate e conflitti catch-all. I codici aiutano nella diagnosi, ma la correzione richiede di verificare il percorso reale, i criteri e l'autenticazione allineata.
Se i problemi si ripetono, potrebbe non essere solo la configurazione: forse stai costruendo soluzioni alternative a un modello tariffario per utente. In quel caso conviene rivedere anche l'architettura e il piano.
Per approfondire architettura e diagnosi, parti da configurazione e correzioni dell'inoltro e-mail.