Inoltro email con SRS: SPF, DMARC e limiti

Hai configurato un inoltro: contact@yourdomain.com invia i messaggi a Gmail. Funziona per una settimana, poi alcune email dei clienti non arrivano e non trovi subito una notifica di mancato recapito. Nei log compaiono 550 5.7.1 Unauthenticated email oppure 550 5.7.26 This message does not have authentication information. Questi errori possono avere più cause; l'inoltro email con SRS affronta uno dei problemi possibili. Il server apre una nuova connessione SMTP mantenendo nel mittente della busta il dominio originale. Se SPF non autorizza il nuovo IP, la verifica può fallire. Con DMARC p=reject, in assenza di SPF o DKIM valido e allineato, il destinatario può rifiutare il messaggio secondo la propria politica. Un rifiuto SMTP può generare una notifica: non è sempre una perdita silenziosa.

Attivare SRS non risolve ogni problema. L'allineamento DMARC può ancora fallire anche con una riscrittura corretta. Per esaminare le diverse cause e diagnosticarle, consulta la guida alla configurazione e alla risoluzione dei problemi di inoltro.

Che cos'è l'inoltro email con SRS?

L'inoltro email con SRS, Sender Rewriting Scheme, riscrive il mittente della busta quando un server inoltra un messaggio. Usa il dominio del servizio di inoltro nell'indirizzo tecnico di ritorno, consentendo di verificare SPF rispetto a quel dominio. Il risultato dipende da DNS e autorizzazione dell'IP. Il From visibile resta quello originale. SRS non cifra il messaggio e non nasconde le intestazioni: agisce sulla busta SMTP, i cui dati possono comparire nelle intestazioni complete.

Postfix può integrare SRS tramite il demone postsrsd. Microsoft 365 e alcuni servizi gestiti lo supportano in determinati percorsi, comprese configurazioni ibride. Versione, connettori e impostazioni vanno verificati. SRS affronta il rapporto tra l'inoltro SMTP e SPF, ma non risolve da solo tutti i requisiti DMARC.

Perché l'inoltro può fallire: il nuovo passaggio SMTP

Ogni inoltro aggiunge un passaggio SMTP, che può far fallire SPF se il nuovo IP non è autorizzato. Le email hanno due identità distinte. Header From (RFC 5322) è il mittente visibile, per esempio From: alice@client.com. Envelope Sender (RFC 5321, MAIL FROM) è l'indirizzo tecnico usato per SPF e le notifiche di mancato recapito. Di solito non appare nella vista ordinaria, ma può essere letto nelle intestazioni complete.

Ecco una possibile sequenza di errore, non l'esito inevitabile di ogni inoltro:

1. Alice invia da alice@client.com. SPF autorizza il suo server e la verifica passa all'arrivo sul tuo.
2. Il tuo server apre una nuova connessione SMTP verso you@gmail.com. Ora il collegamento proviene dal tuo IP.
3. Il mittente della busta resta alice@client.com, ma nell'esempio SPF di client.com non autorizza il tuo IP.
4. Gmail verifica SPF per client.com e, in assenza dell'autorizzazione, la verifica fallisce.
5. Se client.com pubblica p=reject, manca anche un DKIM valido e allineato e il destinatario applica il rifiuto, il messaggio può essere respinto. Il server di inoltro può ricevere l'errore e inviare una notifica.

Come SRS può risolvere il problema SPF

L'inoltro email con SRS riscrive il mittente della busta prima del nuovo invio, usando il dominio del servizio di inoltro. Il destinatario verifica quindi SPF per quel dominio. La verifica può passare se il record attuale autorizza l'IP effettivo. Header From non cambia. Le notifiche di mancato recapito tornano al servizio di inoltro, che può verificare l'indirizzo SRS e instradarle verso il mittente originale secondo la propria configurazione.

Leggere la sintassi SRS

Con SRS, il semplice indirizzo di ritorno viene sostituito da un indirizzo strutturato con un codice di autenticazione. È una riscrittura, non una cifratura:

Prima di SRS: MAIL FROM: <alice@client.com>
Dopo SRS: MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>

In un secondo inoltro (A → B → C), il servizio può usare SRS1. Questo formato limita la crescita dell'indirizzo anziché annidare ogni volta l'intera stringa SRS0; i dettagli non si riducono al solo hash e timestamp e dipendono dall'implementazione. Va comunque verificato il limite di 64 caratteri della parte locale previsto da RFC 5321: SRS non garantisce che qualsiasi indirizzo vi rientri.

Perché SRS non basta: il problema DMARC

Molti amministratori attivano l'inoltro email con SRS e considerano concluso il lavoro, ma i messaggi possono ancora finire nello spam o essere rifiutati. SRS può risolvere SPF senza conservare l'allineamento DMARC. DMARC richiede SPF oppure DKIM valido, con il dominio allineato a Header From. Dopo la riscrittura, SPF può autenticare yourdomain.com, mentre Header From resta client.com. Questi domini distinti non sono allineati nell'esempio. Le regole di allineamento rilassato possono però consentire altri casi con lo stesso dominio organizzativo.

Se SPF non è allineato, un DKIM valido e allineato può ancora far passare DMARC. Alcune modifiche durante l'inoltro possono compromettere la firma, secondo le parti firmate e la canonicalizzazione:

• Aggiunta di [EXTERNAL] all'oggetto, se quella parte è firmata
• Aggiunta di note antivirus o avvertenze legali al corpo firmato
• Conversione della codifica da 8-bit a 7-bit
• Modifica dei delimitatori MIME

Queste modifiche non fanno fallire ogni firma in ogni caso: conta ciò che DKIM firma e come lo normalizza. Se non resta né SPF né DKIM valido e allineato, DMARC fallisce. Il destinatario può allora filtrare o rifiutare il messaggio secondo le proprie politiche, anche se SRS ha funzionato.

Il ruolo di ARC (Authenticated Received Chain)

ARC (RFC 8617) permette al servizio di inoltro di attestare i risultati di autenticazione effettivamente osservati. Il momento della verifica e della sigillatura dipende dal flusso del servizio. Aggiunge tre intestazioni:

• ARC-Authentication-Results: registra i risultati osservati di SPF, DKIM e DMARC, compresi gli eventuali errori
• ARC-Message-Signature: firma intestazioni e corpo secondo il messaggio al momento della sigillatura
• ARC-Seal: collega crittograficamente il nuovo insieme ARC alla catena precedente

Se la catena è valida e il destinatario considera affidabile il servizio che la sigilla, può usare ARC per decidere di accettare un messaggio anche dopo un errore DMARC. ARC non cambia l'allineamento né garantisce il recapito. Gmail valuta i sigilli ARC in produzione dal 2019.

Nel 2026, una configurazione robusta può combinare inoltro con SRS, conservazione delle parti firmate da DKIM e ARC quando utile e supportato. Non sono tre condizioni universalmente necessarie o sufficienti: il risultato dipende dall'autenticazione originale e dalla politica del destinatario.

Configurare SRS sulle diverse piattaforme

Le procedure variano. Postfix può usare un demone esterno; Microsoft 365 applica proprie regole di inoltro e connettori; Google Workspace ha meccanismi gestiti con limiti e controlli. Verifica le impostazioni correnti: non presumere che tutto sia disattivato o attivato per impostazione predefinita.

Postfix su Linux autogestito

Una possibile integrazione SRS per Postfix usa postsrsd. Il comando seguente è un esempio per distribuzioni compatibili, da verificare prima di qualsiasi modifica autorizzata:

apt-get install postsrsd

Il seguente esempio storico configura /etc/postfix/main.cf con mappe TCP di postsrsd. Versioni più recenti possono richiedere socket e sintassi differenti. Salva la configurazione attuale e integra le mappe esistenti, senza sovrascriverle alla cieca:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Da verificare: l'opzione SRS_EXCLUDE_DOMAINS in /etc/default/postsrsd, se prevista dalla versione, può escludere i domini locali dalla riscrittura. Verifica percorsi, mappe, permessi dei socket ed esclusioni, poi prova i flussi. Un'esclusione errata può riscrivere messaggi propri o contribuire a problemi di instradamento; non genera necessariamente un ciclo.

Microsoft 365

M365 gestisce SRS in determinati percorsi di uscita; verifica comportamento e configurazione attuali, soprattutto con ambienti ibridi o connettori verso gateway esterni. La risposta 550 5.7.520 Access denied, Your organization does not allow external forwarding indica una restrizione della politica di inoltro, non prova un guasto SRS.

Questa restrizione richiede una revisione di sicurezza. Un amministratore autorizzato può verificare Security Center → Policies & Rules → Anti-spam → Outbound spam filter policy e consentire soltanto gli inoltri approvati. Il comando seguente è un esempio della configurazione descritta: parametro e disponibilità possono variare o non essere supportati. Conferma la procedura valida per il tenant e la versione; non usarlo come istruzione universale:

Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $true

Google Workspace

Google usa un meccanismo di inoltro gestito. Tra i possibili problemi, non esclusivi di Workspace, ci sono:

• Limiti di volume: un catch-all che inoltra spam può consumare le quote e portare a limitazioni. Un'eventuale sospensione dipende dalle politiche e dal caso.
• Rilevamento dei cicli: alcuni messaggi possono essere scartati per evitare cicli. La visibilità dipende da log, strumenti amministrativi e percorso; non significa che manchi sempre ogni traccia.

Diagnosticare gli errori nell'inoltro con SRS

Le intestazioni complete aiutano a diagnosticare l'inoltro. Invia una prova da ProtonMail e controlla il messaggio ricevuto alla destinazione finale. Se è stato rifiutato, le intestazioni possono non essere disponibili: usa anche log SMTP, tracciamento e risposta completa. Non ogni causa è riconoscibile dalle sole intestazioni.

Controllo 1: Return-Path

Esempio senza riscrittura SRS: Return-Path: <original@protonmail.com>
Esempio con riscrittura SRS: Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>

Un Return-Path originale può indicare un demone non attivo o un'integrazione errata, ma anche un'esclusione o un percorso che non passa da SRS. Verifica il flusso e i log prima di concludere.

Controllo 2: Authentication-Results

Cerca spf=pass associato al dominio di riscrittura. Se compare dmarc=fail, DKIM può essere assente, non valido oppure valido ma non allineato; anche SPF può non essere allineato al From originale. Controlla il dominio firmatario e le eventuali modifiche a corpo e oggetto.

Controllo 3: DNS

dig yourdomain.com TXT +short

Verifica che SPF del dominio di riscrittura autorizzi l'IP effettivo e che l'indirizzo di ritorno sia raggiungibile. Gli MX sono un elemento importante, ma la loro assenza non prova da sola l'impossibilità di ricevere: SMTP può usare un MX implicito tramite A o AAAA. Controlla instradamento e risposte reali, non soltanto la presenza di un record.

Controllo 4: log Postfix

grep "srs_forward" /var/log/mail.log

hash mismatch o timestamp expired possono dipendere da chiavi diverse tra nodi, rotazione delle chiavi, orologi, scadenze o configurazione. Anche riuso di vecchi indirizzi e tentativi di replay sono possibili, ma gli errori da soli non provano un attacco. Verifica il contesto prima di attribuire il backscatter a una causa specifica.

Quando rinunciare all'inoltro con SRS

L'inoltro email con SRS affronta una difficoltà strutturale del passaggio intermedio. SRS, conservazione DKIM e ARC possono richiedere componenti e controlli aggiuntivi. Un apparente risparmio sulle licenze per utente può ridursi includendo il tempo di amministrazione, ma il confronto dipende dalla tua infrastruttura.

Confronta i due approcci:

TrekMail descrive un piano a tariffa fissa con spazio condiviso tra caselle e domini, anziché una tariffa per utente. Non significa pagare soltanto lo spazio né avere capacità illimitata. Per le agenzie, confronta questo modello con un normale inoltro verso Gmail o leggi la guida ai compromessi dell'inoltro tramite alias. Per scegliere tra alias e caselle vere, consulta il confronto tra alias di dominio e casella.

Ricevere direttamente nelle caselle TrekMail elimina il passaggio di inoltro per quei messaggi, quindi SRS e ARC non sono necessari per quel solo passaggio. L'autenticazione in uscita resta da configurare e verificare, anche con una procedura guidata. Il server indicato dagli MX non è per questo automaticamente autorizzato a inviare: SPF, DKIM, DMARC ed eventuale SMTP esterno dipendono da percorso, provider e piano.

Prova TrekMail: l'offerta descrive Nano senza carta oppure una prova di 14 giorni di Starter da $3.50/mese con SMTP gestito. Verifica disponibilità, requisiti, prezzo e condizioni attuali.

Riepilogo

L'inoltro email con SRS è uno strumento utile nelle architetture di inoltro del periodo 2025-2026, non un requisito universale. Senza riscrittura, SPF può fallire al nuovo passaggio. Anche con SRS e SPF valido, il dominio autenticato può non essere allineato al From. Un DKIM valido e allineato può ancora far passare DMARC; il rifiuto dipende dalle politiche del destinatario.

Su Postfix, una possibile integrazione usa postsrsd, mappe in main.cf ed esclusioni da verificare per versione. Su M365, controlla il percorso gestito e la politica di inoltro, modificandola soltanto con autorizzazione. Su Google Workspace, verifica quote, controlli dei cicli e strumenti amministrativi, senza presumere sospensioni o assenza di log.

SRS, conservazione delle parti firmate da DKIM e ARC possono migliorare la gestione dell'inoltro, ma non sono sempre tutti necessari né garantiscono il recapito. In alternativa, valuta una casella nella destinazione effettiva, continuando a verificare autenticazione, accesso e limiti.