Configuri un inoltro: contact@your-agency.com → you@gmail.com. Il test funziona. Due settimane dopo, il contratto di un cliente aziendale non arriva e non è nello spam. Nei log compare 550 5.7.1 Unauthenticated email, un errore che può avere varie cause di autenticazione. Potresti invece trovare 550 5.7.520 Access denied se il percorso parte da Microsoft 365: è legato alla policy di inoltro esterno del tenant. Il destinatario può non vedere notifiche, anche se il server riceve un rifiuto SMTP.
Lo schema di riscrittura del mittente SRS può risolvere una parte del problema. Nell'inoltro SPF può fallire se viene mantenuto il mittente della busta originale e il suo dominio non autorizza l'IP del server intermedio. Nel 2026 i requisiti di Google e Yahoo rendono importante verificare l'autenticazione, ma non impongono a ogni mittente una policy DMARC p=reject (requisiti Google per i mittenti email). Questa guida spiega il ruolo di SRS, i suoi limiti e le verifiche necessarie per una configurazione completa.
Per il quadro generale, inizia dalla guida alla configurazione dell'inoltro e alla risoluzione dei problemi comuni.
Che cos'è Sender Rewriting Scheme (SRS)?
SRS riscrive la busta SMTP per gestire alcuni errori SPF causati dall'inoltro. Il server sostituisce l'indirizzo MAIL FROM con un indirizzo del dominio di inoltro. Questo dato non compare di solito nell'interfaccia del client, ma è consultabile nel Return-Path delle intestazioni complete. Il destinatario verifica quindi SPF per il dominio riscritto. Se DNS e autorizzazioni sono corretti, SPF può passare; senza riscrittura può fallire quando il dominio originale non autorizza il server. Un fallimento SPF non dimostra da solo una falsificazione e non determina necessariamente l'esito DMARC.
I due livelli di identità email
Per capire gli errori legati a SRS bisogna distinguere due identità, spesso confuse. SPF valuta il dominio della busta e l'IP di connessione; DMARC richiede che almeno SPF o DKIM sia valido e allineato al From: visibile. Un nuovo passaggio di inoltro può modificare queste relazioni.
| Livello | RFC | Campo | Controllo | Visibile al destinatario? |
|---|---|---|---|---|
| Busta (P1) | RFC 5321 | MAIL FROM / Return-Path | SPF | Non normalmente; nelle intestazioni complete sì |
| Intestazione (P2) | RFC 5322 | From: | Allineamento DMARC | Sì |
La busta serve per il trasporto e gli avvisi di mancata consegna; SPF ne verifica il dominio. L'intestazione mostra il mittente e fornisce a DMARC il dominio di riferimento per l'allineamento. Un nuovo collegamento SMTP può causare problemi SPF, ma non fa fallire inevitabilmente tutti i controlli: un DKIM valido e allineato può restare disponibile.
Il nuovo passaggio SMTP: perché SPF può fallire
Il tuo server apre una nuova connessione SMTP alla destinazione. Il mittente della busta resta alice@bank.com, mentre l'IP della connessione è il tuo. SPF verifica quel dominio, bank.com, rispetto al nuovo IP. Se non è autorizzato, il controllo fallisce. Se bank.com pubblica DMARC p=reject e manca un DKIM valido e allineato, il destinatario può rifiutare. Il rifiuto può essere comunicato al server e generare un avviso: non è necessariamente una sparizione silenziosa.
| Passaggio | Azione | Mittente della busta | IP della connessione | Risultato SPF nell'esempio |
|---|---|---|---|---|
| 1 | Alice → il tuo server | alice@bank.com | IP della banca | PASS |
| 2 | Il tuo server → Gmail | alice@bank.com | IP del tuo server | FAIL - non autorizzato per bank.com |
È un possibile effetto strutturale dell'inoltro, non sempre un semplice errore di configurazione. Dipende dal mittente della busta mantenuto e dalle autorizzazioni SPF; non riguarda ogni inoltro allo stesso modo.
Come SRS riscrive la busta
SRS sostituisce il mittente della busta MAIL FROM con un indirizzo del dominio di inoltro prima della nuova connessione SMTP. Il campo From: mostrato al destinatario resta quello originale.
# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)
# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)Nell'esempio, il destinatario verifica your-domain.com, che autorizza il tuo server, e SPF passa. Il lettore vede ancora From: alice@bank.com. La riscrittura gestisce questo controllo, ma non garantisce l'allineamento con il dominio del From: originale né la consegna.
Come interpretare un indirizzo SRS
L'indirizzo SRS nel Return-Path può sembrare una sequenza casuale, ma ogni segmento ha una funzione. Conoscerli aiuta a verificare la riscrittura e a indagare eventuali errori, insieme ai log e ai risultati di autenticazione.
Esempio: SRS0=4fac=PM=bank.com=alice@your-domain.com
| Componente | Valore | Scopo |
|---|---|---|
| Prefisso | SRS0 | Prima riscrittura. SRS1 si usa per un successivo inoltro nelle implementazioni pertinenti e limita la crescita dell'indirizzo, non garantisce una catena illimitata. |
| Codice di autenticazione | 4fac | HMAC basato sul segreto del server: aiuta a verificare gli indirizzi di ritorno SRS e a contrastarne la falsificazione, senza eliminare ogni abuso. |
| Riferimento temporale | PM | Codifica temporale base32 nell'esempio. La validità dipende dall'implementazione e dai parametri; limita alcuni usi di indirizzi vecchi senza garantire protezione completa dai replay. |
| Origine | bank.com=alice | Dati del mittente originale conservati per instradare gli avvisi verso alice@bank.com. |
Il secondo problema: SPF valido ma non allineato
SRS può far passare il controllo SPF senza ripristinare l'allineamento SPF con il From: originale. DMARC richiede un meccanismo valido e allineato, SPF oppure DKIM. Ecco perché alcune email continuano a fallire dopo una riscrittura SRS corretta.
Il dominio autenticato deve essere allineato al dominio del From: visibile. Nell'esempio con SRS:
- Controllo SPF: PASS - il tuo IP è autorizzato dal dominio della busta
your-domain.com - Allineamento SPF: FAIL - busta
your-domain.com≠ intestazionebank.com
In questo scenario DMARC dipende da un DKIM valido e allineato che resti intatto. Non basta evitare modifiche al corpo: contano anche le intestazioni firmate e la canonicalizzazione. Banner «External Email», avvisi antivirus aggiunti in fondo o conversioni MIME da 8-bit a 7-bit possono invalidare la firma se alterano le parti protette.
Se SPF non è allineato e le modifiche invalidano il DKIM allineato, DMARC fallisce. Il destinatario può rifiutare il messaggio secondo la propria policy, anche se SRS ha svolto correttamente il suo ruolo.
ARC: un complemento a SRS
ARC (Authenticated Received Chain, RFC 8617) può affiancare SRS. SRS modifica la busta per il controllo SPF; ARC permette al server di registrare e sigillare i risultati di autenticazione realmente osservati. Non certifica che il messaggio sia privo di spam o minacce.
ARC aggiunge ARC-Authentication-Results, ARC-Message-Signature e ARC-Seal. La catena può fornire informazioni sui passaggi precedenti, ma la firma del messaggio dipende anche dal corpo: modifiche successive non sono universalmente innocue e possono rendere ARC non valido.
Il limite: il destinatario decide se fidarsi del sigillante e della catena. In Microsoft 365, un amministratore autorizzato può valutare la configurazione dei sigillanti attendibili con Set-ArcConfig, secondo le funzioni e le policy attuali del tenant; non è sempre necessario aggiungere manualmente ogni dominio. Non puoi imporre a Gmail di fidarsi di un sigillante.
In produzione, valuta SRS per la busta e ARC per trasmettere il contesto di autenticazione. Non sono sempre entrambi necessari e, anche insieme, non garantiscono una consegna affidabile a ogni provider. Restano importanti DKIM allineato, DNS, filtri e policy dei destinatari.
Controlli per indagare i problemi SRS
Se la posta inoltrata non arriva, usa questi controlli per distinguere un problema SRS da un blocco precedente nel percorso.
1. Controllare Return-Path
Invia un test da un account esterno attraverso l'inoltro ed esamina le intestazioni complete alla destinazione finale.
# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)
# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)2. Verificare i blocchi in uscita di Microsoft 365
Se inoltri da Microsoft 365 e la policy del tenant blocca l'operazione prima dell'uscita, SRS non rimuove quel blocco.
550 5.7.520 Access denied, Your organization does not allow external forwarding.Verifica la policy antispam in uscita nel portale Defender. Un eventuale cambiamento deve essere approvato dall'organizzazione e svolto da un amministratore autorizzato dopo una valutazione del rischio. SRS sul server destinatario non risolve questa restrizione.
3. Cercare cicli di instradamento
Se A inoltra a B e B rimanda ad A, può crearsi un ciclo, secondo le regole e le protezioni presenti. Cerca nei log:
554 5.4.14 Hop count exceeded
5.4.6 Routing loop detectedEvitare l'inoltro e usare caselle reali
Configurare postsrsd, gestire segreti HMAC e indagare errori di allineamento DMARC è parte del lavoro necessario per far transitare posta professionale attraverso caselle personali e contenere i costi per casella. SRS risolve una parte del problema; a volte conviene ripensare l'architettura di inoltro.
| Approccio con inoltro | Approccio TrekMail descritto |
|---|---|
| Inoltrare sales@ a Gmail e indagare periodicamente gli errori SRS | Usare sales@ come casella IMAP reale con consegna diretta |
| Configurare SRS, ARC e segreti HMAC sui server coinvolti | Senza quel passaggio di inoltro non serve il relativo SRS |
| DKIM non valido può compromettere DMARC nell'inoltro | Nessun passaggio di inoltro aggiuntivo; restano le verifiche di autenticazione |
| Messaggi mancanti e visibilità limitata sulla consegna | Log e tracciamento nella dashboard, secondo le funzioni e il piano supportati |
Invece di inoltrare contact@client-domain.com a Gmail e gestire SRS, puoi usare contact@client-domain.com come casella IMAP reale su TrekMail. L'accesso tramite un client o un'integrazione Gmail compatibile evita quel passaggio di inoltro esterno, ma non garantisce ogni controllo di autenticazione. Confronta le soluzioni nella guida all'inoltro del dominio verso Gmail o valuta i compromessi nel confronto tra alias e casella.
Gestisci più domini di clienti? TrekMail può consentire di organizzarli con caselle distinte, secondo piano, DNS e permessi configurati. Il tempo di attivazione varia e la separazione non è una garanzia assoluta di sicurezza. La guida all'hosting email multidominio spiega come organizzare la crescita e ridurre il lavoro di configurazione.
L'offerta TrekMail descritta parte da $3.50 al mese con una prova gratuita di 14 giorni. Verifica prezzi, limiti e condizioni correnti. Configura caselle reali e valuta se puoi eliminare il sistema di inoltro.
