DMARC, DKIM e SPF: la guida che non semplifica troppo

SPF, DKIM e DMARC sono i tre record DNS che decidono se le vostre email arrivano o finiscono nello spam. La maggior parte delle guide li riduce a tre comandi copia-incolla. Quello che succede dopo, quando arrivano i messaggi rifiutati o gli spoofer iniziano a impersonare il vostro dominio, lo lasciano gestire a voi.

Questa guida è scritta per chi gestisce davvero un tenant Microsoft 365 e ha bisogno di sapere non solo cosa mettere nel DNS, ma perché. Negli ultimi dieci anni abbiamo configurato questi record su circa duecento ambienti. La struttura delle prime righe è sempre la stessa. È quello che viene dopo — i sender legittimi che dimenticate, i sub-domain non protetti, i sistemi terzi che firmano male — che fa la differenza fra una configurazione che funziona e una che sembra funzionare.

Cosa fa ognuno dei tre

Prima di toccare il DNS conviene chiarire i ruoli. I tre record fanno cose diverse e rispondono a domande diverse.

• SPF risponde alla domanda: chi è autorizzato a inviare email da questo dominio? Pubblica una lista di server o ASN consentiti.
• DKIM risponde alla domanda: il messaggio è stato modificato in transito? Aggiunge una firma crittografica all'header che il destinatario può verificare contro una chiave pubblica nel DNS.
• DMARC risponde alla domanda: cosa fare quando SPF o DKIM falliscono? Specifica la policy (none/quarantine/reject) e dove inviare i report di chi sta provando a usare il vostro dominio.

I primi due dicono al destinatario qualcosa sulla legittimità del mittente. Il terzo dice cosa farne. SPF e DKIM da soli non bastano: senza DMARC il destinatario è libero di interpretare i risultati come vuole — e tipicamente fa il minimo indispensabile.

SPF — il record che dichiara chi può inviare

SPF è un record TXT pubblicato sul dominio. La sintassi è semplice: una serie di meccanismi (include, ip4, ip6, a, mx) seguita da un qualificatore finale che dice al destinatario cosa fare se nessuno matcha.

Per un tenant Microsoft 365 base, il record SPF minimo è:

v=spf1 include:spf.protection.outlook.com -all

Il -all finale (hard fail) significa: tutto ciò che non rientra nelle regole sopra deve essere rifiutato. Il ~all (soft fail) è una versione più permissiva — tipicamente i destinatari lo marcano come spam ma non lo rifiutano. La regola: usate -all quando siete sicuri di aver elencato tutti i sender legittimi, ~all durante la transizione.

Dove si rompono le configurazioni SPF

Quasi sempre nello stesso punto: i sender dimenticati. Sistemi che inviano email per conto vostro e che nessuno ha pensato di includere.

• Il CRM che invia comunicazioni ai clienti
• Il sistema di newsletter (Mailchimp, Brevo, SendGrid)
• L'ERP che spedisce conferme d'ordine
• Lo strumento di marketing automation
• Il sistema HR che manda le buste paga
• L'help-desk che invia notifiche

Ogni sender che invia da @vostro-dominio.it e non è nell'SPF inizierà a finire nello spam. Quasi tutti i sistemi SaaS forniscono un proprio include: da aggiungere. La prima azione, prima di pubblicare un SPF restrittivo, è fare l'inventario completo dei sender.

DKIM — la firma crittografica

DKIM funziona in modo diverso da SPF. Non dichiara chi può inviare; firma il contenuto. Quando un server di posta invia un'email, calcola un hash di alcuni header (e opzionalmente del body) e lo firma con una chiave privata. Il destinatario recupera la chiave pubblica dal DNS del dominio mittente e verifica la firma.

Su Microsoft 365 DKIM si attiva da Microsoft Defender Portal → Email & collaboration → Policies & rules → DKIM. Per ogni dominio accettato si pubblicano due record CNAME nel DNS:

selector1._domainkey   CNAME   selector1-vostro-dominio-it._domainkey.tenant.onmicrosoft.com
selector2._domainkey   CNAME   selector2-vostro-dominio-it._domainkey.tenant.onmicrosoft.com

I due selector permettono la rotazione delle chiavi senza downtime. Una volta pubblicati i CNAME e propagati (qualche minuto, raramente oltre l'ora), si torna nel portale e si abilita la firma per quel dominio.

Microsoft di default firma con chiavi a 2048 bit dal 2023. Se vedete ancora chiavi a 1024 bit su un tenant vecchio, vanno rigenerate — alcuni destinatari iniziano a rifiutarle.

I sender terzi e il loro DKIM

Quando un sistema terzo (Mailchimp, HubSpot, ecc.) firma email che dichiarano From: nome@vostro-dominio.it, deve usare un proprio selector DKIM sul vostro dominio. Tipicamente vi forniscono uno o più CNAME da pubblicare. Senza quei CNAME, la firma DKIM di quel sender non si allinea con il vostro dominio e DMARC non passa, anche se l'email è perfettamente legittima.

DMARC — la regola che lega tutto

DMARC è il record che trasforma SPF e DKIM da segnali a strumenti operativi. È un singolo record TXT pubblicato su _dmarc.vostro-dominio.it. La struttura minima è:

v=DMARC1; p=none; rua=mailto:dmarc-reports@vostro-dominio.it; fo=1

Decomponiamo i tag:

• v=DMARC1 — versione, obbligatoria
• p=none — policy: cosa fare quando un'email fallisce DMARC. none non blocca nulla, quarantine manda in spam, reject rifiuta
• rua= — indirizzo dove vengono inviati i report aggregati giornalieri (uno al giorno per ogni destinatario che li manda)
• fo=1 — forensic options: genera un report ogni volta che SPF o DKIM falliscono (di default è fo=0, troppo restrittivo)

La fase di monitoring esiste per un motivo

L'errore più comune che vediamo è passare direttamente a p=reject "tanto è la configurazione corretta". È vero che reject è la policy finale corretta. Non è vero che ci si arrivi senza fasi intermedie.

Per due o tre settimane lasciate p=none e leggete i report aggregati. Vi diranno:

1. Da quali IP arrivano email che dichiarano il vostro dominio
2. Quante di queste passano SPF e DKIM allineati al vostro dominio
3. Quante falliscono — e quali sono legittime ma mal configurate

I tool che vi consigliamo per leggere i report sono Postmark DMARC, Valimail Monitor o dmarcian (esistono piani gratuiti). I report grezzi sono XML — leggibili ma non comodi.

Gli errori che troviamo negli audit

Quando arriviamo su un ambiente che ha già "configurato" SPF, DKIM e DMARC, questi sono i pattern ricorrenti, in ordine di frequenza.

1. SPF con ~all in produzione da anni

Configurato durante una migrazione, "temporaneamente" messo a soft fail, mai aggiornato. Risultato: spoofer occasionali, ma niente di grave perché DMARC compensa. Va portato a -all quando l'inventario sender è completo.

2. DMARC fermo a p=none

Pubblicato anni fa per "vedere cosa succede", nessuno ha mai letto i report, nessuno ha mai promosso la policy. Tecnicamente conformi, operativamente esposti. Lo spoofing del dominio non viene bloccato — solo riportato a qualcuno che non legge.

3. Sub-domain non protetti

SPF e DMARC pubblicati sul dominio root azienda.it, niente sui sotto-domini news.azienda.it, booking.azienda.it, ecc. Lo spoofer prova From: support@news.azienda.it e passa. Soluzione: aggiungere sp=reject al record DMARC root (policy per i sub-domain non esplicitamente configurati).

4. Report DMARC inviati a una casella morta

L'indirizzo rua= punta a una casella che nessuno controlla — o peggio, a una casella che non esiste e bouncia. I report rimbalzano, voi perdete visibilità su qualunque cosa stia succedendo al vostro mailflow.

5. Selettori DKIM scaduti o dirottati

Vecchi selector di sistemi non più in uso che ancora puntano a chiavi pubbliche. Non rompono nulla, ma sporcano il DNS e nei casi peggiori restano firmati da chiavi compromesse. Vanno rimossi.

Come passare a p=reject senza bloccare nessuno

Il percorso che seguiamo ha quattro tappe ben definite. Non è veloce: tre o quattro settimane in totale per un dominio medio. Ma è l'unico modo che abbiamo trovato per arrivare all'enforcement senza incidenti.

Fase 1 — Inventario (giorni 1–3)

Mappare tutti i sender legittimi. CRM, ERP, marketing automation, sistemi interni, ticketing, qualunque cosa invii con @vostro-dominio.it. Aggiungere ognuno all'SPF e configurare DKIM dove possibile.

Fase 2 — Monitoring (giorni 4–18)

Pubblicare DMARC con p=none, attivare i report aggregati. Per due settimane non si tocca nulla — si guarda. Si scoprono i sender dimenticati, i sub-domain spoofati, gli errori di configurazione DKIM dei sistemi terzi.

Fase 3 — Quarantine (giorni 19–25)

Quando i report mostrano una percentuale di pass DMARC superiore al 98% per i sender legittimi, si passa a p=quarantine; pct=25. La pct applica la policy solo a una percentuale di traffico — un canary deploy. Si monitora una settimana, si alza la percentuale a 50, 75, 100.

Fase 4 — Reject (giorno 26 in poi)

Si passa a p=reject. A questo punto le email di chi tenta lo spoofing del vostro dominio vengono rifiutate dal destinatario prima ancora di arrivare nella casella spam. Aggiungere anche sp=reject per i sub-domain non protetti esplicitamente.

Una configurazione corretta non si pubblica una volta sola. SPF, DKIM e DMARC vanno mantenuti — quando si aggiunge un sender, quando si cambia provider, quando si lancia un nuovo sub-domain. Il lavoro che si fa una volta protegge il dominio; il lavoro che si fa ogni volta che cambia qualcosa protegge la deliverability nel tempo.