In sintesi – SPF, DKIM e DMARC proteggono il dominio aziendale solo se rispecchiano davvero tutte le sorgenti di invio: server interni, CRM, newsletter, gestionali e piattaforme esterne. Una configurazione realizzata anni fa può non includere più i servizi aggiunti nel tempo, lasciando il dominio esposto a spoofing e impersonificazione. DMARC produce report che segnalano fallimenti e tentativi di abuso ma solo se qualcuno li legge e li interpreta. La posta elettronica aziendale non va solo fatta funzionare: va governata.

La posta elettronica aziendale è uno di quei servizi che vengono dati per scontati fino al giorno in cui qualcosa smette di funzionare. Una newsletter finisce nello spam. Un gestionale non recapita più le notifiche. Un cliente riceve una falsa richiesta di pagamento. Un fornitore segnala un messaggio sospetto. Oppure il dominio aziendale viene usato — o tentato di essere usato — per inviare email che sembrano legittime ma non lo sono.

In molti casi, quando si comincia a indagare, la risposta è sempre la stessa: “Ma la posta ha sempre funzionato.”

Ed è proprio qui il problema.

Una configurazione che sembrava corretta dieci anni fa non è detto che sia corretta oggi. Nel frattempo sono cambiati i provider, sono aumentate le piattaforme esterne, sono entrati in azienda CRM, gestionali, sistemi di ticketing, newsletter, servizi cloud, firme automatiche, inoltri, vecchi server rimasti accesi e account configurati manualmente. La posta elettronica non passa più soltanto dal “server mail dell’azienda”. Spesso esce da molti punti diversi: non sempre censiti, non sempre autorizzati, non sempre firmati correttamente.

SPF, DKIM e DMARC servono proprio a mettere ordine in questo scenario. Ma pubblicare tre record DNS non basta. Il vero lavoro è capire se quei record descrivono davvero il modo in cui l’azienda invia email ogni giorno.

La posta elettronica nasce in un mondo che non esiste più

I primi esperimenti di posta elettronica di rete risalgono al 1971, in un contesto tecnico radicalmente diverso da quello attuale. Allora non esistevano phishing industrializzato, spoofing di dominio, piattaforme marketing cloud, CRM con invii automatici, portali SaaS o supply chain digitali complesse.

L’email si è evoluta nel tempo aggiungendo controlli, policy e strumenti di autenticazione sopra un modello nato quando il livello di fiducia della rete era incomparabilmente più alto. Questo spiega perché molte configurazioni “storiche” continuano a funzionare tecnicamente, ma non sono più adeguate dal punto di vista della sicurezza, della recapitabilità e della governance.

Un server può ancora inviare posta. Un account può ancora spedire messaggi. Un gestionale può ancora produrre notifiche. Una newsletter può ancora partire. Ma questo non significa che tutto sia coerente con SPF, DKIM e DMARC, né che il dominio aziendale sia protetto da abusi o errori silenziosi.

Nel 2026, il tema non è più solo “la posta funziona?”. La domanda corretta è: la posta esce davvero dai server che il dominio dichiara come autorizzati?

SPF, DKIM e DMARC non sono decorazioni DNS

SPF, DKIM e DMARC vengono spesso trattati come tre voci tecniche da sistemare una volta sola. In realtà sono tre strumenti distinti, che funzionano bene soltanto se rappresentano fedelmente l’infrastruttura reale di invio.

SPF indica quali server sono autorizzati a inviare posta per conto di un dominio. Il problema è che molte aziende, nel tempo, accumulano servizi su servizi: Microsoft 365, Google Workspace, CRM, piattaforme newsletter, gestionali, sistemi di fatturazione, ticketing, portali HR, software verticali. Ogni servizio deve essere incluso correttamente. Ma SPF ha anche un limite tecnico critico: la valutazione non deve superare i 10 meccanismi che causano query DNS aggiuntive (come definito dall’RFC 7208). Se il record diventa troppo esteso o disordinato, può fallire restituendo un PermError — proprio mentre cerca di autorizzare troppe sorgenti. E quando SPF fallisce in questo modo, DMARC perde uno dei suoi due pilastri di allineamento.

Il punto è questo: SPF, DKIM e DMARC non servono a “mettere il bollino” sulla posta. Servono a dichiarare, verificare e monitorare l’identità tecnica delle email aziendali.

Se ciò che è scritto nei DNS non corrisponde a ciò che accade davvero, DMARC comincia a mostrare il problema.

Quando DMARC segnala un fallimento, di solito ha ragione

DMARC non è capriccioso: confronta quello che il dominio dichiara con quello che i server riceventi osservano. Se una newsletter parte da una piattaforma non autorizzata, DMARC rileva un fallimento. Se un gestionale invia email senza DKIM configurato correttamente, DMARC rileva un fallimento. Se un account viene usato tramite il server SMTP sbagliato, DMARC rileva un fallimento. Se un vecchio server interno continua a spedire posta — anche se nessuno lo considera più parte dell’infrastruttura ufficiale — DMARC rileva un fallimento.

In altre parole, DMARC non scopre solo gli attacchi. Scopre anche il disordine.

E nelle aziende, il disordine della posta elettronica è molto più comune di quanto sembri.

Il problema dei vecchi server e delle configurazioni ereditate

Molte infrastrutture email aziendali non sono state progettate da zero in modo ordinato. Sono state costruite nel tempo: un provider cambiato, un server migrato, un gestionale aggiunto, una newsletter esternalizzata, un dominio secondario, un sistema di ticketing, un vecchio applicativo che manda notifiche automatiche, un server SMTP interno rimasto attivo “perché tanto serve ancora”.

Questa stratificazione genera debito tecnico. Non solo codice vecchio o software non aggiornato: anche una configurazione che nessuno ha più il coraggio, il tempo o la memoria storica per toccare. La posta continua a funzionare, quindi non viene analizzata. Ma nel frattempo i criteri antispam si sono irrigiditi, i grandi provider valutano con maggiore attenzione l’autenticazione, i clienti sono più esposti a tentativi di frode e i domini aziendali sono diventati asset reputazionali da proteggere.

Una configurazione email vecchia non è per forza sbagliata. Va verificata. Il rischio reale è che l’azienda continui a ragionare come se esistesse un solo server di posta, mentre nella realtà le email escono da molti sistemi diversi.

Open relay, server mal configurati e relay permissivi

Un tema spesso sottovalutato riguarda i relay. Un open relay è un server che consente a soggetti non autorizzati di inviare posta verso terzi: una configurazione che da decenni dovrebbe essere evitata, perché può essere sfruttata per spam e invii non controllati. Oggi un mailserver ben gestito non dovrebbe accettare traffico da open relay e dovrebbe affidarsi anche a controlli reputazionali, blacklist e meccanismi di blocco.

Ma non esistono solo gli open relay evidenti. Ci sono anche configurazioni meno appariscenti ma comunque problematiche: server con comportamenti troppo permissivi, MTA installati frettolosamente, vecchie macchine lasciate attive, applicativi che usano credenziali generiche, account configurati in modo da usare sempre lo stesso server SMTP anche quando il mittente appartiene a un dominio diverso.

In questi casi il problema può non sembrare grave: l’invio parte, il messaggio arriva, l’utente non vede errori. Ma dal punto di vista dell’autenticazione, quella posta può non essere coerente. Ed è qui che nascono molti fallimenti difficili da diagnosticare.

Il caso degli account multipli e del server di uscita sbagliato

Un esempio molto comune riguarda i client di posta configurati con più account. Un utente gestisce cinque, dieci, a volte decine di caselle condivise o alias. Se il client usa sempre lo stesso server SMTP di uscita — oppure se l’account principale spedisce messaggi per identità diverse senza controlli adeguati — il risultato può essere tecnicamente incoerente.

Dal punto di vista dell’utente è tutto normale: seleziona il mittente, scrive e invia. Dal punto di vista del server ricevente, però, il messaggio racconta un’altra storia: un dominio nel campo mittente, un server di invio non previsto, una firma DKIM assente o non allineata, una policy DMARC che non trova corrispondenza tra ciò che viene dichiarato e ciò che sta accadendo.

Un mailserver ben configurato dovrebbe governare queste situazioni. Ma molte infrastrutture non lo fanno, soprattutto quando sono nate per accumulo o per urgenza.

Le newsletter sono spesso il punto in cui il problema emerge

Le piattaforme newsletter rappresentano uno dei casi più frequenti. Un’azienda decide di inviare comunicazioni commerciali o informative usando una piattaforma esterna. Il reparto marketing carica i contatti, crea il template, imposta il mittente con il dominio aziendale e inizia a spedire. Tutto sembra funzionare.

Ma se la piattaforma non è stata autorizzata correttamente in SPF, se DKIM non è configurato sul dominio, se il dominio di ritorno non è allineato, o se DMARC è già impostato in modo restrittivo, la newsletter può generare fallimenti, finire nello spam o danneggiare la reputazione del dominio.

Il punto non è “la newsletter è fatta male”. Il punto è che ogni piattaforma che invia email per conto dell’azienda deve essere trattata come parte dell’infrastruttura email aziendale. CRM, ERP, gestionali, sistemi di marketing automation, portali per preventivi, software di assistenza, piattaforme di fatturazione e strumenti di ticketing devono essere mappati, verificati e configurati in modo coerente.

DMARC senza monitoraggio è un’occasione sprecata

Uno degli errori più frequenti è pubblicare DMARC e poi non leggere i report. Questo approccio trasforma DMARC in una semplice riga nel DNS, non in uno strumento di sicurezza operativo.

I report DMARC servono a ricostruire cosa accade al dominio: quali server stanno inviando email, quali passano SPF o DKIM, quali falliscono, quali sorgenti sono legittime ma non ancora configurate, quali invii sembrano sospetti. I report aggregati offrono il quadro complessivo; quelli di fallimento — quando disponibili e supportati dal sistema ricevente — forniscono informazioni più granulari sui singoli messaggi.

Questo significa che non basta “mettere l’indirizzo dei report”. Serve qualcuno, o qualcosa, che li riceva, li analizzi e li trasformi in decisioni operative.

Un dominio può avere DMARC attivo e continuare a essere configurato male. Un dominio può ricevere report pieni di segnali utili senza che nessuno li guardi. Un dominio può mostrare tentativi di abuso, sorgenti dimenticate o invii non conformi — e l’azienda se ne accorge solo quando il problema diventa visibile a un cliente, a un fornitore o a un sistema antispam.

I segnali tecnici: SpamAssassin, DMARC e l’intelligence operativa

In molte infrastrutture, i sistemi antispam non si limitano a decidere se una mail è buona o cattiva. Raccolgono segnali, applicano regole, verificano reputazione, autenticazione, contenuto e comportamento. SpamAssassin, per esempio, include un plugin DMARC che verifica se i messaggi rispettano la policy dichiarata e richiede che siano abilitati anche i controlli SPF e DKIM. In base alla configurazione, questi sistemi possono contribuire a rendere disponibili dati utili sui fallimenti.

Il principio è importante: l’autenticazione email produce segnali tecnici che possono essere raccolti, analizzati e usati per capire cosa accade davvero. Senza monitoraggio, quei segnali restano rumore. Con il monitoraggio, diventano intelligence operativa.

Il rischio più serio non è lo spam: è l’impersonificazione

Quando si parla di SPF, DKIM e DMARC, molte aziende pensano prima di tutto alla recapitabilità. “Mi serve per non finire nello spam.” È vero, ma è solo una parte del problema.

Il tema più serio è l’impersonificazione. Se un attaccante riesce a inviare email che sembrano provenire dal dominio aziendale, può tentare frodi verso clienti, fornitori, amministrazione, direzione o reparti sensibili: una falsa richiesta di pagamento, una modifica IBAN, una comunicazione tecnica contraffatta, una richiesta urgente del management.

Quando l’attacco è rivolto a figure apicali o soggetti ad alto valore, si parla spesso di whaling — una forma mirata di phishing. In questo contesto, DMARC non elimina il rischio, ma può ridurre la possibilità che email non allineate al dominio vengano considerate legittime dai server riceventi, e può aiutare a ricostruire tentativi di abuso attraverso i report.

Il punto non è poter dire “avevamo DMARC”. Il punto è poter dimostrare che il dominio è stato configurato, monitorato e governato in modo coerente nel tempo.

Il falso senso di sicurezza: “abbiamo Microsoft 365” o “abbiamo Google Workspace”

Microsoft 365 e Google Workspace offrono strumenti solidi per la gestione della posta, ma non risolvono automaticamente tutto ciò che ruota intorno al dominio aziendale. Se tutte le email partissero solo da Microsoft o solo da Google, la situazione sarebbe più semplice. Ma raramente è così.

Molte aziende usano piattaforme esterne per newsletter, CRM, fatturazione, ticketing, preventivi, gestionali, e-commerce, portali clienti, sistemi di notifica, software verticali. Alcune usano più domini. Altre hanno sottodomini. Altre ancora hanno vecchi server interni che continuano a inviare email per applicativi legacy.

La domanda giusta non è: “Uso Microsoft 365 o Google Workspace, sono a posto?”

La domanda giusta è: tutte le email che sembrano uscire dal mio dominio passano davvero da sorgenti autorizzate, firmate e monitorate?

Cosa dovrebbe controllare un’azienda

Un controllo serio della posta elettronica aziendale non si limita a verificare se SPF, DKIM e DMARC esistono. Deve ricostruire il perimetro reale. In concreto, bisogna verificare quali domini e sottodomini inviano email, quali server sono autorizzati da SPF, se il record SPF supera o rischia di superare il limite dei 10 lookup DNS, quali piattaforme esterne inviano email per conto dell’azienda e se tutte firmano correttamente con DKIM. Vanno verificati l’allineamento DKIM al dominio mittente, la policy DMARC attiva (osservazione, quarantena o rifiuto), dove arrivano i report e chi li interpreta con quale frequenza. Non vanno trascurati i vecchi server SMTP, MTA, relay, inoltri o applicativi legacy, né i client di posta con account multipli che potrebbero usare server di uscita incoerenti. Vanno mappati newsletter, CRM, ERP e gestionali, e vanno analizzati i segnali di spoofing, abuso o configurazioni non autorizzate.

Questa analisi non serve solo a “mettere a posto la posta”. Serve a ridurre una superficie di rischio che spesso resta invisibile finché non produce un danno reale.

Cosa succede quando si passa troppo presto a DMARC reject

Impostare DMARC con policy p=reject può essere la scelta giusta, ma solo quando l’infrastruttura è stata mappata e verificata. Passare troppo presto a una policy restrittiva può bloccare email legittime: newsletter, notifiche di gestionali, messaggi automatici, comunicazioni da CRM, sistemi di ticketing o applicativi verticali.

Per questo l’approccio corretto è progressivo: prima si osserva, poi si mappano le sorgenti, poi si correggono SPF e DKIM, poi si analizzano i report, poi — con ragionevole certezza che gli invii legittimi siano allineati — si passa a una policy più restrittiva.

DMARC non deve essere usato come interruttore. Deve essere usato come processo.

Una configurazione email va mantenuta, non solo realizzata

La posta elettronica aziendale non è un impianto che si configura una volta e poi si dimentica. Ogni nuovo servizio può cambiare lo scenario. Ogni nuovo CRM può aggiungere una sorgente di invio. Ogni nuova piattaforma newsletter può richiedere una firma DKIM. Ogni cambio provider può modificare SPF. Ogni vecchio server lasciato acceso può continuare a produrre traffico non documentato. Ogni report DMARC ignorato può nascondere un segnale importante.

La sicurezza della posta elettronica deve entrare nella manutenzione ordinaria dell’infrastruttura IT — non come attività estetica, ma come presidio di sicurezza, continuità operativa e reputazione digitale.

In sintesi

SPF, DKIM e DMARC sono strumenti fondamentali, ma non bastano se vengono trattati come semplici record DNS da pubblicare una volta e dimenticare. Il tema centrale è la coerenza tra ciò che il dominio dichiara e ciò che l’azienda fa davvero quando invia email. Se la posta esce da server vecchi, piattaforme non censite, CRM non configurati, newsletter senza firma DKIM, account multipli con SMTP incoerenti o relay gestiti male, DMARC fa emergere il problema. E se nessuno legge i report, il problema resta lì.

Una configurazione email che funzionava dieci anni fa non è automaticamente adeguata oggi. Nel frattempo sono cambiati i rischi, i controlli, le aspettative dei provider, la complessità delle infrastrutture e il valore del dominio come identità digitale.

La posta elettronica non va solo fatta funzionare. Va governata.

Parla con Alchimie Digitali per una verifica della configurazione email aziendale. Se vuoi capire se la tua posta aziendale è davvero configurata in modo coerente, non limitarti a controllare che “funzioni”. Verifica da dove escono le email, chi le firma, quali server sono autorizzati e chi sta leggendo i segnali che DMARC produce.

FAQ

In sintesi – L’Agenzia per la Cybersicurezza Nazionale (ACN) ha pubblicato le nuove linee guida ufficiali per la configurazione della posta elettronica. Il documento indica come implementare correttamente SPF, DKIM e DMARC – i tre protocolli che autenticano il mittente e proteggono il dominio da phishing e spoofing. Se la tua posta non è configurata secondo questi standard, rischi che le email vengano filtrate come spam o rifiutate dai server destinatari, spesso senza che tu lo sappia. Se hai affidato la gestione della posta a un tecnico o a un’agenzia, è il momento di chiedere una verifica.

L’ACN ha pubblicato le nuove linee guida per l’autenticazione email

L’Agenzia per la cybersicurezza nazionale ha pubblicato le Linee guida per la configurazione del servizio di posta elettronica per l’autenticazione del mittente, con l’obiettivo di rafforzare l’affidabilità del servizio di posta elettronica di tutte le organizzazioni interessate.

Non si tratta di raccomandazioni generiche: è un framework tecnico operativo, rivolto a tutte le organizzazioni pubbliche e private, che stabilisce come configurare correttamente tre protocolli ormai fondamentali per qualsiasi infrastruttura email.

Il documento ufficiale è disponibile sul sito ACN: Framework di Autenticazione per la Posta Elettronica

Perché la posta elettronica è un punto critico

Il funzionamento della posta elettronica si basa sul protocollo SMTP, che non incorpora nativamente meccanismi di autenticazione del mittente né di protezione dell’integrità dei messaggi. Queste vulnerabilità espongono le organizzazioni al rischio di spoofing, phishing e manomissione del contenuto durante il transito.

In termini pratici questo significa che, senza protezioni adeguate, chiunque potrebbe inviare email fingendo di provenire dal tuo dominio — spacciandosi per te con i tuoi clienti, fornitori o colleghi — senza che tu lo sappia e senza che sia necessario accedere al tuo account.

Il problema non è teorico: quasi una organizzazione italiana su quattro non è in grado di impedire a soggetti terzi di inviare email fraudolente a suo nome.

I tre protocolli al centro delle linee guida

Le linee guida dell’ACN forniscono indicazioni operative per la corretta implementazione di SPF, DKIM e DMARC: tre standard ampiamente adottati a livello internazionale che, se configurati in modo coerente, permettono di aumentare il livello di fiducia nei messaggi ricevuti e di limitare l’uso fraudolento dei domini.

DMARC introduce anche il concetto di allineamento: verifica che il dominio visibile nel campo “Da:” corrisponda a quello autenticato via SPF o DKIM, intercettando le impersonificazioni anche nei casi tecnici più sofisticati.

Non è solo sicurezza: è anche recapitabilità

Questo è l’aspetto che le aziende sottovalutano più spesso. I principali provider di posta — Gmail, Microsoft 365, Yahoo — hanno progressivamente irrigidito i loro filtri antispam. Oggi valutano attivamente la presenza e la correttezza di SPF, DKIM e DMARC. Un dominio privo di questi record, o con una configurazione errata, viene automaticamente trattato con più sospetto.

Il risultato è che puoi inviare un preventivo, una conferma d’ordine, una risposta urgente — e il destinatario non la riceve, o la trova nello spam giorni dopo. Il tuo server non ti segnala nessun errore: l’email parte regolarmente. Il problema avviene in silenzio, sul lato del destinatario.

Il collegamento con NIS 2 e il quadro normativo italiano

Le linee guida ACN non sono un documento isolato. Le misure descritte si inseriscono nel contesto della Direttiva NIS 2, del Perimetro di Sicurezza Nazionale Cibernetica e del Regolamento Cloud ACN. In questo scenario, la sicurezza della posta elettronica non è più solo una best practice: per molte organizzazioni diventa un requisito di conformità.

Oggi in Italia sono già stati identificati oltre 21.000 soggetti obbligati dalla NIS 2, di cui almeno 5.000 classificati come essenziali. Per queste realtà, verificare la configurazione della posta non è più rimandabile.

Configurare SPF, DKIM e DMARC: più complesso di quanto sembri

Questi protocolli agiscono sui record DNS del dominio. In teoria bastano poche modifiche. In pratica ci sono insidie frequenti che portano a configurazioni errate, spesso senza che nessuno se ne accorga:

• SPF ha un limite di 10 lookup DNS. Superarlo causa errori su tutte le email in uscita. È un problema comune nelle aziende che usano più servizi in parallelo (CRM, newsletter, gestionale, PEC).
• DKIM richiede la gestione di chiavi crittografiche che vanno protette, ruotate periodicamente e configurate per ogni sorgente di invio.
• Passare subito a p=reject senza una fase di monitoraggio preliminare può bloccare email legittime, creando disservizi immediati.
• L’inoltro automatico delle email (forwarding) può invalidare le verifiche SPF e DKIM se non gestito correttamente.
• I servizi di terze parti — piattaforme di email marketing, CRM, ERP — devono essere esplicitamente inclusi e configurati per firmare con DKIM.

• Vecchi server di posta o MTA installati in modo frettoloso possono comportarsi come relay configurati male, permettendo invii non coerenti con l’identità dichiarata dal dominio.

• Account multipli configurati nello stesso client, se usano sempre il medesimo server di uscita senza controlli adeguati, possono generare invii formalmente funzionanti ma non allineati con SPF, DKIM e DMARC.

L’approccio corretto è graduale: partire con DMARC in monitoraggio per mappare i flussi reali, poi passare a quarantine e reject quando la configurazione è stabile e verificata. 

Avere un record DMARC pubblicato e non monitorarne i report, però, significa perdere gran parte del valore dello strumento. I report servono a capire se qualcuno sta tentando di usare il dominio in modo fraudolento, se una piattaforma legittima è stata dimenticata nella configurazione o se una vecchia impostazione continua a produrre errori silenziosi. In assenza di monitoraggio, DMARC rischia di diventare solo una riga nel DNS, non un presidio reale di sicurezza.

Il punto più delicato è che la posta elettronica aziendale raramente passa da un solo canale. Nel tempo si accumulano piattaforme, vecchi server, gestionali, newsletter, account configurati manualmente, inoltri automatici e servizi terzi. Una configurazione che anni fa sembrava corretta può non esserlo più oggi, soprattutto se nessuno ha mai ricostruito davvero tutte le sorgenti che inviano email per conto del dominio.

Cosa fare adesso

Hai un tecnico o un’agenzia che gestisce la tua posta?

Contattali e chiedi una verifica esplicita su questi quattro punti:

1. 1. Il record SPF è presente, corretto e ottimizzato, entro il limite dei 10 lookup?
   2. Tutte le sorgenti che inviano email per conto del dominio sono state mappate?
   3. DKIM è configurato per tutte le sorgenti di invio, non solo per il client principale?
   4. Le piattaforme esterne, come CRM, newsletter, gestionali e ticketing, firmano correttamente con DKIM?
   5. È presente un record DMARC con una policy coerente con lo stato reale della configurazione?
   6. I report DMARC vengono monitorati regolarmente e interpretati da qualcuno?
   7. Esistono vecchi server, relay, inoltri automatici o account configurati manualmente che possono generare invii non allineati?

Non dare per scontato che sia già tutto a posto. La posta “che funziona” non è la stessa cosa della posta “correttamente autenticata”.

Gestisci direttamente la tua infrastruttura IT?

Segui il percorso raccomandato dall’ACN:

1. 1. Avvia DMARC in modalità `p=none` con indirizzi di report configurati.
   2. Analizza i report per 2–4 settimane e mappa tutte le sorgenti reali di invio.
   3. Verifica che SPF includa solo le sorgenti necessarie e che resti entro il limite dei 10 lookup.
   4. Configura DKIM in modo completo su tutte le sorgenti, comprese piattaforme newsletter, CRM, ERP, gestionali e sistemi automatici.
   5. Controlla che non esistano vecchi server, relay, MTA dimenticati, forwarding o account configurati in modo incoerente.
   6. Passa progressivamente a `p=quarantine` e poi a `p=reject` solo quando la configurazione è stabile e verificata.

In sintesi

Le linee guida pubblicate dall’ACN chiariscono un punto che per anni è stato sottovalutato: la posta elettronica non è un servizio “che funziona o non funziona”, ma un’infrastruttura che deve essere configurata, monitorata e governata.

SPF, DKIM e DMARC non sono più elementi opzionali o tecnici “da specialisti”: sono il livello minimo per garantire affidabilità, protezione del dominio e continuità operativa nelle comunicazioni.

Il punto, però, non è soltanto pubblicare tre record DNS. Il vero lavoro consiste nel verificare se la posta aziendale rispecchia ancora il modo in cui l’organizzazione comunica oggi: server autorizzati, piattaforme esterne correttamente firmate, relay chiusi, account configurati in modo coerente e report DMARC realmente monitorati.

In questo scenario, il vero rischio non è solo subire un attacco, ma non accorgersi che qualcosa non sta funzionando correttamente: email che non arrivano, dominio utilizzato da terzi, reputazione compromessa senza segnali evidenti.

Le indicazioni dell’ACN offrono oggi un riferimento chiaro. Il punto non è tanto “implementarle”, ma essere consapevoli dello stato reale della propria infrastruttura email e delle sue implicazioni in termini di sicurezza e conformità.

Se vuoi capire perché una configurazione email apparentemente corretta può comunque generare errori, blocchi o segnali compatibili con spoofing e phishing, leggi anche il nostro approfondimento su vecchi server, relay configurati male, newsletter non allineate e report DMARC ignorati.

Fonte ufficiale: ACN — Framework di Autenticazione per la Posta Elettronica Articolo redatto da Alchimie Digitali

FAQ

Redirect e Forward nel 2025: cosa è cambiato, perché sono più importanti di prima e come scegliere l’approccio corretto

Articolo aggiornato dell’originale del 28 settembre 2019

Introduzione

Dal 2019 al 2025 il modo in cui web server, CDN e applicazioni gestiscono routing, reindirizzamenti e riscritture interne è cambiato profondamente.

L’arrivo di HTTP/2, HTTP/3, l’adozione massiva di reverse proxy (Nginx, Traefik, Envoy) e la crescita di architetture basate su API, microservizi e Single Page Application richiede una revisione completa del tema redirect vs forward.

L’articolo del 2019 rimane valido nelle fondamenta, ma oggi il contesto è molto più complesso e interconnesso.

Ecco quindi la versione aggiornata al 2025.

Riepilogo dei concetti fondamentali: redirect vs forward (versione 2025)

Redirect

Una risposta HTTP che istruisce il browser a effettuare una nuova richiesta verso una nuova URL.

Caratteristiche:

• L’URL visibile cambia

• Il browser effettua una nuova richiesta

• I codici più usati: 301, 302, 307, 308

• Ideale per SEO, migrazioni, canonicalizzazioni, HTTPS, login/logout

Forward (o Internal Rewrite)

Il server o reverse proxy riscrive internamente la richiesta, senza cambiare l’URL visto dal client.

Caratteristiche:

• Il browser non vede cambiamenti

• Nessuna nuova richiesta HTTP

• Ideale per routing interno, microservizi, API Gateway, SPA

Cosa è cambiato dal 2019 al 2025

Evoluzione dei protocolli

• HTTP/2 e HTTP/3 hanno ridotto la latenza, ma le catene di redirect sono più penalizzate

• I motori di ricerca e le AI Overview interpretano i redirect come segnali semantici strutturali

Diffusione dei reverse proxy

Oggi quasi tutte le applicazioni utilizzano un livello intermedio che gestisce routing, compressione, caching, riscritture, load balancing, sicurezza.

Il forward è diventato una pratica quotidiana.

SPA (React, Vue, Angular)

Le SPA richiedono quasi sempre rewrite interni:

try_files $uri /index.html;

Sicurezza 2025

Particolare attenzione a:

• open redirect

• redirect cross-domain

• meta refresh lato client

• conflitti tra regole CDN e server

Email routing e autenticazioni SPF/DKIM/DMARC

Nel 2025 forward e redirect lato mail possono:

• invalidare SPF

• annullare DKIM

• violare DMARC

Un forward che modifica gli header è rischioso.
Un redirect che preserva gli header è generalmente preferibile.

Impatto SEO e GEO

Le AI Overview valutano i redirect come segnali algoritmici:

• 301 e 308 consolidano l’autorità semantica

• 302 indica contenuto instabile

• catene multiple riducono coerenza e interpretabilità

Quando usare un redirect nel 2025

• Migrazioni URL

• Canonicalizzazioni (www, slash/no-slash)

• Passaggio HTTPS

• Login/logout

• Regole su CDN come Cloudflare, Fastly

Esempio redirect Nginx:

return 308 https://$host$request_uri;

Quando usare un forward/rewrite nel 2025

• Microservizi

• API Gateway

• Web server come layer di orchestrazione

• SPA routing

• Offuscamento struttura interna

Esempio Nginx API Proxy:

location /api/ {
    proxy_pass http://backend-service:8080/;
}

Forward per SPA:

try_files $uri /index.html;

Esempi aggiornati per Apache, Nginx, Node e CDN

Apache – Redirect

Redirect 301 /pagina-vecchia /pagina-nuova

Apache – Rewrite

RewriteRule ^app/(.*)$ /index.php?route=$1 [L]

Node.js / Express – Redirect

app.get('/old', (req, res) => {
  res.redirect(301, '/new');
});

Node.js / Express – Forward tramite proxy

app.use('/api', createProxyMiddleware({
  target: 'http://backend:8080'
}));

Redirect e forward nel JAMStack (Netlify, Vercel, Cloudflare Pages)

Netlify — file _redirects

/old-url   /new-url   301

Vercel — rewrites.json

{
  "source": "/api/:path*",
  "destination": "https://backend.example.com/:path*"
}

Cloudflare — Redirect Rule (rappresentazione logica)

IF (http.host eq "example.com" AND http.request.uri.path eq "/old")
THEN
  STATIC_REDIRECT to "https://example.com/new" status_code = 301

Errori comuni nel 2025

• Catene di redirect non ottimizzate

• Meta refresh lato client

• Rewrite che espongono endpoint sensibili

• Loop CDN ↔ reverse proxy ↔ app server

• SPA senza fallback (404)

• Forward email che rompono DMARC

Tabella Comparativa

Conclusioni

Nel 2025 redirect e forward non sono più semplici strumenti tecnici, ma componenti fondamentali della progettazione moderna.

Impattano direttamente su:

• SEO

• sicurezza

• deliverability email

• performance

• coerenza semantica percepita dalle AI

Il nostro articolo del 2019 rimane la base. Questa versione aggiornata riflette le esigenze delle infrastrutture moderne.

Domande frequenti dei clienti