Verifica SPF e DMARC: come cercare, leggere e correggere i record

Che cosa controllano SPF, DKIM e DMARC

SPF e DKIM possono entrambi dare esito positivo per un dominio che chi legge non vede mai. DMARC colma questa lacuna con l’allineamento: un messaggio supera il controllo quando SPF o DKIM passano per un dominio allineato al dominio From, e basta un solo esito allineato. L’allineamento relaxed, quello predefinito, richiede solo lo stesso dominio organizzativo, quindi bounce.example.com è allineato a example.com. L’allineamento strict richiede una corrispondenza esatta.

Un servizio di newsletter ipotetico mostra perché conta. Invia come news@example.com ma usa un proprio dominio di bounce su example.net come mittente della busta. SPF passa per example.net, che non è allineato, quindi DMARC passa solo se il servizio firma con DKIM come d=example.com.

Come cercare i record con dig o nslookup

Ti bastano dig (Linux, macOS) o nslookup (Windows):

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
nslookup -type=TXT _dmarc.example.com

Il record SPF è il record TXT che inizia con v=spf1; accanto ci sono spesso token di verifica di altri servizi. Il record DMARC è il record TXT in _dmarc che inizia con v=DMARC1. Controlla SPF sul dominio del mittente della busta, che può differire dal dominio From; lo mostra l’header Return-Path di un messaggio recapitato.

Le chiavi DKIM non si possono elencare dall’esterno, perché ciascuna sta sotto un selettore. Leggi i valori s= e d= nell’header DKIM-Signature di un messaggio che hai inviato, poi interroga quel nome, per esempio dig +short TXT s1._domainkey.example.com.

Dopo una modifica, i resolver possono servire la vecchia risposta finché non scade il TTL. Per vedere che cosa è pubblicato adesso, individua i server autorevoli con dig +short NS example.com e interrogane uno direttamente: dig +short TXT example.com @ns1.example.net. Poi invia un messaggio reale a una casella che controlli e leggi il suo header Authentication-Results. Mostra che cosa ha deciso il destinatario per SPF, DKIM e DMARC, ed è il risultato che conta.

Come leggere un record SPF

v=spf1 ip4:192.0.2.10 include:_spf.mail.example.net -all

I meccanismi vengono valutati da sinistra a destra e il primo che corrisponde decide il risultato. Ciascuno può avere un qualificatore: + pass (predefinito), - fail, ~ softfail, ? neutral.

~all o -all

~all dice che i server non elencati probabilmente non sono autorizzati e che i destinatari non dovrebbero rifiutare solo per questo. -all dice che non sono autorizzati; che cosa succede dopo dipende dalla policy del destinatario. Entrambi sono ragionevoli e il BSI tedesco accetta l’uno e l’altro. La RFC 9989 aggiunge una cautela: con -all, un destinatario che controlla SPF presto nella sessione SMTP può rifiutare un messaggio che DKIM allineato avrebbe fatto passare, tipicamente la posta inoltrata, e quel rifiuto non compare mai nei report DMARC. ?all o l’assenza di all non dicono nulla sui server non elencati. +all fa passare qualsiasi indirizzo IP di Internet: non pubblicarlo mai.

Il limite di 10 lookup

I destinatari valutano al massimo 10 termini che interrogano il DNS, contando anche quelli dentro i record inclusi (sezione 4.6.4). Oltre, il risultato è permerror e SPF non può più aiutare un messaggio a superare DMARC. Un limite separato riguarda i lookup che non restituiscono risposta: più di due di questi dovrebbero concludersi anch’essi con permerror. Un record che mostra quattro termini può comunque superare il limite se i record inclusi contengono a loro volta altri include, quindi conta in modo ricorsivo. Per rientrare nel limite, rimuovi i servizi che non usi più, scrivi ip4/ip6 per gli indirizzi che controlli e sposta i servizi ad alto volume su un sottodominio di bounce dedicato, con il proprio record SPF. Il flattening, cioè copiare gli intervalli IP di un provider nel tuo record, diventa obsoleto quando il provider li cambia.

Un solo record per nome

Due record TXT che iniziano con v=spf1 sullo stesso nome producono un permerror: uniscili. Un record più lungo di 255 caratteri va in un unico record TXT come più stringhe tra virgolette, che i destinatari uniscono senza spazi. Nemmeno SPF viene ereditato: un record su example.com non copre mail.example.com, quindi ogni nome usato come mittente della busta ha bisogno del proprio.

Come leggere un record DMARC

DMARC è ora la RFC 9989 (maggio 2026), una specifica standards-track che sostituisce la RFC 7489. Il record sta ancora in _dmarc e inizia con v=DMARC1:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Un record su example.com copre anche i sottodomini che non ne hanno uno proprio; i destinatari lo trovano con quello che la RFC 9989 chiama DNS Tree Walk. I destinatari che inviano report aggregati li consegnano come file XML, di solito ogni giorno, con l’elenco degli indirizzi IP che hanno inviato a nome del tuo dominio e i relativi risultati. Se rua punta a un altro dominio organizzativo, come un servizio di report, quel dominio deve pubblicare un record TXT come example.com._report._dmarc.reports.example.net che inizia con v=DMARC1 (RFC 9990, sezione 4), altrimenti i destinatari ignorano l’indirizzo.

Da none a reject

1. Elenca ogni servizio che invia a nome del dominio: piattaforma di posta, newsletter, CRM, fatturazione, help desk, moduli del sito.
2. Pubblica p=none con rua e leggi i report.
3. Correggi ogni fonte legittima finché non supera i controlli con allineamento, preferibilmente tramite DKIM, che in genere sopravvive all’inoltro mentre SPF no.
4. Passa a quarantine, eventualmente prima con t=y, poi valuta reject.

La RFC 9989 dice che i domini i cui utenti scrivono a mailing list NON DOVREBBERO pubblicare reject; chi lo vuole comunque dovrebbe prima restare almeno un mese su none e altrettanto su quarantine, confrontando i risultati. Ogni dominio che pubblica reject DEVE firmare la posta con DKIM. Il BSI tedesco, con la TR-03182, adotta una linea più severa: un dominio mittente DOVREBBE richiedere reject. Un dominio usato solo per fatture e notifiche è un caso diverso da uno che il personale usa nelle mailing list. La RFC 9989 dice inoltre ai destinatari di non rifiutare sulla sola base di p=reject, ma riconosce che in pratica la posta delle liste con la riga From invariata viene spesso rifiutata.

Domini che non inviano posta

I domini parcheggiati, quelli registrati per proteggersi dai refusi e quelli usati solo per i redirect possono comunque comparire in una riga From contraffatta. La RFC 7208 definisce un record SPF per i domini che non inviano posta una buona pratica consolidata. Un set completo per un dominio parcheggiato ipotetico:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net.         MX   0 .

Il record SPF non autorizza nessuno e p=reject qui non costa nulla, perché non c’è posta legittima da perdere. Il null MX della RFC 7505 dichiara che il dominio non accetta posta, quindi i report vanno a example.com, che deve pubblicare example.net._report._dmarc.example.com. La BSI TR-03182 indica questa stessa combinazione come obbligatoria (MUST) per i domini inutilizzati. La policy DMARC copre i sottodomini, SPF no: assegna quindi un v=spf1 -all anche a ogni sottodominio con un proprio record A o MX.

Che cosa richiedono ai mittenti Gmail, Yahoo e Outlook.com

Da novembre 2025 Gmail sta intensificando l’applicazione delle regole, compresi i rifiuti. Le regole di Google riguardano gli account Gmail personali, non i destinatari Google Workspace. Google e Yahoo richiedono chiavi DKIM di almeno 1024 bit. Microsoft rifiuta la posta che non rispetta i requisiti con 550 5.7.515. Tutti e tre accettano p=none, che soddisfa la regola ma non esprime alcuna preferenza sulla posta contraffatta: consideralo una tappa, non la configurazione finale.

MTA-STS e CAA: altri due record da controllare

MTA-STS (RFC 8461) protegge la posta in arrivo: dice ai mittenti di non consegnare ai tuoi host MX se non offrono TLS con un certificato attendibile. Richiede un record TXT in _mta-sts.example.com, come v=STSv1; id=20261001000000Z;, e un file di policy in https://mta-sts.example.com/.well-known/mta-sts.txt con modalità, nomi MX e max_age. Parti in modalità testing, in cui i mittenti consegnano comunque e segnalano gli errori se il TLS reporting è configurato in _smtp._tls.example.com, poi passa a enforce. Cambia l’id ogni volta che la policy cambia.

CAA (RFC 8659) indica le autorità di certificazione autorizzate a emettere certificati TLS per il dominio, per esempio CAA 0 issue "ca.example.net". Le CA pubbliche devono controllarlo prima dell’emissione; non impedisce a una CA autorizzata di emettere certificati errati e i browser non lo usano. Un record su example.com copre i sottodomini che non ne hanno uno proprio. Elenca ogni CA che usi, compresa quella della tua CDN, o i rinnovi possono fallire. La guida a TLS e header di sicurezza tratta i certificati più in dettaglio.

Errori comuni in SPF e DMARC e come correggerli

Che cosa controlla lo snapshot gratuito nel DNS della posta

Lo snapshot gratuito di preparazione al lancio esegue otto controlli passivi su un’origine pubblica, senza registrazione. Non è un pentest e non è l’audit su sei aree. Uno degli otto controlli legge i record DNS della posta:

• Hostname esatto. MX, TXT, _dmarc, _mta-sts e CAA vengono interrogati sull’hostname che inserisci, senza ripiegare sul dominio padre. Un record mancante su www.example.com non significa che example.com sia senza protezione. Per far leggere i record del tuo dominio di posta, inserisci quel dominio stesso (example.com anziché www.example.com); deve risolvere a un indirizzo perché lo snapshot produca un punteggio.
• SPF. Un record mancante viene segnalato (medio) solo se l’host ha record MX. +all è segnalato come rischio alto e ?all come basso; ~all e -all non generano segnalazioni. Più di dieci termini che interrogano il DNS vengono segnalati (medio), ma si contano solo i termini del record di primo livello, perché include: non viene seguito.
• DMARC. Un record mancante viene segnalato (medio) solo se l’host ha record MX. p=none è segnalato come modalità di monitoraggio (basso), mentre quarantine o reject contano come superati. sp, pct, rua e l’allineamento non vengono valutati.
• MTA-STS e CAA. Un record TXT _mta-sts mancante viene segnalato (basso) solo se l’host ha record MX; il file di policy non viene scaricato. Qualsiasi record CAA conta come superato e la sua assenza è un segnale basso; il contenuto non viene confrontato con il tuo certificato.
• Non controllati: DKIM, TLS reporting e DNSSEC.

Ottieni un punteggio e un voto, un voto di hardening, il conteggio dei segnali di rischio e dei controlli superati, fino a tre segnali, dal più grave, e tutti i controlli, compresa ogni riga del DNS della posta, elencati con la rispettiva valutazione. Un nome che non risolve a un indirizzo non riceve alcun punteggio. La checklist per il lancio di un sito passa in rassegna tutti gli otto controlli e la guida alla sicurezza di DNS e posta tratta la revisione continuativa.

Per aprire subito questo controllo, usa la verifica gratuita SPF e DMARC: esegue lo stesso snapshot ed elenca per primo, già aperto, il controllo del DNS della posta, sopra gli altri sette.