SPF, DKIM e DMARC: come il DNS rende riconoscibili le email del tuo dominio

1. Dai a ogni servizio di invio un posto nella mappa

I record MX indicano ai server mittenti dove consegnare la posta in arrivo per un dominio. La posta in uscita segue un’altra strada: un’azienda può ricevere tramite il proprio fornitore di caselle e intanto spedire ricevute, risposte dell’assistenza e newsletter attraverso servizi specializzati, ognuno con i propri server.

Il primo passo è quindi un inventario dei mittenti, con una riga per ogni servizio. Per ciascuno annota:

• l’indirizzo From che vede il destinatario;
• il dominio del mittente della busta (envelope sender, quello che finisce nel Return-Path), cioè il dominio verificato da SPF;
• il dominio di firma DKIM, il valore d= nella firma;
• il responsabile interno e il referente presso il fornitore;
• un messaggio reale salvato come esempio, con le intestazioni complete.

Questi tre domini possono legittimamente essere diversi: alcuni servizi, per esempio, usano un proprio dominio nella busta finché non configuri un sottodominio dedicato. Tenerli nella stessa tabella rende leggibile la configurazione. Accanto al nome del sito indica anche il dominio email esatto: example.com e www.example.com sono nomi DNS distinti, ognuno con i propri record. L’inventario si rivela davvero utile il giorno in cui il marketing aggiunge un nuovo strumento o la gestione passa a un collega.

2. Che cosa fa ciascun meccanismo

Ogni meccanismo copre un pezzo diverso. SPF guarda l’indirizzo IP di chi consegna, DKIM il contenuto firmato, DMARC collega questi risultati al dominio che vede il destinatario. La cifratura del trasporto è un tema a parte: TLS tra i server e, per renderlo obbligatorio verso la tua posta, MTA-STS. Le linee guida dell’Agenzia per la Cybersicurezza Nazionale (ACN) pubblicate ad aprile 2026 raccomandano di adottare SPF, DKIM e DMARC insieme, perché il solo SPF non basta contro lo spoofing del mittente. Tenere a mente questa divisione dei compiti rende molto più facile leggere le intestazioni di un messaggio consegnato.

3. Tieni SPF allineato ai percorsi di invio reali

SPF confronta l’indirizzo IP del server che si collega con la policy pubblicata per il dominio della busta (il MAIL FROM della sessione SMTP), non con il From visibile. Una policy può includere quella di un fornitore tramite include:, e quella a sua volta può rimandare ad altri record. La specifica SPF (RFC 7208) fissa alcuni limiti che conviene conoscere:

• un nome può avere un solo record v=spf1: con due record la verifica restituisce permerror;
• durante la valutazione si possono usare al massimo 10 termini che richiedono query DNS (include, a, mx, ptr, exists, redirect), contando anche quelli annidati negli include; ip4, ip6 e all non contano, e oltre il limite il risultato è permerror;
• le ricerche che non restituiscono dati (void lookup) andrebbero limitate a due.

Quando aggiungi un servizio, inseriscilo nel record esistente seguendo la sua documentazione invece di pubblicare un secondo record. Quando ne dismetti uno, togli il suo include: un’autorizzazione rimasta nel DNS continua a valere.

Resta da decidere come chiudere il record. +all, o all senza qualificatore, autorizza qualunque indirizzo di Internet e non va mai usato. Le linee guida ACN indicano come configurazione raccomandata l’elenco dei server autorizzati seguito da -all. La nuova specifica DMARC segnala però un effetto collaterale: con -all alcuni destinatari possono rifiutare il messaggio già durante la sessione SMTP, prima di valutare DMARC, anche quando una firma DKIM allineata lo avrebbe fatto passare, e quei rifiuti non compaiono nei report DMARC. ~all (softfail) è un’indicazione più debole: la RFC 7208 chiede ai destinatari di non rifiutare un messaggio solo sulla base di questo risultato. Decidi tenendo conto degli inoltri da cui passano i tuoi messaggi e di quali servizi firmano con DKIM.

Un dominio che non invia posta, per esempio uno usato solo per il sito, può dichiararlo con un record che non autorizza nessuno, v=spf1 -all, come raccomandano anche le linee guida ACN. Se il dominio non riceve nemmeno posta, può dirlo con un MX nullo (RFC 7505).

4. Collega firme, allineamento e report DMARC

DKIM aggiunge al messaggio una firma digitale: il valore d= indica il dominio che firma, s= il selettore, e la chiave pubblica sta in un record TXT a selettore._domainkey.dominio. Attiva la firma presso ogni fornitore dell’inventario e pubblica i record che ti indica. Per le chiavi, l’ACN raccomanda oggi RSA a 2048 bit, una coppia di chiavi distinta per ogni terza parte che invia per tuo conto e una rotazione almeno ogni sei mesi. Poi invia un messaggio reale e apri presso il destinatario l’intestazione Authentication-Results: mostra come il server ricevente ha valutato SPF, DKIM e DMARC su quel messaggio.

DMARC lega questi risultati al dominio del From visibile. Il record sta in _dmarc.dominio e inizia con v=DMARC1. Un messaggio supera DMARC se almeno uno tra SPF e DKIM è superato e allineato, cioè riferito allo stesso dominio del From: nella modalità predefinita (relaxed) basta lo stesso dominio organizzativo, in quella strict serve la corrispondenza esatta. Da maggio 2026 lo standard di riferimento è la RFC 9989, che sostituisce la RFC 7489, ancora citata da molte guide, comprese le linee guida ACN di aprile. Una novità pratica: il tag pct non esiste più e ne riprende in parte la funzione il nuovo tag t=y, che chiede ai destinatari di applicare un livello in meno rispetto alla policy pubblicata, per esempio quarantine al posto di reject.

La RFC 9989 consiglia di partire da p=none con il tag rua. Con questa policy i destinatari non cambiano il modo in cui trattano la posta e continuano ad applicare i propri filtri; intanto i report aggregati mostrano i flussi legittimi non ancora autenticati o allineati, da sistemare prima di passare a p=quarantine o p=reject. Su p=reject la stessa RFC aggiunge due cautele. Chi lo pubblica deve firmare con DKIM e non affidarsi al solo SPF, che non sopravvive agli inoltri. I domini i cui utenti possono scrivere su mailing list non dovrebbero pubblicarlo; se vogliono farlo comunque, dovrebbero restare almeno un mese con p=none e altrettanto con p=quarantine, confrontando i risultati nei report. Non esiste un valore giusto per tutti: un dominio usato solo da sistemi automatici e uno usato da persone che partecipano a liste di discussione hanno esigenze diverse.

I report aggregati, che ricevi all’indirizzo indicato nel tag rua, riassumono quali server hanno inviato a nome del tuo dominio e con quali risultati. Servono a scoprire i mittenti legittimi che mancano nell’inventario prima di rendere la policy più severa. Se invii grandi volumi, contano anche le regole dei provider di posta: a chi invia circa 5.000 messaggi o più al giorno verso account Gmail personali, Google richiede SPF e DKIM, un record DMARC (va bene anche p=none), l’allineamento con il dominio del From e la disiscrizione con un clic per i messaggi promozionali.

5. Coordina certificati (CAA) e trasporto della posta (MTA-STS)

Un record CAA indica quali CA, le autorità che emettono certificati, possono rilasciarne per il dominio. Prima di emettere, una CA pubblica deve controllarlo; la ricerca parte dal nome richiesto e risale verso il dominio principale, quindi un record sul dominio vale anche per i sottodomini che non ne hanno uno proprio. Non pubblicare alcun record CAA è consentito: in quel caso nessuna CA viene esclusa.

Per scrivere il record parti dai fornitori che emettono davvero i tuoi certificati: hosting, CDN, servizi su sottodomini, ognuno con i propri rinnovi automatici. Se il record CAA non include la CA usata dalla CDN, il rinnovo successivo fallirà. Conosci anche i limiti: la specifica CAA (RFC 8659) chiarisce che il record non impedisce un’emissione errata da parte di una CA autorizzata e che i browser non devono usarlo per convalidare i certificati. È un controllo a monte dell’emissione, non una protezione per chi visita il sito.

MTA-STS (RFC 8461) riguarda la posta in arrivo: permette al tuo dominio di chiedere ai server mittenti che lo supportano di consegnare ai tuoi MX solo su TLS con un certificato attendibile, invece di ripiegare su una connessione in chiaro. Servono due parti:

• un record TXT su _mta-sts.dominio;
• un file di policy pubblicato in HTTPS su https://mta-sts.dominio/.well-known/mta-sts.txt, con la modalità (testing, enforce o none) e l’elenco dei nomi MX.

Il record da solo non basta. Se il file non è raggiungibile, i mittenti non hanno una policy da applicare; se la modalità è enforce e i certificati degli MX non corrispondono ai nomi elencati, la consegna può fallire. Comincia in testing e, se vuoi ricevere segnalazioni sui problemi di consegna cifrata, pubblica anche un record TLS-RPT su _smtp._tls.dominio (RFC 8460). Documentare insieme certificati e trasporto della posta aiuta il team a mantenere coerente l’identità del dominio tra servizi diversi.

6. Verifica il risultato con messaggi reali

Prima di modificare il DNS salva i record attuali, verifica quale provider gestisce i server DNS autoritativi della zona, che non sempre coincide con il registrar o con l’hosting, e annota il TTL. Dopo la pubblicazione interroga sia un server autoritativo sia un resolver pubblico: finché il TTL del vecchio record non è scaduto, alcuni destinatari possono ancora vedere il valore precedente. Pianifica il controllo successivo tenendone conto.

1. Invia un messaggio rappresentativo da ogni servizio dell’inventario, verso caselle di provider diversi.
2. Apri l’intestazione Authentication-Results e annota i risultati di SPF, DKIM e DMARC e i domini allineati.
3. Confronta quanto vedi con i report aggregati dei giorni successivi.
4. Aggiorna l’inventario con data, esito e responsabile.

Includi i tipi di messaggio che la tua azienda invia davvero: fatture, risposte dell’assistenza, notifiche dell’account, reimpostazione della password. Conserva per ogni percorso un esempio datato con le intestazioni complete: il prossimo collega vedrà com’è fatto un messaggio configurato correttamente e avrà un termine di confronto quando qualcosa cambia. Così la manutenzione del DNS diventa una routine ripetibile invece di un intervento d’emergenza.

Per consultare subito i record SPF, DMARC, MTA-STS e CAA di un dominio, usa la verifica SPF e DMARC gratuita.

7. Tieni in un unico posto l’identità del dominio

Riunisci inventario dei mittenti, record DNS, CA autorizzate ed esempi di messaggi in un unico documento. Per un primo controllo dall’esterno puoi usare lo snapshot gratuito di Sitelemetry: esegue otto controlli passivi su un’origine pubblica, senza registrazione, e non è un penetration test. Sul fronte DNS legge i record SPF, DMARC e MTA-STS della posta e il record CAA del nome host esatto che inserisci: per www.example.com interroga www.example.com, non il dominio principale, quindi un record che manca su www non significa che manchi anche su example.com. Segnala SPF, DMARC o MTA-STS mancanti solo se quel nome ha record MX. DKIM non viene controllato e di MTA-STS viene letto solo il record DNS, non il file di policy: per questi due restano i test con messaggi reali descritti sopra. Per le connessioni del sito prosegui con la guida a TLS e header di sicurezza; per i servizi collegati, con la guida alle integrazioni.