Controllo SPF, DKIM e DMARC

I tre record rispondono a tre domande diverse che un server di posta si fa quando riceve un messaggio che dice di arrivare dal tuo dominio:

• SPF, definito nella RFC 7208: il server che me lo consegna è tra quelli autorizzati dal dominio? Il record elenca indirizzi IP e servizi ammessi.
• DKIM, RFC 6376: il messaggio porta una firma digitale valida? Il server di invio firma intestazioni e corpo con una chiave privata, e chi riceve verifica la firma con la chiave pubblica pubblicata nel DNS.
• DMARC, RFC 7489: se le prime due verifiche falliscono, cosa devo fare? E a chi mando il rapporto?

Il punto che rende DMARC efficace è l'allineamento: non basta che SPF o DKIM passino, il dominio verificato deve coincidere con quello che il destinatario vede nel campo «Da». Senza allineamento, un truffatore potrebbe superare l'SPF del proprio dominio e scrivere nel mittente il tuo. È lo schema tipico dello spoofing usato nel phishing e nelle frodi di Business Email Compromise, dove una finta email dell'amministratore o di un fornitore chiede un bonifico.

Pubblicare subito p=reject è il modo più rapido per far sparire fatture, notifiche del gestionale e newsletter che partono da servizi dimenticati. L'ordine che evita sorprese è questo:

1. Fare l'elenco di chi invia a nome del dominio: la casella di posta, il gestionale o l'ERP, il CRM, la piattaforma di newsletter, il centralino che manda i fax per email, il sito con il modulo contatti.
2. Mettere tutti questi servizi nell'SPF, restando sotto i 10 lookup DNS, e attivare il DKIM su ognuno: quasi tutti i servizi lo offrono dal loro pannello, con il record da pubblicare.
3. Pubblicare DMARC con p=none e rua= verso una casella dedicata: per qualche settimana nessuna email viene bloccata, ma arrivano i rapporti che mostrano chi invia a nome del dominio e con quale esito.
4. Correggere i servizi che falliscono e solo dopo passare a p=quarantine, eventualmente con pct= per applicarlo a una parte dei messaggi.
5. Arrivare a p=reject quando i rapporti sono puliti. È il livello in cui le email false vengono rifiutate prima di arrivare in casella.

I rapporti DMARC sono file XML poco leggibili: per un dominio con molti invii conviene un servizio che li raccolga e li mostri in grafici.

• Due record SPF sullo stesso dominio, spesso perché un servizio nuovo ne ha fatto aggiungere un secondo invece di integrare il primo. Ne è ammesso uno solo: con due, il controllo va in errore.
• Più di 10 lookup DNS nell'SPF, a forza di include per ogni servizio. Oltre il limite il risultato è un errore permanente e l'SPF smette di proteggere.
• +all o ?all in fondo all'SPF, che autorizzano qualunque server o lo rendono neutro.
• DMARC fermo a p=none da anni: è un buon punto di partenza, ma da solo non blocca nessuna email falsa.
• DKIM con chiavi da 1024 bit mai ruotate. Oggi la lunghezza consigliata è 2048 bit.
• Domini che non inviano posta lasciati scoperti: i domini secondari o registrati solo per il marchio vanno protetti con v=spf1 -all e un DMARC con p=reject, perché sono i più comodi da usare per una truffa.
• Sottodomini dimenticati: con sp=none la policy non vale per loro.

Da febbraio 2024 Google e Yahoo chiedono a chi invia grandi volumi verso Gmail e Yahoo Mail di avere SPF, DKIM e un record DMARC, con il mittente allineato; a tutti gli altri chiedono almeno SPF o DKIM. Le regole sono nelle linee guida per i mittenti di Google e nelle best practice di Yahoo, e anche Microsoft spiega come usa questi controlli nel filtro antispam di Outlook. Chi non è in regola vede le sue email finire nello spam o rifiutate.

Sul fronte normativo, la NIS2 chiede misure tecniche proporzionate al rischio, e l'autenticazione della posta è tra le più semplici ed economiche contro il phishing. Per completare il quadro ci sono MTA-STS (RFC 8461), che obbliga a consegnare la posta su una connessione TLS verificata, e TLS-RPT (RFC 8460), che segnala quando questa consegna fallisce.