Come diagnosticare SPF, DKIM e DMARC per la deliverability email

I problemi di autenticazione email nel traffico aziendale

Le email inviate da un dominio aziendale finiscono frequentemente nella cartella spam dei destinatari. Il motivo della mancata consegna raramente dipende dal testo contenuto nel messaggio. Nella maggioranza dei casi, la causa è un'errata configurazione dei record DNS dedicati all'autenticazione del mittente. I provider di posta applicano filtri severi prima di accettare i messaggi in entrata.

Quando un server ricevente accetta una connessione SMTP, interroga le voci DNS del dominio del mittente. Se le voci SPF, DKIM e DMARC sono assenti, incomplete o malformate, il messaggio viene marcato come sospetto o scartato del tutto. La diagnosi precisa di questi parametri è il primo passo per garantire il recapito e proteggere il nome a dominio da tentativi di spoofing e phishing.

Audit del record SPF: prevenire gli errori di sintassi e lookup

Il record Sender Policy Framework (SPF) indica quali indirizzi IP e server sono autorizzati a inviare posta elettronica per conto di un dominio. Il controllo viene pubblicato sotto forma di record TXT nelle impostazioni DNS principali del dominio.

L'errore più banale e comune consiste nella pubblicazione di più record SPF separati. Lo standard RFC impone che un dominio contenga un solo record SPF valido, identificato dall'intestazione v=spf1. La presenza di due record TXT distinti provoca il fallimento immediato dell'analisi da parte dei server di posta.

Un secondo ostacolo riguarda la soglia dei dieci controlli DNS (lookup limit). Ogni volta che un record SPF utilizza un meccanismo come include:, a, mx o redirect, il server ricevente deve effettuare una risoluzione DNS aggiuntiva. Se il totale delle chiamate necessarie per valutare il record supera dieci, il controllo restituisce un esito di tipo PermError e l'email viene rifiutata.

È essenziale valutare attentamente l'uso delle direttive di chiusura del record. La clausola ~all (SoftFail) segnala al ricevente di accettare il messaggio ma di considerarlo sospetto in caso di mancata corrispondenza, mentre la clausola -all (HardFail) chiede il blocco diretto. L'uso corretto dipende dallo stato di aggiornamento delle sorgenti di invio registrate.

Verifica delle chiavi DKIM e corretta configurazione dei selettori

DomainKeys Identified Mail (DKIM) aggiunge una firma digitale crittografica all'intestazione di ciascun messaggio in uscita. Il server mittente firma l'email con una chiave privata, mentre il server destinatario usa la chiave pubblica recuperata via DNS per autenticare l'origine del messaggio e verificare che il testo non sia stato modificato durante il transito.

A differenza del record SPF, i dati DKIM sono associati a un selettore specifico. La chiave pubblica deve essere pubblicata come record TXT su un sotto-dominio formulato come selettore._domainkey.dominio.it.

Gli errori più diffusi nella configurazione DKIM comprendono:

• Nome del selettore errato o difforme rispetto alle impostazioni del server SMTP mittente.
• Interruzioni o spazi impropri inseriti durante l'incollatura della chiave pubblica RSA nel pannello DNS.
• Chiavi a 2048 bit troncate nei campi di testo DNS che non supportano stringhe superiori ai 255 caratteri senza opportuna formattazione a blocchi.

Se la firma crittografica dell'email non corrisponde alla chiave pubblica DNS, il controllo DKIM fallisce. Questo causa il declassamento della reputazione del dominio mittente.

Allineamento del dominio e politica DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) opera come il terzo strato di sicurezza. DMARC indica al server destinatario cosa fare se i controlli SPF e DKIM falliscono. Il record viene posizionato nella locazione TXT riservata _dmarc.dominio.it.

DMARC introduce il concetto di allineamento del dominio. Un'email supera l'allineamento solo se il dominio presente nell'intestazione visibile From: corrisponde al dominio validato dal record SPF o dalla firma DKIM. Se SPF e DKIM superano le verifiche tecniche ma usano un dominio differente da quello mostrato al destinatario, DMARC considera il messaggio non valido.

La politica DMARC si definisce mediante il parametro p=:

• p=none: Modalità di solo monitoraggio. Non applica alcuna restrizione alle email non conformi, ma raccoglie dati.
• p=quarantine: Sposta le email che falliscono la verifica nella cartella spam del destinatario.
• p=reject: Istruisce il server di posta di rifiutare integralmente il messaggio non autenticato.

I parametri rua e ruf consentono di specificare l'indirizzo email a cui inviare i report aggregati e di analisi diagnostica sui fallimenti rilevati in rete.

Diagnosi immediata con Mail Inspector di VxD.mobi

Effettuare controlli incrociati manuali da riga di comando tramite dig o nslookup richiede tempo e attenzione ai dettagli di sintassi. Lo strumento Mail Inspector, disponibile nell'area Utility Hub del sito VxD.mobi, velocizza l'intero processo di verifica dell'infrastruttura di posta.

Mail Inspector effettua una scansione automatica dei record TXT associati al dominio specificato. L'utility analizza la struttura del record SPF, rileva la presenza di errori di sintassi, conta il numero di direttive di lookup e avvisa in caso di record SPF duplicati. Lo strumento esamina inoltre la validità della chiave pubblica DKIM sui selettori indicati e recupera la politica DMARC impostata, fornendo un quadro diagnostico immediato.

Procedura operativa per la risoluzione dei problemi di recapito

1. Eseguire un'analisi iniziale del dominio inserendolo in Mail Inspector nella sezione Utility Hub su VxD.mobi.
2. Identificare ed eliminare eventuali record SPF duplicati all'interno della zona DNS.
3. Consolidare tutti gli indirizzi IP e i servizi terzi autorizzati in un unico record SPF che inizia con v=spf1.
4. Verificare che le direttive include: non generino più di dieci richieste DNS complessive.
5. Estrarre il selettore DKIM dai log o dalle configurazioni dell'infrastruttura di invio e controllarne la presenza su selettore._domainkey.
6. Creare un record TXT per _dmarc con politica iniziale p=none e configurare l'indirizzo di reportistica nel parametro rua.
7. Esaminare i report ricevuti per identificare eventuali servizi legittimi invianti non ancora autorizzati.
8. Aggiornare progressivamente la politica DMARC a p=quarantine e successivamente a p=reject per bloccare lo spoofing del dominio.