Guida Red Sift alla configurazione dei protocolli email

In questo capitolo abbiamo risposto ad alcune delle domande più comuni che i nostri Customer Success Engineers ricevono riguardo a SPF, DKIM e DMARC: i tre pilastri dell'autenticazione email moderna. Dal 2026, questi protocolli saranno richiesti dai principali provider di caselle di posta per i mittenti di email massive. Approfondiamo!

Usa questa lista per controllare di aver coperto l’essenziale. Spunta i punti in ordine: ogni passaggio si basa sul precedente.

1. Pubblica un solo record SPF TXT sul tuo dominio Return-Path
2. Conferma che ogni indirizzo IP autorizzato per l’invio sia incluso nel record
3. Controlla di non aver superato il limite di 10 ricerche DNS (usa Red Sift's SPF Checker per verificare)
4. Usa ~all (soft fail), non -all, così DMARC potrà gestire l’enforcement
5. Assicurati che il dominio Return-Path sia allineato con il dominio visibile nel campo From:

1. Assicurati che tutti i servizi di invio supportino e firmino attivamente con DKIM
2. Utilizza chiavi di almeno 2048 bit
3. Verifica che il dominio di firma (d=) sia allineato con il dominio From:
4. Dai nomi chiari ai selector per identificare ogni servizio di invio
5. Ruota le chiavi con regolarità e revoca quelle compromesse

1. Pubblica un record DMARC TXT — inizia con p=none per raccogliere i report
2. Punta rua= a un processore di report (ad es. Red Sift OnDMARC) per rendere i dati aggregati azionabili
3. Controlla i report ogni settimana per identificare mittenti sconosciuti o mal configurati
4. Quando tutte le fonti legittime superano SPF o DKIM con allineamento, passa a p=quarantine
5. Procedi a p=reject per bloccare completamente le email contraffatte — l’obiettivo è 6–8 settimane con gli strumenti adeguati

Bonus: sicurezza del trasporto

1. Implementa MTA-STS prima in modalità test, poi passa a enforce dopo aver esaminato i report TLS
2. Aggiungi TLS-RPT per ottenere visibilità sui fallimenti di consegna causati da problemi TLS

Configurare SPF e DKIM non garantisce che tutte le fonti di invio restino autenticate. Alcune lacune fanno fallire le email legittime senza un errore evidente:

• Sottodomini non protetti. Un sottodominio senza un record SPF o DKIM può essere contraffatto anche se il dominio principale è ben protetto.
• Mittenti terzi. Piattaforme marketing, CRM e sistemi di supporto spesso inviano per conto tuo con la loro infrastruttura, ognuno necessita della propria autenticazione.
• Drift nei record DNS. Cambiamenti infrastrutturali, come un nuovo provider di posta o il decommissionamento di uno strumento, lasciano record SPF inclusi o selector DKIM obsoleti, che possono far fallire mittenti reali.
• Forwarding rotto. Le firme DKIM possono diventare invalide se l’email viene inoltrata da un servizio che riscrive le intestazioni o altera il corpo.
• Gestione client incoerente. Client di posta mobili e desktop non valutano l’autenticazione allo stesso modo, così un messaggio può finire in modo diverso a seconda di dove viene aperto.
• Propagazione della reputazione. I fallimenti di autenticazione si accumulano. Un dominio che fallisce ripetutamente i controlli costruisce una cattiva reputazione da mittente che peggiora la consegna anche dei messaggi validi.

Identifica queste criticità prima che si traducano in email mai recapitate: effettua un inventario completo di ogni dominio e sottodominio che invia email per tuo conto e verifica separatamente SPF, DKIM e DMARC per ciascuno.

SPF (Sender Policy Framework) è uno standard di autenticazione email ideato per combattere la falsificazione degli indirizzi del mittente. Verificando l’autenticità delle identità MAIL FROM o HELO/EHLO durante la trasmissione, SPF confronta l’indirizzo IP del server mittente con una lista di mittenti autorizzati specificata in un record TXT nel DNS del proprietario del dominio. Se l’indirizzo IP mittente corrisponde a uno di quelli autorizzati, l’autenticazione SPF ha successo. 

SPF si concentra sul “dominio” presente nell’intestazione email, chiamata anche Return-Path, MAIL-FROM, Bounce address o Envelope from. Se questa intestazione manca, SPF esamina il nome host “HELO/EHLO” e cerca lì il record SPF.

L’intestazione Return-Path è tecnica e non visibile all’utente finale — a meno che non sappiano visualizzare tutte le intestazioni in una mail, non la vedranno. 

DKIM (DomainKeys Identified Mail) serve a firmare differenti campi di intestazione e i corpi delle email per autenticare il dominio mittente e prevenire la modifica dei messaggi durante il transito.

Lo fa utilizzando la crittografia asimmetrica, che si basa su una coppia di chiavi pubblica e privata. La chiave privata resta riservata al dominio mittente e viene usata per firmare le email. La chiave pubblica è pubblicata nel DNS e può essere recuperata da chiunque riceva email da tale mittente.

Quando un’email viene composta, intestazione e corpo sono firmati usando la chiave privata del mittente, creando una firma digitale che viene inclusa tra le intestazioni dell’email. Sul lato del destinatario (se abilitato DKIM), il server recupera la chiave pubblica e verifica se l’email è stata effettivamente firmata dal dominio mittente. Una convalida con successo dimostra che il dominio mittente ha inviato il messaggio e che intestazioni e corpo non sono stati modificati durante la trasmissione.

DKIM si concentra sull’intestazione “DKIM-Signature”.

Proprio come per SPF, questa intestazione non è visibile all’utente finale a meno che non sappiano visualizzare tutte le intestazioni dell’email ricevuta.

1. La maggior parte dei problemi di autenticazione email deriva sempre dagli stessi motivi. Fai bene questi tre punti e risolverai il 90% dei problemi di deliverability e sicurezza.
2. Pubblica un record DMARC a p=reject Inizia con p=none per raccogliere i report, ma non fermarti lì. Una policy di sola monitoraggio non ti protegge. Passa a p=reject quando hai identificato e configurato tutti i mittenti legittimi. Questo dice ai server riceventi di bloccare le email che non superano l’autenticazione.
3. Assicurati che SPF e DKIM siano allineati con il dominio From: SPF e DKIM possono entrambi passare e potresti comunque fallire DMARC se i domini non corrispondono. Verifica che il dominio Return-Path (per SPF) e il dominio di firma DKIM (d=) coincidano o siano sottodomini dell’indirizzo From: visibile. È proprio qui che molte organizzazioni si bloccano.
4. Monitora i tuoi report DMARC ogni settimana I report DMARC ti dicono esattamente chi invia email a tuo nome e se queste passano l’autenticazione. Utilizza una piattaforma come Red Sift OnDMARC per trasformare l’XML grezzo in dati azionabili. Intercetta le configurazioni errate prima che diventino problemi di deliverability.

Perché SPF & DKIM non bastano: anche se DKIM può verificare che un’email non sia stata alterata e SPF può consigliare a un server ricevente di rifiutare un’email in base all’IP, nessuno dei due da solo previene efficacemente la contraffazione. Ecco perché DMARC è diventato obbligatorio per le organizzazioni che inviano email massive nel 2026.

Il motivo principale sta nell’intestazione controllata da ciascun protocollo.

SPF controlla il record trovato al dominio presente nell’intestazione return-path, DKIM controlla la chiave dichiarata nel dominio d= (presente nell’intestazione DKIM).

Entrambi i protocolli possono essere impostati per verificare qualsiasi dominio.

Nell’email, il dominio principale del mittente è quello del campo From:, ovvero il “nome grosso” in cima alle email che l’utente finale vede per identificare chi ha inviato il messaggio.

Alla luce di ciò, il tuo dominio potrebbe essere falsificato: un attaccante potrebbe impostare From: su yourdomain.com e return-path e d= sul proprio dominio. Se i record SPF e DKIM su theirdomain.com sono configurati correttamente, l’email passerebbe sia SPF che DKIM risultando in una contraffazione efficace del tuo dominio.

SPF e DKIM hanno scopi importanti, ma nessuno dei due permette di prevenire l’imitazione da solo.

DMARC sta per Domain-based Message Authentication, Reporting and Conformance e si basa su SPF e DKIM, offrendo un ulteriore livello di autenticazione email e enforcement delle policy. DMARC è ora richiesto dai principali provider ed è lo standard di settore per l’autenticazione email nel 2026.

DMARC fa alcune cose fondamentali:

1. Prende in considerazione i risultati di SPF e DKIM
2. Affinché DMARC passi, richiede che SPF o DKIM passino e che il dominio usato da uno dei due sia allineato al dominio presente in From:. Se vuoi saperne di più su Identifier Alignment, clicca qui.
3. Riporta i risultati SPF, DKIM e DMARC al dominio trovato in From: (cioè al mittente).
4. Infine, indica ai server riceventi come trattare le email che non passano DMARC specificando una policy nel DNS.

Impostando la policy DMARC su p=reject un’organizzazione può dire ai server riceventi di scartare qualunque email inviata a nome del proprio dominio che non superi il controllo di allineamento. Questo ferma qualsiasi tentativo di imitazione laddove DMARC è correttamente implementato sul ricevente.

DMARC si concentra sul dominio presente nell’intestazione From: o Header from, che è visibile all’utente finale. 

SPF verifica se una email è stata inviata da un mittente autorizzato controllando una lista di indirizzi IP autorizzati che pubblichi sul DNS. Il server ricevente prende il dominio presente nell’intestazione Return-Path e controlla se esiste un record SPF. Esamina quest’ultimo per vedere se l’indirizzo IP mittente compare tra quelli autorizzati; se sì, SPF PASSA, altrimenti SPF FALLISCE.

La logica generale è:

• Se l’indirizzo IP mittente è contenuto nel record SPF = SPF PASS
• Se l’indirizzo IP mittente non è contenuto nel record SPF = SPF FAIL

Il server ricevente controlla l’intestazione DKIM-Signature, che include il selector (s=) e il dominio di firma (d=) necessari per recuperare la chiave pubblica. Recuperata la chiave, viene usata per validare il messaggio. Se la validazione va a buon fine, DKIM PASSA, altrimenti DKIM FALLISCE.

La logica generale è:

• Se la validazione va a buon fine = DKIM PASS
• Se la validazione non va a buon fine = DKIM FAIL

Il server ricevente controlla se SPF o DKIM sono PASSATI, poi verifica se il dominio Return-Path usato da SPF e/o il dominio d= usato da DKIM si allineano con il dominio From:, ed estrae la policy DMARC pubblicata dal dominio From: applicandola.

La logica generale è:

• Se SPF PASSA e SI ALLINEA con il dominio “From” = DMARC PASS, oppure
• Se DKIM PASSA e SI ALLINEA con il dominio “From” = DMARC PASS
• Se entrambi SPF e DKIM FALLISCONO = DMARC FAIL

DMARC non richiede solo che SPF o DKIM passino, ma anche che i domini usati da uno di loro siano ALLINEATI con il dominio presente in

From:. Solo allora DMARC PASSA.

Strict alignment significa che il dominio Return-Path o quello di firma “d=” deve corrispondere esattamente al dominio nell’indirizzo From:.

Relaxed alignment significa che il dominio Return-Path o il dominio di firma “d=” possono essere un sottodominio del dominio From: o viceversa.

Se vuoi approfondire l’allineamento degli identificatori, clicca qui.

Se DMARC fallisce, il server ricevente normalmente applicherà la policy specificata nel tuo record DMARC.

• Se sei in modalità solo report (p=none) l’email verrà accettata e sottoposta a ulteriori filtri.
• Se sei in modalità quarantena (p=quarantine) l’email sarà messa in quarantena e di solito finirà nella cartella spam del destinatario.
• Se sei in modalità reject (p=reject) il server ricevente interromperà la connessione col server mittente e l’email non arriverà mai all’utente finale.

A prescindere dalla policy, i metadati delle email saranno registrati insieme allo stato dell’autenticazione e inoltrati al tuo processore di report DMARC. Scopri di più sui report DMARC qui.

Avere SPF e DKIM configurati a regola d’arte sulla carta non significa che funzionino ovunque come pensi tra domini, sottodomini e fonti di invio. Prima di passare al troubleshooting specifico, fatti un quadro chiaro della postura attuale di autenticazione.

Elenca ogni dominio e sottodominio che invia email per tuo conto, includendo quelli usati da strumenti marketing, CRM e supporto. Per ognuno registra lo stato di SPF, DKIM e DMARC.

Recupera tassi di bounce, reclami spam e problemi di consegna dai principali provider di invio. Confrontali con strumenti di reputazione dominio come Google Postmaster Tools per scoprire dove mancano autenticazioni che ti costano posizionamento in inbox.

Per ogni dominio, valuta l’impatto per il business se venisse spoofato. Un dominio usato solo per tool interni comporta rischi diversi rispetto a quello sulle fatture clienti. Dai priorità ai fix in base a questo impatto e non a quale intervento è più semplice.

Ripeti questa valutazione ogni trimestre. Nuove fonti d’invio e cambi infrastrutturali sono la causa più frequente dei problemi in configurazioni che prima funzionavano.

Le organizzazioni a volte pensano che l’autenticazione email completa richieda budget da enterprise. In realtà il costo dipende dalla complessità, non dall’ampiezza della protezione.

Cinque fattori lo determinano: volume di invio, complessità infrastrutturale (quanti domini, sottodomini e servizi terzi usi), quanta expertise interna hai, conformità normativa del settore e quanto serve integrare personalizzazioni.

Alcune situazioni portano il rischio di una cattiva autenticazione ben oltre il costo di sistemarla:

• Fusione e acquisizione. Integrare infrastruttura email tra più domini e sistemi legacy crea lacune di autenticazione che gli attaccanti cercano proprio nella fase di transizione.
• Settori regolamentati. Sanità e finanza affrontano obblighi di compliance sulla sicurezza email. Un provider che manda comunicazioni non autenticate ai pazienti rischia multe HIPAA milionarie.
• Obiettivi di valore. Le aziende con dati sensibili o transazioni elevate sono bersagli per il business email compromise. Un produttore ha perso 2,3 milioni di dollari dopo che attaccanti hanno usato lo spoofing di dominio per deviare un bonifico.
• Operazioni globali. Più regioni, lingue e regimi normativi moltiplicano le fonti di invio da autenticare in modo coerente.

Fra tutte le organizzazioni che hanno subito un attacco di spoofing riuscito nel 2023, le perdite hanno superato i 18 milioni di dollari secondo dati FBI.

1. Assicurati di avere un record SPF nel dominio Return-Path.
2. Assicurati di avere un record SPF nel dominio HELO/EHLO per i bounce in cui il Return-Path è vuoto.
3. Assicurati che esista un solo record SPF per dominio.
4. Assicurati che la sintassi del record SPF sia corretta.
5. Assicurati che il dominio Return-Path sia allineato col domínio From.
6. Assicurati che i mittenti autorizzati siano inclusi nel record SPF.
7. Assicurati che i mittenti non autorizzati NON siano presenti nel record SPF.
8. Assicurati di non oltrepassare il limite di 10 lookup DNS imposto da SPF. Se lo superi, valuta l’uso di una funzione come il Dynamic SPF di Red Sift OnDMARC.
9. Assicurati di non usare meccanismi SPF deprecati come “ptr”.
10. Rendila semplice lavorando con un fornitore DMARC come Red Sift

1. Assicurati che i sistemi di invio supportino DKIM.
2. Assicurati che le email siano firmate DKIM.
3. Assicurati che il dominio di firma sia allineato al campo “From”.
4. Assicurati che la chiave DKIM sia oltre i 1024 bit (2048 bit è consigliato)
5. Cerca, dove possibile, di scegliere selector DKIM che rappresentino chiaramente il servizio di invio per distinguerli.
6. Revoca tutte le chiavi che sono state compromesse.
7. Ruota regolarmente tutte le chiavi DKIM che amministri.
8. Assicurati che la sintassi delle chiavi DKIM sia corretta.
9. Assicurati che per ogni chiave privata che firma ci sia la chiave pubblica corrispondente disponibile.

1. Poiché DMARC si basa sia su SPF che DKIM e sui domini relativi, assicurati che il dominio Return-Path per SPF sia uguale o sottodominio di quello “From”. Idem per il dominio di firma DKIM. L’allineamento corretto è fondamentale per la deliverability nel 2026.
2. Assicurati che la sintassi del record DMARC sia corretta.
3. Assicurati di aver configurato tutti i sistemi correttamente con SPF e DKIM prima di passare alla policy reject perchè altrimenti le email verranno perse.
4. Assicurati di utilizzare un sistema o fornitore esterno come Red Sift OnDMARC per ricevere i report DMARC e capire eventuali sistemi mal configurati. Le piattaforme DMARC moderne nel 2026, come OnDMARC, permettono di raggiungere l’enforcement in 6-8 settimane tramite troubleshooting automatico e test in tempo reale.
5. Monitora lo stato di ogni fonte di invio e assicurati che ogni cambiamento ai record SPF e DKIM venga individuato. Red Sift OnDMARC include questa funzione come parte integrante del prodotto.