Un problema persistente: l'autenticazione email nel 2025

L'email continua a essere uno degli strumenti più usati — e purtroppo più vulnerabili — in ambito business. Nonostante l'emergere di piattaforme moderne che offrono alternative più sicure e tracciabili, l'email rimane centrale nella comunicazione tra aziende. E proprio per questo, anche nel 2025, continua a rappresentare un vettore significativo per attacchi di phishing, spoofing e spam.

Il protocollo SMTP, nato in un contesto molto diverso dall'attuale, non prevede meccanismi robusti per l'autenticazione del mittente. Da qui la necessità di tecnologie come SPF, DKIM e DMARC.

Vediamole da vicino, con lo sguardo tecnico di chi le implementa.

SPF: una whitelist basata su IP

Sender Policy Framework (SPF) permette al dominio mittente di dichiarare esplicitamente quali IP sono autorizzati a spedire email per suo conto. Funziona tramite un record DNS TXT che specifica gli IP (o i domini) autorizzati.

Benefici concreti: SPF è relativamente semplice da implementare in ambienti controllati. Per esempio, se tutta la posta esce da Google Workspace o da un relay SMTP aziendale noto, SPF può aiutare a bloccare tentativi di spoofing di base.

Le difficoltà reali:

  • SPF verifica l'IP dell'MTA che spedisce la mail, non l'header "From" visibile all'utente. Quindi non previene attacchi di spoofing più sofisticati.
  • Il limite di 10 lookup DNS può diventare un ostacolo quando si utilizzano molti servizi terzi (CRM, strumenti di marketing, piattaforme di invio notifiche...).
  • Alcuni mailserver possono gestire in modo non uniforme i risultati SPF softfail.

Best practice:

  • Minimizzare le deleghe. Evitare SPF troppo permissivi o con +all.
  • Monitorare i servizi che inviano per conto del dominio. Se cambiano IP, l’SPF va aggiornato.
  • Validare la configurazione con strumenti come MXToolbox o Dmarcian.

DKIM: firma crittografica per le email

DomainKeys Identified Mail (DKIM) si basa su una firma crittografica del contenuto della mail e di alcuni header. Il dominio pubblica una chiave pubblica nel DNS, che viene usata per verificare la firma inserita nel messaggio.

Benefici concreti: DKIM aggiunge integrità e autenticazione: se il messaggio è stato alterato in transito o inviato da un servizio non autorizzato, la firma fallisce.

Le difficoltà reali:

  • Non tutti i provider configurano DKIM correttamente di default.
  • La selezione degli header da firmare può causare fallimenti inaspettati (es. se un mail gateway modifica i campi "Subject" o "From").
  • La gestione delle chiavi RSA richiede attenzione: lunghezza, rotazione e revoca devono essere parte di un processo strutturato.

Best practice:

  • Usare chiavi da almeno 2048 bit.
  • Firmare almeno i campi From, Subject, Date e i contenuti MIME.
  • Testare gli invii reali verso provider principali (Gmail, Outlook, Apple Mail) per verificare compatibilità e deliverability.

DMARC: il coordinatore tra SPF e DKIM

Domain-based Message Authentication, Reporting & Conformance (DMARC) coordina SPF e DKIM e introduce una policy su come trattare i messaggi che falliscono i controlli. Inoltre, fornisce report aggregati e forensi.

Benefici concreti:

  • Permette di specificare azioni (none, quarantine, reject) in base alla conformità di SPF/DKIM.
  • Rende visibile cosa succede realmente grazie ai report aggregate.

Le difficoltà reali:

  • I report sono in formato XML e spesso richiedono strumenti terzi per essere analizzati.
  • Richiede che SPF o DKIM siano aligned con il dominio visibile nel From. Questo è un aspetto spesso trascurato.
  • Una policy aggressiva impostata troppo presto (es. p=reject) può bloccare email legittime.

Best practice:

  • Iniziare con p=none e monitorare per almeno 1-3 mesi.
  • Analizzare i report con strumenti come Postmark, Dmarcian, o soluzioni open source come OpenDMARC.
  • Procedere per gradi verso quarantine e solo successivamente verso reject.

Esempio pratico: configurazioni DNS

Immaginiamo un dominio che utilizza Google Workspace per l’invio della posta e anche una piattaforma di newsletter esterna (es. Mailchimp).

Record SPF:

@ IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

Record DKIM (Google):

google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

Record DMARC:

_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s"

Questi record sono solo un punto di partenza: ogni servizio esterno ha le sue indicazioni specifiche e, in alcuni casi, può essere necessario configurare chiavi DKIM dedicate o subdomini separati.

Un percorso sostenibile per l’adozione

In uno scenario ideale, SPF, DKIM e DMARC sarebbero configurati su ogni dominio. Nella realtà, la loro adozione richiede pianificazione, test approfonditi e monitoraggio costante. L’approccio più efficace è procedere per fasi:

  1. SPF first: è il più semplice da introdurre e spesso già supportato dai provider principali.
  2. DKIM second: richiede più attenzione ma offre un salto di qualità sulla sicurezza.
  3. DMARC last: va introdotto con policy leggere e strumenti di osservabilità.

Coinvolgere DevOps e SecOps è fondamentale: un record DNS errato può compromettere la deliverability delle email transazionali o addirittura bloccare comunicazioni cruciali con clienti e partner.

Conclusione: equilibrio tra sicurezza e affidabilità

SPF, DKIM e DMARC sono strumenti validi e ormai indispensabili per proteggere la reputazione email di un dominio. Tuttavia, la loro implementazione richiede un approccio strutturato e multidisciplinare: non bastano configurazioni iniziali corrette, serve anche una manutenzione continua.

Chi desidera mantenere un dominio affidabile e costruire una reputazione solida deve investire in questi standard. Il risultato si traduce in una migliore deliverability, una riduzione delle frodi e una comunicazione aziendale più credibile.

In definitiva, garantire che un’email arrivi a destinazione e sia considerata legittima non è solo una questione tecnica, ma un investimento strategico per la propria organizzazione.