SPF, DKIM e DMARC: guida semplice per la posta aziendale

Cosa fanno SPF, DKIM e DMARC

Tutti e tre sono record TXT nel DNS del dominio: non si installano sui computer né nei programmi di posta. Li legge il server che riceve il messaggio, per decidere quanto fidarsi del mittente.

In breve: SPF è l'elenco dei corrieri autorizzati, DKIM il sigillo sulla busta, DMARC l'istruzione all'ufficio postale del destinatario su cosa fare quando mancano entrambi, con un resoconto periodico.

SPF: l'elenco dei server autorizzati

Esempio per una PMI con le caselle su Google Workspace, il server del sito che invia i moduli di contatto e una piattaforma esterna per la newsletter:

tuodominio.it.  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.10 include:spf.newsletter.example ~all"

• v=spf1 apre il record e deve essere il primo elemento.
• include: delega l'elenco a un altro dominio. Google Workspace chiede include:_spf.google.com, Microsoft 365 include:spf.protection.outlook.com; quasi ogni servizio di invio ha il suo.
• ip4: e ip6: autorizzano indirizzi precisi, come il server del sito.
• La chiusura vale per tutto il resto: -all significa «non autorizzato», ~all «probabilmente non autorizzato». ?all e +all non proteggono il dominio.

SPF ha due limiti: controlla il mittente tecnico, non l'indirizzo nel campo Da, e si rompe con l'inoltro automatico, perché il server che inoltra non è nel tuo elenco.

DKIM: la firma digitale del messaggio

Il server di invio firma ogni messaggio con una chiave privata. Chi riceve legge nella firma il dominio (d=) e il selettore (s=), recupera la chiave pubblica dal DNS e verifica che il messaggio non sia stato alterato:

selettore1._domainkey.tuodominio.it.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

• La chiave la genera il servizio che invia (posta, newsletter, gestionale): tu copi il record nel DNS. Ogni servizio ha il suo selettore, quindi più chiavi convivono sullo stesso dominio.
• Gmail richiede chiavi di almeno 1024 bit e consiglia 2048. Una chiave a 2048 bit supera i 255 caratteri di una singola stringa TXT: se il pannello DNS la rifiuta, dividila in più stringhe tra virgolette nello stesso record; chi verifica le riunisce.
• DKIM di solito sopravvive all'inoltro, ma si rompe se il contenuto viene modificato, come fanno le mailing list che aggiungono un piè di pagina.

DMARC e allineamento: il pezzo che di solito manca

Un truffatore può inviare da un suo server con SPF valido per il suo dominio e scrivere il tuo nel campo Da. DMARC chiude il buco: il messaggio passa solo se SPF o DKIM sono validi e allineati, cioè riferiti al dominio del campo Da. In modalità relaxed, la predefinita, basta lo stesso dominio organizzativo: news.tuodominio.it è allineato con tuodominio.it.

Qui sbagliano molte configurazioni. Una piattaforma newsletter con il Return-Path sul proprio dominio supera SPF, ma per il suo dominio: SPF passa e DMARC fallisce. Si risolve attivando sul servizio la firma DKIM con il tuo dominio, o un Return-Path su un tuo sottodominio. Il primo record DMARC è di solo monitoraggio:

_dmarc.tuodominio.it.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-report@tuodominio.it"

• p= è la politica: none (solo monitoraggio), quarantine (di solito nello spam), reject (rifiuto).
• rua= è l'indirizzo dei report aggregati: file XML periodici, di solito giornalieri, con chi ha inviato a nome del dominio, da quali IP e con quale esito. Senza rua non ricevi report. Usa una casella dedicata o un servizio di analisi.
• sp= imposta la politica dei sottodomini; adkim= e aspf= scelgono allineamento relaxed (r, predefinito) o strict (s).

Gli errori più comuni

1. Due record SPF sullo stesso dominio, di solito perché chi configura la newsletter ne aggiunge uno invece di modificare quello esistente. Per l'RFC 7208 il risultato è permerror, errore permanente: serve un solo record con tutti gli include.
2. Più di 10 lookup DNS. include, a, mx, ptr, exists e redirect valgono una ricerca ciascuno, e gli include annidati sommano le proprie; ip4, ip6 e all non contano. Oltre 10 è di nuovo permerror. Rimedi: togliere i servizi dismessi, spostare gli invii massivi su un sottodominio, usare ip4/ip6 solo per fornitori con IP stabili e documentati.
3. Il meccanismo ptr, che l'RFC 7208 chiede di non pubblicare, ed errori di sintassi come un punto dopo il dominio o include= al posto di include:.
4. Servizi esterni dimenticati: gestionale che invia le fatture di cortesia, e-commerce, CRM, helpdesk. Ognuno va nell'SPF o, meglio, firma con DKIM sul tuo dominio.
5. Moduli del sito che scrivono a nome del visitatore. Se il modulo mette nel campo Da l'indirizzo Gmail di chi compila, il messaggio fallisce DMARC, e Google chiede di non usare intestazioni From di Gmail. Usa un indirizzo del tuo dominio come mittente e quello del visitatore nel Rispondi a.
6. Passare subito a p=reject, perdendo posta legittima che nessuno aveva censito.
7. Domini parcheggiati senza record: Microsoft suggerisce v=spf1 -all; con un DMARC a p=reject diventano poco utili per email false.

Il percorso graduale: da p=none a p=reject

L'RFC 9989 indica di restare almeno un mese su p=none e poi un periodo altrettanto lungo su p=quarantine prima di p=reject, confrontando i report. È un minimo: con molti servizi esterni o invii stagionali serve più tempo.

1. Prepara: un solo record SPF sotto i 10 lookup e DKIM su ogni servizio. Google suggerisce di attendere 48 ore dopo SPF e DKIM prima di pubblicare DMARC.
2. Monitora con p=none per almeno quattro settimane e fai l'elenco delle fonti legittime. Ogni IP sconosciuto è un servizio dimenticato o qualcuno che usa il tuo dominio.
3. Correggi DKIM o allineamento per ogni fonte legittima che fallisce.
4. Passa a p=quarantine e continua a leggere i report e le segnalazioni di colleghi e clienti.
5. Arriva a p=reject: i server che applicano DMARC rifiutano i messaggi non autenticati con il tuo dominio nel campo Da.
6. Mantieni: ogni nuovo servizio di invio si configura prima di attivarlo, non dopo i primi rimbalzi.

Cosa chiedono Gmail, Yahoo e Outlook.com

I requisiti di Gmail valgono per la posta verso gli account personali (@gmail.com e @googlemail.com), non verso le caselle su Google Workspace. Il quadro secondo le pagine ufficiali, verificato a ottobre 2026:

Per le agenzie contano due dettagli. Gmail somma dominio principale e sottodomini, e chi supera la soglia anche una sola volta resta mittente massivo senza scadenza. E la soglia riguarda il volume, non la dimensione dell'azienda: basta una campagna verso più di 5.000 indirizzi Gmail. Google indica come obiettivo un tasso di spam sotto lo 0,1%.

Come verificare che tutto funzioni

# SPF: deve comparire una sola riga che inizia con v=spf1
dig +short TXT tuodominio.it

# DMARC
dig +short TXT _dmarc.tuodominio.it

# DKIM: il selettore è nel pannello del servizio o nella firma (s=)
dig +short TXT selettore1._domainkey.tuodominio.it

# Windows
nslookup -type=TXT _dmarc.tuodominio.it

• Invia un messaggio a una casella Gmail e scegli Altro > Mostra originale: nell'intestazione Authentication-Results cerca spf=pass, dkim=pass e dmarc=pass.
• Ripeti il test da ogni servizio che invia a nome del dominio: sito, newsletter, gestionale, e-commerce.
• Controlla che la firma DKIM valida sia del tuo dominio (header.i=@tuodominio.it), non solo della piattaforma.
• Verifica il dominio su Google Postmaster Tools per seguire tasso di spam, autenticazione ed errori di consegna verso Gmail.
• Leggi i report DMARC ogni settimana durante il monitoraggio, poi almeno una volta al mese.
• Tieni un documento condiviso con i servizi che inviano per il dominio e i loro selettori DKIM.

Se gestisci la posta di molti domini di clienti e preferisci che i record DNS li controlliamo noi mentre configuri i servizi, il supporto di lubemy può farlo insieme a te.