Controllo SPF, DKIM e DMARC
Tre record DNS dicono al resto del mondo quali e-mail arrivano davvero dal tuo dominio. Questo controllo li legge come fa un server che riceve la posta e traduce ogni termine che trova.
Il mittente di un’e-mail non dimostra nulla
L’e-mail è stata progettata come una busta di carta. Il mittente scrive l’indirizzo di ritorno e nessuno lo controlla. Un server in qualsiasi paese può inviare un messaggio la cui riga From mostra il tuo dominio. Tre aggiunte successive chiudono questa falla, e tutte e tre stanno nella tua zona DNS come record TXT.
- SPF, sul dominio stesso
- Un elenco dei server autorizzati a inviare per il dominio. Il ricevente confronta l’indirizzo IP che si collega con l’elenco.
- DKIM, su
selector._domainkey - Una chiave pubblica. Il servizio di invio firma ogni messaggio con la chiave privata corrispondente, così il ricevente può capire che nessuno ha alterato il messaggio e quale dominio se ne fa garante.
- DMARC, su
_dmarc - La tua istruzione per la posta che non supera nessuno dei due test sotto il tuo nome di dominio: consegnarla, mandarla nello spam o rifiutarla. Indica anche una casella per i report giornalieri.
Da febbraio 2024 Gmail e Yahoo respingono gli invii massivi dai domini privi di questi record, e Microsoft ha seguito nel 2025 per Outlook.com.
Cosa guarda il controllo
Comincia dai tuoi record MX, per riconoscere il fornitore della casella (Google Workspace, Microsoft 365, Proton Mail, Fastmail e altri otto). Da lì sa quale include SPF e quali selettori DKIM aspettarsi.
| Record | Segnalato come errore | Segnalato come avviso |
|---|---|---|
| SPF | Nessun record su un dominio che ha server di posta; due record; più di 10 query DNS; un include che non ha un proprio SPF o che rimanda a sé stesso; un termine scritto male; +all; più di due query che non restituiscono nulla | Da 8 a 10 query; ?all o nessun all; ptr; termini messi dopo all; il tuo fornitore di posta assente dall’elenco |
| DKIM | Una chiave pubblicata che non si può usare: RSA sotto i 1024 bit, valore p= danneggiato, algoritmo sconosciuto | Nessuna chiave con nessuno dei nomi provati; una chiave da 1024 bit; il flag di test t=y |
| DMARC | Nessun record; due record; nessun p= valido; un indirizzo per i report o un valore di tag malformato | p=none; pct sotto 100; sp=none sotto una policy più severa; report inviati a un altro dominio che non ha accettato di riceverli |
Le query vengono contate attraverso ogni include annidato, ed è di solito lì che il limite di 10 viene superato senza che nessuno se ne accorga. Per un sottodominio, la ricerca DMARC risale al dominio padre e applica il suo valore sp=. Il verdetto complessivo è il peggiore dei tre risultati. Tre record facoltativi (MTA-STS, TLS-RPT, BIMI) vengono solo indicati come pubblicati o no.
Un dominio il cui SPF è solo v=spf1 -all viene trattato come un dominio che non invia nulla. Lì una chiave DKIM mancante è normale, e il DMARC suggerito è p=reject.
Come trovare il tuo selettore DKIM
Le chiavi DKIM non hanno un indirizzo fisso. Ogni servizio di invio sceglie un’etichetta, chiamata selettore, e il DNS non offre alcun modo di elencarle. Il controllo prova una trentina abbondante di nomi comuni, come google, selector1, k1 e s1. Quindi «nessuna chiave trovata» spesso significa solo che la tua ha un altro nome.
- Invia un messaggio dal tuo dominio a una casella che puoi aprire.
- Visualizzane il sorgente grezzo: «Mostra originale» in Gmail, «Visualizza origine messaggio» in Outlook, «Vista > Messaggio > Tutte le intestazioni» in Apple Mail.
- Trova la riga che comincia con
DKIM-Signature:e leggi due tag.d=è il dominio che firma es=è il selettore.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mta2024; …
Qui inseriresti mta2024 nella casella del selettore. Se d= mostra il nome della tua piattaforma di newsletter e non il tuo dominio, il messaggio è firmato, ma non da te, e quella firma non conta per DMARC. Il nostro decoder di intestazioni e-mail legge queste righe al posto tuo.
Riparare nell’ordine giusto
Fai un elenco di tutto ciò che invia a nome del tuo dominio: caselle di posta, piattaforma di newsletter, negozio online, help desk, il modulo di contatto del sito. Metti ognuno in un unico record SPF. Poi attiva DKIM in ogni servizio che lo offre, perché DKIM sopravvive all’inoltro e SPF no.
Pubblica DMARC con p=none e un indirizzo rua=, e leggi i report per qualche settimana con il lettore di report DMARC. Quando ogni fonte legittima supera i controlli, passa a quarantine, poi a reject. Il generatore di record scrive entrambi i record.
Questo controllo legge il DNS e non vede mai nessuno dei tuoi messaggi. Non può confermare che un servizio firmi davvero con la chiave trovata, né che il dominio che firma corrisponda al tuo indirizzo From. Per questo servono le intestazioni di un messaggio consegnato.
Domande frequenti
Perché le mie e-mail finiscono nello spam se SPF, DKIM e DMARC passano tutti?
L’autenticazione dimostra chi ha inviato il messaggio. Non dice se le persone lo vogliono. I filtri pesano anche il tasso di segnalazioni, la reputazione dell’indirizzo IP e del dominio di invio, i link nel messaggio e come i destinatari hanno reagito alla posta precedente. Comincia con una verifica delle blacklist.
Un dominio può avere due record SPF?
No. Due record TXT che cominciano con v=spf1 producono un errore permanente e i riceventi si comportano come se non ne avessi nessuno. Uniscili in un solo v=spf1 con tutti i termini include: e ip4: e un unico all alla fine.
Cosa significa «SPF PermError: too many DNS lookups»?
Elaborare il tuo record ha richiesto più di 10 query DNS. Ogni include, a, mx, exists e redirect ne costa una, e contano anche gli include dentro un include. Togli i servizi che non usi più, oppure sostituisci a e mx con indirizzi ip4: fissi, che non costano nulla.
SPF deve finire con ~all o -all?
Con DMARC attivo vanno bene entrambi, perché è DMARC a decidere cosa succede a un messaggio che fallisce. ~all è la scelta più prudente mentre stai ancora scoprendo i mittenti. Non usare mai +all, che autorizza ogni server di internet.
p=none basta per Gmail e Yahoo?
Sì, le loro regole per gli invii massivi accettano p=none. Tutto quello che ti dà sono i report, e la posta falsificata viene comunque consegnata. La protezione comincia con quarantine.
Mi serve DMARC su un dominio che non invia mai e-mail?
È proprio lì che è più facile e più utile, perché un dominio parcheggiato è un travestimento comodo per il phishing. Pubblica v=spf1 -all sul dominio e v=DMARC1; p=reject; su _dmarc.