Guida Red Sift alla configurazione dei protocolli email

In questo capitolo, abbiamo risposto ad alcune delle domande più comuni poste ai nostri Customer Success Engineer riguardo SPF, DKIM e DMARC – i tre pilastri dell'autenticazione e-mail moderna. Dal 2026, questi protocolli sono richiesti dai principali provider di caselle di posta per chi invia grandi volumi di e-mail. Immergiamoci nell’argomento!

Usa questo elenco per verificare di aver coperto gli elementi essenziali. Spunta ogni voce in ordine – ogni passaggio è propedeutico al successivo.

1. Pubblica un solo record SPF TXT sul tuo dominio Return-Path
2. Conferma che ogni IP mittente legittimo sia incluso nel record
3. Verifica di non aver superato il limite di 10 interrogazioni DNS (usa il SPF Checker di Red Sift per controllare)
4. Usa ~all (soft fail), non -all, così DMARC può gestire l’enforcement
5. Assicurati che il dominio Return-Path sia allineato con il dominio visibile nel campo From:

1. Conferma che tutti i servizi di invio supportino DKIM e firmino attivamente
2. Usa una chiave 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 regolarmente le chiavi e revoca quelle compromesse

1. Pubblica un record DMARC TXT – inizia con p=none per raccogliere i report
2. Punta rua= verso un processore di report (es. Red Sift OnDMARC) per rendere utilizzabili i dati aggregati
3. Rivedi i report settimanalmente per identificare mittenti sconosciuti o configurati male
4. Quando tutte le fonti legittime superano SPF o DKIM con allineamento, passa a p=quarantine
5. Avanza a p=reject per bloccare completamente lo spoofing – mira a farlo dopo 6–8 settimane con gli strumenti giusti

Bonus: sicurezza del trasporto

1. Implementa MTA-STS prima in modalità test, poi passa a enforcement dopo aver rivisto i report TLS
2. Aggiungi TLS-RPT per avere visibilità sui problemi di consegna causati da errori TLS

SPF (Sender Policy Framework) è uno standard di autenticazione e-mail sviluppato per combattere la falsificazione degli indirizzi mittente. Verificando l’autenticità delle identità MAIL FROM o HELO/EHLO durante la trasmissione, SPF confronta l’indirizzo IP del server mittente con un elenco di mittenti autorizzati specificato in un record TXT nel DNS del proprietario del dominio. Se l’indirizzo IP corrisponde all’elenco autorizzato, l’autenticazione SPF ha successo. 

SPF si focalizza sul “dominio” presente nell’header dell’e-mail, conosciuto con vari nomi come Return-Path, MAIL-FROM, Bounce address o Envelope from. Se manca questo header, SPF ripiega e controlla il nome host “HELO/EHLO”, verificando lì la presenza di un record SPF.

L’header Return-Path è un header tecnico che non è visibile all’utente finale – lo vedrà solo chi sa come visualizzare gli header di una e-mail nel client di posta. 

DKIM (DomainKeys Identified Mail) serve a firmare diversi campi di header e il corpo dell’e-mail per autenticare il dominio mittente e prevenire la modifica dei messaggi durante il transito.

Funziona tramite crittografia asimmetrica, composta da una coppia di chiavi pubblica/privata. La chiave privata resta privata al dominio mittente e serve per firmare le mail. La chiave pubblica è pubblicata nel DNS del mittente, così chiunque riceva messaggi da quel dominio la può recuperare.

Quando un’e-mail viene creata, i suoi header e il corpo sono firmati usando la chiave privata del mittente per generare una firma digitale, che viene aggiunta come campo di header insieme all’e-mail stessa. Sul lato ricevente (se DKIM è attivo), il server recupera la chiave pubblica e verifica che la mail sia realmente stata firmata dal dominio mittente. Se la verifica ha successo, si dimostra che il dominio ha davvero inviato il messaggio e che header e corpo non sono stati modificati durante la trasmissione.

DKIM si focalizza sull’header “DKIM-Signature”.

Come per SPF, anche questo header non è visibile all’utente finale, a meno che non sappia come visualizzare gli header delle e-mail ricevute.

1. La maggior parte dei problemi di autenticazione e-mail deriva sempre dagli stessi errori. Fai bene queste tre cose e risolverai il 90% dei problemi di deliverability e sicurezza.
2. Pubblica un record DMARC con p=reject Inizia con p=none per raccogliere i report, ma non fermarti lì. Una policy solo di monitoraggio non ti protegge. Passa a p=reject dopo aver identificato e configurato tutti i mittenti legittimi. Così indichi ai server riceventi di bloccare le e-mail che falliscono l’autenticazione.
3. Assicurati che SPF e DKIM siano allineati con il dominio From: SPF e DKIM possono entrambi avere esito positivo e comunque fallire DMARC se i domini non corrispondono. Controlla che il tuo dominio Return-Path (per SPF) e il dominio di firma DKIM (d=) corrispondano o siano sottodomini dell’indirizzo From: visibile. Questo è il punto in cui la maggior parte delle organizzazioni si blocca.
4. Monitora settimanalmente i report DMARC I report DMARC ti dicono esattamente chi sta inviando e-mail per conto tuo e se stanno superando l’autenticazione. Usa una piattaforma come Red Sift OnDMARC per trasformare gli XML grezzi in dati utilizzabili. Individua le configurazioni errate prima che si trasformino in problemi di deliverability.

Perché SPF & DKIM non bastano. Anche se DKIM può verificare che una e-mail non sia stata modificata rispetto all’originale, e SPF può raccomandare al server ricevente di rifiutare in base all’IP, nessuno dei due è davvero efficace contro lo spoofing. Per questo motivo DMARC diventa obbligatorio per chi invia importi elevati di e-mail nel 2026.

La ragione principale è l’header che viene controllato da ciascun protocollo.

SPF verifica il record del dominio presente nell’header return-path, DKIM la chiave del dominio d= (presente nell’header DKIM).

Entrambi i protocolli sopra possono essere configurati su qualunque dominio.

In una e-mail, il dominio principale del mittente è quello nell’header From:, che rende il nome in evidenza in cima all’e-mail – ed è l’indirizzo che l’utente finale vedrà se controlla chi ha inviato la mail.

Dati questi elementi, il tuo dominio mail può essere impersonato: gli attaccanti potrebbero impostare From: yourdomain.com e return-path e d= sul loro dominio. Se i record SPF e DKIM su theirdomain.com sono correttamente configurati, la mail passerebbe entrambi i controlli risultando in un dominio impersonato con successo.

SPF e DKIM sono utili ma da soli non bastano per prevenire l’imitazione.

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

DMARC svolge alcune funzioni:

1. Considera i risultati di SPF e DKIM 
2. Per superare DMARC, è necessario che SPF o DKIM abbiano esito positivo e che il dominio utilizzato si allinei a quello presente nell’indirizzo From:. Se vuoi approfondire l’Identifier Alignment, clicca qui.
3. Riporta i risultati di SPF, DKIM e DMARC al dominio From: (cioè al mittente).
4. Infine, dice ai server riceventi come trattare le e-mail che non superano la validazione DMARC, specificando una policy nel DNS.

Impostando DMARC su p=reject, un’organizzazione può indicare ai server riceventi di scartare tutte le e-mail inviate per conto del proprio dominio che non superano l’allineamento. Così si bloccano tutti i tentativi di imitazione dove il server ricevente implementa DMARC in modo corretto.

DMARC si focalizza sul dominio presente nell’header From: o Header From, che è visibile all’utente finale. 

SPF verifica se una e-mail è stata inviata da un mittente autorizzato controllando una lista di IP pubblicata nel DNS. Il server ricevente prenderà il dominio del Return-Path e controllerà la presenza di un record SPF. Controlla che l’IP mittente della mail sia contenuto nel record. Se l’IP è presente, significa che è autorizzato. Quindi SPF ha SUPERATO. Se l’IP non è presente allora SPF FALLISCE.

La logica in sintesi è:

• Se l’IP del mittente è nel record SPF = SPF SUPERATO
• Se l’IP del mittente NON è nel record SPF = SPF FALLITO

Il server ricevente controllerà l’header DKIM-Signature che contiene selector (s=) e dominio di firma (d=) per recuperare la chiave pubblica. Una volta ottenuta, la chiave pubblica serve a validare il messaggio. Se la validazione va a buon fine allora DKIM SUPERA, altrimenti DKIM FALLISCE.

La logica in sintesi è:

• Se la validazione ha successo = DKIM SUPERATO
• Se la validazione fallisce = DKIM FALLITO

Il server ricevente controllerà se SPF o DKIM sono ANDATI A BUON FINE, poi controllerà che il dominio Return-Path (usato da SPF) e/o il dominio d= (usato da DKIM) siano allineati con il dominio From:, infine estrarrà la policy DMARC pubblicata dal dominio From: e vi si conformerà.

La logica in sintesi è:

• Se SPF è SUPERATO e ALLINEATO con dominio From: = DMARC SUPERATO, oppure
• Se DKIM è SUPERATO e ALLINEATO con dominio From: = DMARC SUPERATO
• Se sia SPF sia DKIM FALLISCONO = DMARC FALLITO

DMARC non solo richiede che SPF o DKIM abbiano esito positivo, ma anche che i domini usati siano ALLINEATI con il dominio indicato in 

l’indirizzo “From:”. Solo in questo caso DMARC sarà SUPERATO.

Allineamento “strict” significa che il dominio Return-Path o il dominio di firma d= devono corrispondere esattamente al dominio nel campo From:.

Allineamento “relaxed” significa che Return-Path o d= possono essere sottodomini di From: e viceversa.

Per approfondire il concetto di Identifier Alignment, clicca qui.

Se DMARC fallisce, di solito il server ricevente segue la policy che hai indicato nel tuo record DMARC.

• Se sei in modalità solo report (p=none) la mail sarà accettata dal server ricevente e analizzata da altri filtri.
• Se sei in modalità quarantine (p=quarantine) la mail verrà messa in quarantena, di solito finendo nello spam del destinatario.
• Se sei in modalità reject (p=reject) il server ricevente interromperà la connessione con il server mittente e la e-mail non raggiungerà mai l’utente finale.

A prescindere dalla policy, i metadata dell’e-mail saranno registrati, insieme allo stato dei risultati di autenticazione, e inviati al tuo processore di report DMARC. Scopri di più sui report DMARC qui.

1. Assicurati che il dominio Return-Path abbia un record SPF.
2. Assicurati che anche il dominio HELO/EHLO abbia un record SPF in caso di rimbalzi (Return-Path vuoto).
3. Assicurati che ci sia 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 con il From:
6. Assicurati che i mittenti autorizzati siano inseriti nel record SPF.
7. Assicurati che i mittenti non autorizzati non siano nel record SPF.
8. Assicurati di non superare il limite di 10 interrogazioni DNS imposto da SPF. Se hai superato il limite, valuta l’utilizzo di soluzioni dinamiche come OnDMARC Dynamic SPF di Red Sift.
9. Assicurati di non usare meccanismi SPF deprecati come “ptr”.
10. Semplifica lavorando con un fornitore DMARC come Red Sift

1. Assicurati che i sistemi di invio che usi supportino DKIM.
2. Assicurati che le mail siano firmate DKIM.
3. Assicurati che il dominio di firma sia allineato con il dominio “From”.
4. Assicurati di usare una chiave DKIM sopra i 1024 bit (meglio 2048 bit)
5. Scegli selector DKIM che permettano di riconoscere facilmente il servizio di invio
6. Revoca subito le chiavi compromesse.
7. Ruota le chiavi DKIM regolarmente.
8. Assicurati che la sintassi della chiave DKIM sia corretta.
9. Assicurati che esista una chiave pubblica per ogni chiave privata che firma le tue mail.

1. Poiché DMARC si basa sia su SPF sia su DKIM e sui domini correlati, assicurati che il dominio Return-Path per SPF sia uguale o sottodominio del dominio “From:”. Lo stesso vale per il dominio di firma DKIM. La corretta configurazione dell'allineamento è fondamentale per la deliverability nel 2026.
2. Assicurati che la sintassi del record DMARC sia corretta.
3. Assicurati di aver configurato correttamente tutti i tuoi sistemi con SPF e DKIM prima di passare a una policy reject, altrimenti perderai delle mail.
4. Assicurati di utilizzare una piattaforma o provider terzo come Red Sift OnDMARC per ricevere i report DMARC e interpretarli, così da individuare eventuali sistemi configurati in modo errato. Le piattaforme DMARC moderne nel 2026, come OnDMARC, permettono di arrivare all’enforcement in 6-8 settimane grazie a troubleshooting automatico e testing in tempo reale.
5. Monitora lo stato di ciascuna delle sorgenti di invio e assicurati che qualsiasi cambiamento a SPF e DKIM venga identificato. Red Sift OnDMARC offre questa funzione come parte integrante.