Differenza tra SPF, DKIM e DMARC spiegata per MSP

Riepilogo esecutivo: Gli MSP che gestiscono gli ambienti email dei clienti hanno bisogno che SPF, DKIM e DMARC funzionino insieme per proteggere da attacchi di spoofing e soddisfare i requisiti dei fornitori di caselle di posta. Questa guida spiega il funzionamento di ciascun protocollo, perché sono tutti e tre necessari e come gli MSP possono implementare efficacemente l’autenticazione email in tutta la base clienti.

Punti chiave:

• SPF convalida gli indirizzi IP dei server mittenti, DKIM verifica l'integrità dei messaggi tramite firme crittografiche e DMARC applica una politica quando l'autenticazione fallisce
• Google e Yahoo ora richiedono SPF e DKIM per gli invii massivi, rendendo l’autenticazione email essenziale per la recapitarietà dei clienti
• Gli MSP dovrebbero implementare prima SPF, poi DKIM, poi DMARC con p=none prima di passare all'applicazione della politica
• L’architettura multi-tenant di Red Sift OnDMARC permette agli MSP di gestire l'autenticazione su tutti i domini dei clienti da una sola dashboard, raggiungendo l'applicazione della politica in 6-8 settimane contro le 6-12 mesi richieste manualmente

Invii quella che sembra una normale email aziendale per conto di un cliente, solo per vedertela respinta o finire nello spam. O peggio, i clienti del tuo cliente ricevono email di phishing che sembrano provenire dal suo dominio, danneggiando la reputazione prima ancora che qualcuno si accorga del problema. Questi scenari accadono perché l’email, per sua natura, non prevede la verifica integrata dell’identità del mittente.

I protocolli originari delle email degli anni '80 presupponevano fiducia tra i server di posta. Chiunque poteva inviare email da qualsiasi dominio e i server destinatari non avevano un metodo affidabile per verificare queste affermazioni. Questa debolezza di fondo permette attacchi di spoofing, con cui gli aggressori falsificano l’indirizzo From per impersonare mittenti affidabili.

I protocolli di autenticazione email esistono proprio per colmare questa lacuna. SPF, DKIM e DMARC lavorano insieme per verificare che le email che dichiarano di provenire dai domini dei tuoi clienti siano legittime. Per gli MSP che gestiscono più ambienti clienti, capire come funziona ciascun protocollo e perché sono tutti e tre fondamentali può fare la differenza tra un’infrastruttura email sicura e una vulnerabile a spoofing e phishing.

SPF (Sender Policy Framework) è uno standard di autenticazione email che consente ai proprietari di dominio di specificare quali indirizzi IP sono autorizzati a inviare email per loro conto. Quando un server di posta ricevente riceve un’email che dichiara di provenire dal dominio di un cliente, verifica il record SPF per confermare che l’indirizzo IP del server mittente sia nell’elenco degli approvati.

Pensa a SPF come a una lista degli invitati in un edificio sicuro. Il server ricevente controlla se l’indirizzo IP del mittente compare nella lista pubblicata degli autorizzati. Se corrisponde, l’email supera la verifica SPF. Altrimenti fallisce.

DKIM (DomainKeys Identified Mail) segue un approccio diverso, aggiungendo una firma digitale alle intestazioni delle email. Questa firma crittografica prova che il messaggio non è stato alterato durante il transito e conferma che è stato inviato da un server con accesso alla chiave privata DKIM. Il server ricevente valida questa firma utilizzando la chiave pubblica pubblicata nel DNS.

Mentre SPF si concentra sull’identità del server mittente, DKIM verifica il messaggio stesso. La firma copre sia le intestazioni che il corpo dell’email, quindi ogni manomissione durante il transito invalida la firma.

DMARC (Domain-based Message Authentication, Reporting and Conformance) si basa sia su SPF che su DKIM aggiungendo capacità di applicazione delle politiche e reporting [1]. Mentre SPF e DKIM verificano aspetti diversi di una email, DMARC collega questi controlli al dominio visibile nella casella del destinatario e indica ai server riceventi cosa fare quando l’autenticazione fallisce.

La differenza fondamentale è che DMARC ti dà il controllo sulle email che non superano l’autenticazione. Decidi se le email fallite debbano comunque essere recapitate, messe nello spam o rifiutate del tutto. Per gli MSP, questo significa poter impostare policy coerenti su tutti i domini dei clienti.

La guida alla sicurezza email di Red Sift offre ulteriore contesto su come DMARC coordina SPF e DKIM per una protezione completa del dominio.

La validazione SPF avviene quando il server ricevente interroga il DNS per il record SPF del dominio. Questo record TXT contiene una lista di indirizzi IP autorizzati e può includere meccanismi come “include” per servizi terzi. Il server confronta l’IP mittente con questa lista e restituisce un risultato positivo, negativo o neutro [2].

• SPF: Il server ricevente interroga il DNS, confronta l’IP mittente con la lista degli autorizzati e restituisce pass/fail/neutral
• DKIM: Il server di posta firma il messaggio con la chiave privata, il server ricevente recupera la chiave pubblica dal DNS e valida la firma
• DMARC: Controlla i risultati di SPF o DKIM, verifica l’allineamento del dominio con l’header From, applica la policy secondo la configurazione

DKIM opera tramite crittografia a chiave pubblica. Il server di posta firma i messaggi in uscita con una chiave privata e i server riceventi verificano la firma usando la chiave pubblica pubblicata nel DNS. Anche una sola variazione di carattere nel corpo dell’email fa fallire la validazione DKIM.

DMARC coordina questi due metodi di autenticazione e aggiunge funzionalità essenziali. Quando pubblichi un record DMARC, specifichi una policy (none, quarantine o reject) che indica ai server riceventi come gestire le email che non superano i controlli SPF o DKIM. DMARC richiede anche l’allineamento, cioè che il dominio dell’header From corrisponda a quello autenticato da SPF o DKIM.

La guida completa a DKIM e SPF spiega nel dettaglio tecnico come questi protocolli fondamentali verificano l’autenticità dell’email.

Gli attacchi di spoofing email costano alle organizzazioni una media di 1,6 milioni di dollari per incidente, secondo i dati dell’FBI. Senza protocolli di autenticazione, i malintenzionati possono facilmente falsificare i domini cliente nell’header From per impersonare dirigenti, clienti o partner. Questi attacchi di compromissione degli account aziendali hanno successo perché i protocolli email standard non prevedono la verifica integrata del mittente.

Per gli MSP, i rischi si moltiplicano su tutta la clientela. Un singolo caso di spoofing su un cliente può compromettere la tua reputazione e sollevare dubbi da parte di tutti gli altri clienti sulla propria sicurezza. E l’impatto finanziario si estende ben oltre i danni diretti. I clienti devono sostenere costi di risposta agli incidenti, indagini forensi, spese legali, sanzioni regolatorie e notifiche ai clienti. Il danno reputazionale può persistere a lungo dopo la fine della crisi immediata.

I protocolli di autenticazione proteggono la reputazione dei domini e la recapitarietà su tutto il tuo portafoglio clienti. I principali provider di posta come Google, Microsoft e Yahoo ora richiedono SPF e DKIM per gli invii massivi e utilizzano la conformità DMARC come segnale per decidere se le email finiranno in inbox o nello spam [3].

Oltre a proteggere le email in uscita, questi protocolli difendono i clienti e i partner dei tuoi clienti dal ricevere messaggi falsificati. Il reporting DMARC ti offre visibilità su chi invia email per conto di ogni dominio cliente, includendo sia servizi legittimi sia potenziali attaccanti. Per gli MSP, questa visibilità centralizzata su tutti i domini cliente rappresenta un forte elemento distintivo.

SPF e DKIM ricoprono ruoli complementari nello stack di autenticazione. SPF convalida l’autorizzazione del server mittente in base all’IP, ma non verifica il contenuto del messaggio né il campo From visibile. DKIM conferma l’integrità del messaggio e fornisce autenticazione crittografica, ma non richiede che il dominio di firma corrisponda al dominio From.

Qui entra in gioco DMARC: DMARC richiede “allineamento” tra il dominio autenticato da SPF o DKIM e quello visualizzato nel From. Questo controllo di allineamento impedisce una comune tecnica di spoofing in cui gli attaccanti fanno passare SPF usando il proprio dominio nel mail-from, ma mostrano il dominio del cliente nel From visibile.

• Livello 1: Validazione infrastrutturale (SPF) Convalida l’IP del server mittente. Validazione rapida tramite una ricerca DNS. Non funziona con l’inoltro.
• Livello 2: Validazione del messaggio (DKIM) Convalida che il messaggio non sia stato modificato. Usa firma crittografica. Sopravvive all’inoltro senza alterazioni.
• Livello 3: Enforcement delle policy (DMARC) Richiede allineamento col From. Applica policy di pass/quarantena/rifiuto. Coordina i risultati SPF e DKIM.

Gli MSP solitamente implementano tutti e tre i protocolli a tappe sulle infrastrutture cliente: prima vengono pubblicati i record SPF e DKIM, poi si aggiunge un record DMARC con policy “none” per raccogliere dati senza alterare la consegna delle email. Identificando e autorizzando tutte le fonti legittime per ciascun cliente, si passa gradualmente a policy più restrittive.

I protocolli offrono anche valore diverso a seconda del tipo di flusso email. SPF funziona bene per invii diretti dalle infrastrutture cliente, ma ha limiti con gli inoltri. DKIM sopravvive all’inoltro perché la firma viaggia con il messaggio.

La configurazione di SPF parte dall’identificazione di ogni servizio e server che invia email usando il dominio di ogni cliente. Questo include server di posta, piattaforme marketing, sistemi CRM e qualsiasi servizio terzo. Ogni mittente legittimo va incluso nel record SPF tramite indirizzo IP o meccanismi “include”.

La fase di discovery spesso rivela fonti di invio inattese. Tipicamente gli MSP scoprono che i clienti usano più servizi email di quanto pensassero: sistemi di notifiche automatiche, help desk, strumenti HR. Documentare queste fonti in tutta la base clienti aiuta a individuare pattern ricorrenti che puoi trasformare in template.

Il record SPF è un TXT nel DNS che segue una sintassi specifica. Un esempio base potrebbe essere “v=spf1 ip4:192.0.2.1 include:_spf.google.com -all”, dove “-all” significa che gli IP non autorizzati devono fallire l’autenticazione. Il record deve essere inferiore a 255 caratteri e non superare 10 lookup DNS, altrimenti non funzionerà.

Il limite dei 10 lookup DNS è un ostacolo frequente che può rompere silenziosamente l’autenticazione email. Ogni meccanismo “include” conta come un lookup e alcuni servizi concatenano più include. Quando un record SPF supera il limite, i server destinatari lo considerano fallito in modo permanente, rischiando di bloccare tutta la posta legittima. Potresti dover “appiattire” i record SPF convertendo gli include in IP o consolidare i servizi per rientrare nel limite. Per gli MSP che gestiscono più domini cliente, monitorare il numero di lookup diventa un compito operativo critico.

L’implementazione DKIM richiede la generazione di una coppia di chiavi pubblica-privata e la configurazione del server di posta affinché firmi i messaggi in uscita con la chiave privata. La chiave pubblica viene pubblicata in un record TXT DNS su un sottodominio selector, ad esempio “selector1._domainkey.clientdomain.com”. La maggior parte delle piattaforme email offre strumenti per generare le chiavi e configurare la firma DKIM.

Fase di setup SPF

• Audita tutti i servizi di invio email per ciascun cliente
• Documenta indirizzi IP e meccanismi include
• Crea il record SPF con prefisso v=spf1
• Verifica che il numero di lookup resti sotto 10
• Testa con uno strumento di validazione SPF
• Pubblica nel DNS e verifica la propagazione

Fase di setup DKIM

• Genera la coppia di chiavi a 2048 bit
• Configura il server di posta con la chiave privata
• Pubblica la chiave pubblica nel DNS
• Abilita la firma DKIM su tutta la posta in uscita
• Invia messaggi di test e verifica le intestazioni
• Coordina con i servizi terzi

Fase di setup DMARC

• Inizia con una policy p=none (solo monitoraggio)
• Configura l’indirizzo dei report aggregate (rua=)
• Pubblica il record DMARC nel DNS
• Monitora i report per 2-4 settimane
• Identifica e correggi i fallimenti di autenticazione
• Passa a p=quarantine, poi p=reject

La lunghezza della chiave è rilevante per la sicurezza DKIM. Usa almeno chiavi da 1024 bit, anche se quelle da 2048 bit offrono maggiore protezione contro attacchi futuri. Alcuni MSP ruotano periodicamente le chiavi DKIM come best practice di sicurezza su tutti gli ambienti clienti.

Per DMARC, crea un record TXT su “_dmarc.clientdomain.com” che specifica policy e preferenze di reporting. Inizia con “v=DMARC1; p=none; rua=mailto:dmarc-reports@yourmsp.com” per raccogliere dati senza bloccare la posta. Il tag rua indica dove ricevere i report aggregate, cosicché tu possa monitorare i risultati di autenticazione di tutti i clienti da un’unica casella.

I report arrivano come file XML che mostrano i risultati dell’autenticazione per ogni email inviata da ciascun dominio cliente. Senza una soluzione automatizzata, questi report sono difficili da interpretare su larga scala. Vedrai quali fonti di invio superano o falliscono SPF e DKIM, aiutandoti a individuare problemi di configurazione prima di applicare policy più restrittive.

La guida completa all’implementazione DMARC illustra ogni fase del deployment: dall’impostazione iniziale fino all’applicazione della policy p=reject.

La questione non è quale protocollo scegliere, ma in quale ordine implementarli. Tutti e tre sono necessari per una sicurezza email completa. SPF e DKIM forniscono i meccanismi di autenticazione, mentre DMARC li lega con enforcement delle policy e visibilità centralizzata.

Inizia con SPF perché è il più semplice da implementare. Di solito puoi deployare SPF in poche ore identificando le fonti di invio e pubblicando un record DNS. SPF da solo fornisce protezione di base e migliora la recapitarietà presso i principali provider.

Aggiungi DKIM subito dopo, perché fornisce un’autenticazione più forte di SPF. Le firme crittografiche DKIM non possono essere falsificate facilmente e, a differenza di SPF, DKIM sopravvive all’inoltro delle email. La combinazione SPF+DKIM ti dà due meccanismi indipendenti che DMARC utilizza.

Implementa DMARC per ultimo, perché richiede SPF e DKIM per funzionare in modo efficace. Parti con una policy di solo monitoraggio (p=none) per identificare tutte le fonti lecite, poi passa gradualmente a quarantine e reject man mano che sei sicuro della configurazione.

Alcuni MSP si chiedono se sia possibile saltare qualche protocollo o usarne solo uno per risparmiare tempo. Questo lascia buchi significativi: SPF da solo non previene alcuni tipi di spoofing, DKIM non forza l’allineamento del From. Solo DMARC consente il vero enforcement e blocca effettivamente lo spoofing prima che arrivi ai destinatari.

Implementare l’autenticazione email manualmente su dozzine o centinaia di domini cliente vuol dire tenere traccia di numerosi record DNS, interpretare report XML complessi e coordinarsi su ogni servizio di posta terzo. La piattaforma Red Sift OnDMARC automatizza tutto ciò, aiutando gli MSP a raggiungere DMARC enforcement nella clientela in 6-8 settimane invece delle 6-12 mesi tipiche della gestione manuale.

La piattaforma parte monitorando tutto l’ecosistema email e identifica automaticamente tutte le fonti che inviano posta per conto di ogni cliente. Al posto di analizzare i report DMARC grezzi, puoi vedere una dashboard visuale con tutte le fonti già autenticata e quelle che richiedono intervento per tutto il portfolio clienti.

OnDMARC categorizza automaticamente le fonti di invio, distinguendo fra server email aziendali, servizi terzi autorizzati e fonti potenzialmente malevole. La piattaforma mostra esattamente quali servizi superano l’autenticazione e quali hanno bisogno di aggiornamento/configurazione per ogni cliente.

Individua errori di configurazione SPF, DKIM e DMARC, suggerendo azioni correttive chiare. Quando sei pronto per forzare DMARC, OnDMARC monitora l’impatto e ti avverte se qualche posta legittima sarebbe bloccata. Il sistema predice l’impatto delle modifiche di policy prima che tu le implementi, così riduci il rischio di bloccare email lecita per i clienti.

Per MSP con molti clienti e ambienti complessi, OnDMARC offre gestione e reporting centralizzato. Puoi verificare lo stato dell’autenticazione su tutto il tuo portafoglio domini clienti e applicare policy coerenti. L’architettura multi-tenant permette di gestire tutti i clienti da un’unica interfaccia, mantenendo la corretta separazione dei dati.

La piattaforma Red Sift OnDMARC scala dagli MSP più piccoli ai grandi managed security service provider con centinaia di domini cliente.

[1] "DMARC vs SPF vs DKIM - The Ultimate Comparison." courier.com. https://www.courier.com/guides/dmarc-vs-spf-vs-dkim

[2] "What are DMARC, DKIM, and SPF?" Cloudflare. https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/

[3] "SPF, DKIM, DMARC: I 3 pilastri dell’autenticazione email." higherlogic.com, 2024-01-01. https://www.higherlogic.com/blog/spf-dkim-dmarc-email-authentication/