Le mail finiscono in spam: SPF, DKIM e DMARC spiegati una volta per tutte

La verifica più veloce

Prima di toccare il DNS, apri la mail che è finita in spam (o quella che non è arrivata) e guarda le intestazioni complete: in Gmail è "Mostra originale", in Outlook le "intestazioni del messaggio". Cerca la riga che inizia con Authentication-Results: riporta tre esiti, spf=, dkim= e dmarc=, ciascuno con pass, fail, softfail o none. È il modo più rapido per sapere quale dei tre protocolli sta fallendo senza indovinare. Se il messaggio arriva da fuori, chi riceve può sempre controllare le intestazioni da un altro client di posta per verificare l'autenticazione.

Chi controlla cosa, e in che ordine

Il server che riceve la posta valuta prima SPF (l'indirizzo IP del mittente è autorizzato?) e poi DKIM (la firma crittografica nell'header combacia con la chiave pubblica pubblicata nel DNS?). DMARC entra per ultimo: non verifica nulla da solo, ma controlla che almeno uno dei due risultati sia "allineato" con il dominio che compare nel campo From, e decide cosa fare in base alla policy pubblicata.

Il record SPF: sintassi e limiti

Un record SPF è un TXT nel DNS della zona principale. Esempio reale di un dominio che usa Google Workspace più un IP proprio, letto con dig +short txt nomedominio: "v=spf1 ip4:128.173.235.0/27 ip6:2001:468:c80:a102:1:1000:1024:0/120 ip6:2607:b400:000a:0280::/64 mx a include:_spf.google.com ~all". Se invece la posta passa da Microsoft 365/Exchange, il record tipico è "v=spf1 include:spf.protection.outlook.com ~all".

I pezzi che contano:

• mechanism: mechanism = ( all / include / a / mx / ptr / ip4 / ip6 / exists )
• qualifier davanti al mechanism: qualifier = "+" / "-" / "?" / "" (nessun segno equivale a "+", cioè pass; "-" è fail; "" è softfail, usato in fase di test)

Limite da ricordare: RFC 7208 richiede che i validatori SPF limitino a dieci i termini che generano una query DNS durante il controllo; i meccanismi coinvolti sono include, a, mx, ptr ed exists, più il modificatore redirect. Superarlo non dà un warning: dà un permerror, e secondo RFC 7208 se ci sono errori di sintassi nel record, check_host() restituisce subito il risultato "permerror", senza ulteriore interpretazione.

Gli errori più comuni, in ordine di frequenza

1. Troppi include: ogni servizio aggiunto nel tempo (CRM, fatturazione, newsletter, vecchio provider mai tolto) aggiunge un lookup. Oltre dieci, SPF si rompe per tutti i messaggi, non solo per quelli del servizio in eccesso. Causa tipica di permerror, insieme a meccanismi duplicati o lookup a vuoto.
2. Due record SPF sullo stesso dominio: un dig txt che restituisce due righe che iniziano entrambe con v=spf1 è sempre un errore. Il dominio deve averne uno solo: se servono più sorgenti, si aggiungono come include dentro lo stesso record, non come record separati.
3. Dimenticare -all o lasciare +all: senza un qualifier restrittivo in coda, SPF autorizza chiunque, rendendo il controllo inutile.

Il record DKIM

DKIM firma il corpo e alcune intestazioni del messaggio con una chiave privata; il destinatario recupera la chiave pubblica da un TXT pubblicato su selettore._domainkey.tuodominio, dove il selettore è il nome scelto dal software di invio (es. google, mail, default). Lo standard di riferimento è RFC 6376. Il valore tipico del TXT è v=DKIM1; k=rsa; p= seguito dalla chiave pubblica in base64. Due cause pratiche di fallimento: il selettore nel DNS non corrisponde a quello scritto nell'header DKIM-Signature del messaggio, oppure la chiave è stata rigenerata sul server di invio ma non aggiornata nel DNS.

Il record DMARC: sintassi dei tag

Il record DMARC va su _dmarc.tuodominio, come TXT. La sintassi base, secondo la documentazione Microsoft: Hostname: _dmarc, valore TXT: v=DMARC1; policy DMARC; percentuale di mail soggette alla policy; indirizzo per i report aggregati; indirizzo per i report forensi.

Tag	Significato	Valori
p=	policy per il dominio principale	none, quarantine, reject
sp=	policy separata per i sottodomini	none, quarantine, reject
pct=	percentuale di messaggi a cui si applica la policy	0-100, default 100
rua=	indirizzo per i report aggregati XML	mailto:
ruf=	indirizzo per i report forensi (messaggio per messaggio)	mailto:
adkim= / aspf=	rigidità dell'allineamento DKIM/SPF	s (strict) o r (relaxed)

Il significato delle tre policy, da RFC 7489: con quarantine il titolare del dominio chiede che la posta che fallisce DMARC sia trattata come sospetta dai mail receiver: in pratica finisce in spam o viene esaminata con più attenzione; con reject chiede che i mail receiver rifiutino la posta che fallisce il controllo DMARC, preferibilmente durante la transazione SMTP stessa. Il tag pct indica la percentuale dei messaggi del flusso del titolare del dominio a cui va applicata la policy DMARC, utile per alzare l'enforcement gradualmente.

L'errore più diffuso: DMARC fermo in p=none per sempre

Molti pubblicano il record, ricevono i report, e si fermano lì. p=none serve solo a raccogliere dati: non blocca né mette in quarantena nulla. Il percorso corretto parte da un record minimo come v=DMARC1; p=none; rua=mailto:indirizzo@tuodominio, pensato per dare visibilità operativa senza impatti, e si sposta verso l'enforcement solo quando ogni sorgente legittima è nota e SPF o DKIM passano in allineamento con il dominio visibile nel From. Chi resta in none per mesi ha solo installato un sistema di controllo, non una protezione.

Come si legge un report DMARC aggregato

I report che arrivano all'indirizzo rua sono file XML, in genere zippati, inviati circa una volta al giorno da ogni destinatario che supporta il reporting. Dentro trovi, per ogni IP sorgente: quanti messaggi ha inviato, se SPF e DKIM sono passati per quell'IP, e se risultano allineati al dominio del From. Un IP che manda volumi alti e risulta sempre in fail su entrambi è quasi sempre un servizio terzo (newsletter, CRM, fatturazione) mai aggiunto all'SPF o mai configurato per firmare in DKIM: va aggiunto, non ignorato.

Se il problema è del fornitore

Se usi un servizio di invio gestito (hosting condiviso, Google Workspace, Microsoft 365, piattaforme di email marketing) e la firma DKIM non compare proprio nell'header del messaggio inviato, il problema è quasi sempre lato fornitore: la firma va attivata e il selettore pubblicato da loro. In questo caso scrivi all'assistenza indicando il dominio esatto, il selettore DKIM che il loro sistema dovrebbe usare e, se li hai, due o tre Message-ID di mail inviate senza firma: senza questi riferimenti il ticket si risolve più lentamente.