Configuri un inoltro email e il test funziona. Due settimane dopo, il contratto di un cliente non arriva. Non è nello spam e non vedi notifiche di mancata consegna. Nei log trovi: 550 5.7.1 Unauthenticated email from domain.com.
Questo errore può avere diverse cause di autenticazione; SRS assente o mal configurato è una possibilità da verificare, non una diagnosi certa. Nell'inoltro, il server trasmette dal proprio IP un messaggio il cui mittente della busta può appartenere a un altro dominio. Uno schema di riscrittura del mittente, o SRS, interviene sulla busta SMTP. Nel 2026 non è comunque una soluzione completa da solo: occorre conoscerne sia il funzionamento sia i limiti.
Questa guida spiega cosa fa SRS, dove può fallire e quali componenti servono per un sistema di inoltro. Se stai indagando problemi più generali, come record MX errati, catch-all mal configurati o modifiche DNS che hanno interrotto l'instradamento, leggi prima la guida alla configurazione e alla risoluzione dei problemi di inoltro.
Perché SPF può fallire durante l'inoltro
SPF può fallire se il server di inoltro usa il proprio IP mantenendo il mittente della busta originale e quel dominio non autorizza tale IP. Con DMARC p=reject e senza un DKIM valido e allineato, il destinatario può rifiutare il messaggio. Il rifiuto SMTP può generare un avviso al mittente originale, mentre nella tua casella potrebbe non comparire alcuna notifica.
La posta non percorre un unico collegamento continuo: passa attraverso una catena di connessioni SMTP, con una nuova connessione TCP a ogni passaggio. Ecco uno scenario di errore:
alice@client.comscrive acontact@your-agency.com- Il tuo server accetta il messaggio: nell'esempio l'IP di invio di Alice è autorizzato da SPF per
client.com - Il tuo server apre una nuova connessione SMTP a Gmail per inoltrarlo
- Gmail vede una connessione dal tuo IP
- Il mittente della busta resta
alice@client.com - Gmail verifica SPF di
client.com: il tuo IP non è autorizzato - SPF fallisce. Se
client.comusap=rejecte manca un DKIM valido e allineato, Gmail può rifiutare il messaggio
RFC 7208, la specifica SPF, riconosce i problemi dell'inoltro. Non basta presumere che il dominio originale autorizzi il server intermedio: la riscrittura della busta è uno degli strumenti per gestire il controllo SPF sul nuovo percorso.
Due identità: mittente della busta e From: visibile
Le email hanno due livelli di identità del mittente. Il mittente della busta (RFC 5321, MAIL FROM, P1) serve per SPF e per instradare gli avvisi di mancata consegna. È usato dai server, ma si può vedere anche nelle intestazioni complete tramite Return-Path. Il From: dell'intestazione (RFC 5322, P2) è quello mostrato da Gmail o Outlook. Nell'inoltro, l'autorizzazione SPF del mittente della busta può non corrispondere al nuovo server di invio: SRS interviene su questa parte, non sul From: visibile.
| Livello | Nome tecnico | RFC | Scopo | Visibilità |
|---|---|---|---|---|
| Mittente della busta | MAIL FROM / Return-Path | RFC 5321 (P1) | Controlli SPF e avvisi di mancata consegna | Server; consultabile nelle intestazioni complete |
| From: dell'intestazione | From: header | RFC 5322 (P2) | Mittente mostrato dal client email | Utenti finali |
Nell'inoltro, il From: visibile può restare alice@client.com. Il tuo server crea una nuova transazione SMTP e SPF valuta il mittente della busta rispetto all'IP di quel passaggio. Il problema è l'eventuale mancata autorizzazione del nuovo IP, non la semplice presenza di due identità diverse.
Che cosa fa SRS
SRS riscrive il mittente della busta (P1) prima che il server di inoltro apra la nuova connessione SMTP. Il From: visibile resta invariato. Usando nella busta un dominio che autorizza il server di inoltro, SPF può passare alla destinazione senza cambiare il mittente mostrato. Questo non garantisce l'allineamento DMARC con il dominio originale.
L'analogia postale: senza SRS, ricevi la lettera di Alice, la metti in un nuovo sacco e lasci il suo indirizzo di ritorno. L'identità di chi trasporta e quella usata per il ritorno sono diverse: è un'analogia per il problema SPF, non una prova di falsificazione. Con SRS usi il tuo indirizzo di ritorno. Se il sacco torna indietro, arriva a te e puoi instradare il ritorno ad Alice.
| Componente | Prima dell'inoltro | Dopo SRS (esempio) |
|---|---|---|
| From: visibile (P2) | alice@client.com | alice@client.com (invariato) |
| Mittente della busta (P1) | alice@client.com | SRS0=4fac=PM=client.com=alice@your-agency.com |
| IP di invio | Il tuo server | Il tuo server |
| Risultato SPF nell'esempio | FAIL | PASS |
Come leggere un indirizzo SRS
SRS trasforma il mittente della busta in una stringa codificata prima dell'inoltro. Il dominio riscritto deve consentire il percorso effettivo. La stringa contiene un codice di autenticazione per verificare i ritorni, un riferimento temporale che ne limita la validità e l'indirizzo originale per instradare gli avvisi. Sono dati strutturati, non caratteri casuali; la protezione dipende dall'implementazione.
Un esempio di indirizzo riscritto con SRS:
SRS0=4fac=PM=client.com=alice@your-agency.com- SRS0: primo passaggio.
SRS1viene usato per successivi inoltri e limita la crescita dell'indirizzo, senza garantire una catena illimitata - 4fac: nell'esempio rappresenta un codice HMAC-SHA1. Algoritmo e lunghezza dipendono dall'implementazione. Il controllo aiuta a rifiutare ritorni con codici non validi e a contenere gli abusi di backscatter
- PM: riferimento temporale. Una finestra di 7-21 giorni è un esempio configurabile, non una regola universale. La scadenza limita l'uso di indirizzi vecchi, ma non elimina ogni attacco di replay
- client.com=alice: mittente originale codificato, usato per instradare gli avvisi di mancata consegna
Quando valutare SRS
SRS è utile quando inoltri tra domini mantenendo il mittente della busta originale e il suo SPF non autorizza il server intermedio. Una configurazione multidominio dovrebbe verificare questo caso e l'intero percorso di autenticazione, anziché presumere che l'inoltro resti sempre compatibile con le policy dei mittenti.
Dominio personale verso Gmail. Possiedi cool-startup.com e inoltri a founder@gmail.com. Verifica SRS per il mittente della busta e l'autorizzazione SPF del server. Senza riscrittura SPF può fallire, anche per mittenti con DMARC rigoroso; un DKIM valido e allineato può comunque consentire a DMARC di passare.
MSP o agenzia con un cluster condiviso. Ospiti 200 domini e i clienti inoltrano ai propri servizi, come Comcast, AT&T o Outlook. Lo spam ritrasmesso può danneggiare la reputazione dell'IP. Un inserimento in Spamhaus nel giro di settimane è un possibile rischio, non un esito inevitabile; SRS da solo non risolve spam e reputazione.
Microsoft 365 con connettore in uscita. In M365 il comportamento SRS dipende dal percorso e dal tipo di connettore supportato. Verifica la disponibilità di SenderRewritingEnabled nella versione e configurazione utilizzate e modifica le impostazioni solo con l'autorizzazione appropriata. Controlla anche la policy antispam in uscita: il blocco esterno 5.7.520 indica una restrizione di policy, non necessariamente un errore SRS.
Perché SRS non basta
SRS può consentire il successo SPF sul dominio riscritto, ma non ripristina automaticamente l'allineamento DMARC con il From: originale. DMARC richiede che almeno uno dei controlli SPF o DKIM sia valido e allineato a quel dominio. Se SRS usa un dominio diverso dal From:, SPF può passare senza essere allineato; DMARC può allora dipendere da un DKIM valido e allineato che resti intatto.
Alcune modifiche durante l'inoltro possono invalidare DKIM:
- Aggiungere
[EXTERNAL]all'oggetto può invalidare DKIM se quel campo è firmato - Aggiungere testo in fondo, come avvisi antivirus o link di disiscrizione, può cambiare il corpo firmato e invalidare DKIM
- Riscrivere MIME, per esempio da codifica 8-bit a 7-bit, può invalidare DKIM secondo le parti firmate e la canonicalizzazione
In questo scenario SPF non è allineato e DKIM non è più valido: DMARC fallisce. La gestione finale, incluso un eventuale rifiuto, dipende dalla policy del destinatario.
ARC (Authenticated Received Chain, RFC 8617) può fornire ulteriori informazioni. Il server sigilla i risultati osservati prima di inoltrare. Aggiunge tre intestazioni:
ARC-Authentication-Results: registra i risultati SPF, DKIM e DMARC osservati, non necessariamente tutti positiviARC-Message-Signature: firma parti del messaggio nello stato presente al momento della firma, non necessariamente quello originale alla ricezioneARC-Seal: firma crittografica che collega il sigillante alla catena
Gmail può considerare ARC quando SPF e DKIM non consentono a DMARC di passare. Se ritiene attendibile il sigillante e la catena, può usare queste informazioni nella decisione. Non puoi imporre tale fiducia, né garantirla accumulando reputazione nel tempo: resta una scelta del destinatario.
Come verificare il funzionamento di SRS
Invia da un account esterno un messaggio di prova all'indirizzo inoltrato ed esamina le intestazioni complete alla destinazione. Return-Path mostra se in quella consegna compare un mittente riscritto con SRS o l'indirizzo originale. Verifica anche i risultati effettivi di autenticazione.
Passaggio 1: controllare Return-Path alla destinazione
# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>
# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>Passaggio 2: verificare il DNS del dominio SRS
# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf
# Check MX - bounces need a place to go:
dig MX your-domain.comIl dominio riscritto deve autorizzare l'invio tramite SPF e offrire un percorso di ritorno funzionante. Un MX appropriato è normalmente utile, ma la sua assenza non rende sempre il dominio irraggiungibile: in alcuni casi SMTP può usare implicitamente A o AAAA. Verifica la raggiungibilità effettiva e il comportamento dei server, non solo la presenza del record.
Passaggio 3: controllare il log della posta su Linux
grep "srs_forward" /var/log/mail.loghash mismatch o timestamp expired possono dipendere da segreti non sincronizzati, rotazione delle chiavi, ritardi normali, dati alterati o tentativi di abuso: non provano da soli un attacco. Postfix richiede una soluzione SRS integrata, per esempio PostSRSd. Le modalità variano con versione e configurazione. Valuta SRS_EXCLUDE_DOMAINS per i domini locali dove previsto e testa l'instradamento: una mancata esclusione non produce inevitabilmente cicli.
L'alternativa più semplice: evitare l'inoltro
SRS gestisce il mittente della busta quando cambia il server di invio. Una casella reale sul tuo dominio, accessibile tramite IMAP, può evitare il passaggio aggiuntivo di inoltro e i relativi problemi SPF. Non garantisce però autenticazione end-to-end né elimina ogni possibile problema DKIM, DMARC o di accesso: resta necessaria una configurazione corretta.
L'inoltro è diffuso anche perché pagare una licenza per una casella che riceve cinque email al mese può sembrare eccessivo. A volte SRS serve a gestire una scelta dettata dai costi, oltre che esigenze tecniche.
Il modello TrekMail descritto prevede piani da $3.50 al mese, più domini e spazio condiviso a prezzo fisso, senza costi per utente entro i limiti applicabili. Puoi usare sales@yourdomain.com come casella IMAP reale e collegarla a Outlook o a un'integrazione Gmail supportata. Eviti così lo specifico sistema di inoltro, non ogni rischio di autenticazione. Verifica prezzi, funzioni e compatibilità attuali.
Per più clienti, la guida all'hosting email multidominio spiega come organizzare decine di domini e contenere il lavoro amministrativo. Se usi una configurazione ibrida con caselle e inoltri legacy, la guida all'inoltro tramite alias email illustra SRS nel percorso di inoltro.
Che tu mantenga l'inoltro o passi alle caselle, comprendi il ruolo di SRS, verifica che funzioni e valuta ARC se supportato. Un sistema parzialmente configurato può perdere posta legittima: è un rischio aziendale, non soltanto una curiosità tecnica.
Inizia con un account TrekMail gratuito: l'offerta descritta non richiede una carta e non prevede una scadenza della prova. Verifica le condizioni correnti e prova la gestione multidominio senza la complessità dell'inoltro.
