SPF, DKIM e DMARC: cosa sono e come configurarli passo passo

SPF, DKIM e DMARC sono tre record DNS che insieme dicono ai provider di posta se un'email è davvero legittima o va trattata con sospetto. Non sono un dettaglio da IT interno da ignorare finché tutto funziona: sono il prerequisito tecnico che decide se un'email di prospezione indirizzata a un decisore preciso arriva in inbox o sparisce silenziosamente in spam. Questa guida spiega cosa fa ciascuno dei tre e come configurarli concretamente su Google Workspace e su Microsoft 365, le due piattaforme più usate dalle aziende che fanno outreach B2B mirato.

Cosa sono SPF, DKIM e DMARC, in breve

SPF, Sender Policy Framework, è un record TXT che elenca quali server hanno il permesso di inviare email a nome del tuo dominio. Quando un'email arriva, il provider di destinazione controlla se il server che l'ha spedita compare in quella lista.

DKIM, DomainKeys Identified Mail, aggiunge una firma crittografica al messaggio, generata con una chiave privata sul server di invio e verificabile con una chiave pubblica pubblicata nel DNS. Se il contenuto del messaggio viene alterato lungo il percorso, la firma non corrisponde più e il controllo fallisce.

DMARC, Domain-based Message Authentication Reporting and Conformance, si appoggia a SPF e DKIM e indica al provider di destinazione cosa fare quando uno dei due (o entrambi) falliscono: ignorare, mettere in quarantena o rifiutare il messaggio. In più, DMARC genera report periodici su chi sta effettivamente inviando email a nome del dominio.

Perché contano per chi fa outreach B2B

Chi contatta un numero ristretto di decisori selezionati, uno per uno, con email personalizzate, tende a pensare che i controlli anti-abuso pensati per il volume non lo riguardino. In realtà Gmail e Outlook applicano la stessa verifica di autenticazione a ogni messaggio in arrivo, indipendentemente dal fatto che provenga da una campagna di migliaia di invii o da dieci email al giorno scritte a mano.

Un venditore di Rossi Impianti Srl che scrive personalmente al direttore acquisti di un potenziale cliente perde tutto il valore di quella personalizzazione se il messaggio finisce in spam per un problema di configurazione DNS mai risolto. La qualità del contenuto non compensa un'infrastruttura tecnica che non supera i controlli di base.

Configurare SPF, DKIM e DMARC su Google Workspace

Su Google Workspace, SPF si configura pubblicando un record TXT sul DNS del dominio che includa il server di Google: v=spf1 include:_spf.google.com ~all. Se il dominio usa anche altri servizi per inviare email, per esempio uno strumento di outreach o un servizio di fatturazione elettronica, ognuno va aggiunto con un proprio include nello stesso record, che deve restare unico.

Per DKIM, Google genera automaticamente la chiave dalla console di amministrazione, nella sezione dedicata all'autenticazione email: il pannello fornisce un valore da copiare in un record TXT su un sottodominio del tipo selettore._domainkey.tuodominio.it, con il selettore specifico assegnato da Google. Solo dopo aver pubblicato quel record si attiva la firma dal pannello Google, altrimenti Google inizia a firmare messaggi con una chiave che il DNS non conferma ancora.

Per DMARC, si pubblica un record TXT su _dmarc.tuodominio.it, indipendentemente dal fatto che il dominio sia su Google Workspace o altrove: Google non genera questo record automaticamente, va scritto e pubblicato manualmente, partendo da policy none e con un indirizzo rua= che riceva davvero i report.

Configurare SPF, DKIM e DMARC su Microsoft 365

Su Microsoft 365 il record SPF include il server Microsoft con la sintassi v=spf1 include:spf.protection.outlook.com ~all, sempre come unico record TXT che raccoglie anche gli altri servizi di invio eventualmente usati dal dominio, esattamente come su Google Workspace.

DKIM su Microsoft 365 richiede un passaggio in più: va abilitato esplicitamente dal centro sicurezza di Microsoft Defender o dal PowerShell di Exchange Online, perché di default non è attivo. Microsoft fornisce due record CNAME da pubblicare nel DNS prima di poter attivare la firma dal pannello; se questi CNAME non vengono pubblicati, il tentativo di abilitazione fallisce con un errore chiaro.

DMARC su Microsoft 365 segue la stessa logica generale: record TXT su _dmarc.tuodominio.it, indipendente dalla piattaforma di posta usata. Microsoft consiglia comunque di completare prima la configurazione DKIM e di verificarla, perché un DMARC con policy restrittiva pubblicato prima che DKIM sia realmente attivo rischia di far fallire messaggi legittimi inviati dallo stesso tenant.

Errori da evitare durante il setup

L'errore più comune è dimenticare uno strumento aggiuntivo nel record SPF: se il team commerciale usa una piattaforma di outreach o un CRM per inviare i follow-up, e quel servizio non compare nell'include del record SPF, tutte le email inviate da lì falliscono l'allineamento SPF, anche se il resto della configurazione è corretto.

Un secondo errore è attivare DMARC in policy quarantine o reject il primo giorno, prima ancora di aver verificato con qualche settimana di report in policy none che tutti i canali di invio legittimi siano allineati. Il rischio concreto è bloccare email vere insieme a quelle false.

Un terzo errore, più sottile, riguarda ARC e BIMI: ARC (Authenticated Received Chain) preserva i risultati di autenticazione quando un'email passa per un inoltro o una mailing list, mentre BIMI mostra il logo aziendale accanto al mittente nella inbox, ma solo se DMARC è già a un livello di policy sufficientemente restrittivo. Configurare BIMI prima di aver stabilizzato DMARC è un ordine invertito che semplicemente non produce risultati.

• Includere ogni strumento di invio nel record SPF, senza duplicare il record
• Attivare e verificare DKIM prima di innalzare la policy DMARC
• Partire sempre da DMARC policy=none per raccogliere report prima di restringere
• Considerare ARC solo se il dominio riceve email inoltrate o passate da mailing list
• Valutare BIMI solo dopo che DMARC è stabile in quarantine o reject

Come verificare che tutto funzioni davvero

Dopo aver pubblicato i tre record, la verifica più semplice è inviare un'email di prova a un indirizzo che permetta di ispezionare gli header completi del messaggio: sia Gmail sia Outlook mostrano, tra le intestazioni tecniche, l'esito di SPF, DKIM e DMARC per ogni messaggio ricevuto, indicato con pass o fail.

In parallelo vale la pena controllare i report DMARC che iniziano ad arrivare all'indirizzo indicato in rua=: nei primi giorni mostrano chiaramente quali server stanno inviando a nome del dominio e se tutti risultano allineati. Se compare un server sconosciuto, va indagato prima di procedere con l'innalzamento della policy.

Solo quando i report risultano puliti per un periodo ragionevole, tipicamente alcune settimane, ha senso passare da policy none a quarantine e successivamente a reject, completando così la configurazione difensiva del dominio.

Domande frequenti