Guida all'impostazione dell'autenticazione email: SPF e DKIM spiegati
Una guida pratica all'autenticazione delle email per SPF e DKIM, con passaggi DNS, migliori pratiche e suggerimenti per la verifica.

Se invii email da un dominio a cui tieni, l'autenticazione non è facoltativa. È la parte della tua configurazione che informa i server di posta in arrivo: “Sì, questo messaggio è davvero arrivato da noi.” Senza di essa, la tua posta può sembrare sospetta anche quando il contenuto è perfettamente legittimo. Con essa, fornisci ai fornitori di caselle di posta un segnale più chiaro, riduci le possibilità di spoofing e rendi la vita un po' più difficile per i phisher che cercano di utilizzare il tuo nome di marca per i propri schemi.
SPF e DKIM sono i due pilastri che la maggior parte dei team configura per prima cosa. Svolgono lavori diversi e sono più efficaci se usati insieme. SPF verifica se il server che invia il messaggio è autorizzato a inviare per il tuo dominio. DKIM verifica se il messaggio è stato firmato dal tuo dominio e se è stato modificato durante il percorso. DMARC si trova sopra e informa i destinatari su come trattare i messaggi che non superano questi controlli. Se desideri una visione più ampia di come l'autenticazione si inserisca nel posizionamento complessivo della posta in arrivo, è utile leggere Le migliori pratiche per la consegna delle email insieme a questa guida.
Questa è la versione breve. La versione più lunga è più pratica: devi sapere cosa pubblicare nel DNS, cosa il tuo fornitore di posta ha bisogno da te e come confermare che la configurazione funzioni effettivamente una volta attivata.
Cosa è l'autenticazione email e perché è importante
L'autenticazione email è un insieme di controlli tecnici che aiutano i sistemi riceventi a decidere se un messaggio è genuinamente associato al dominio da cui afferma di provenire. Pensala come una catena di prove. Un messaggio può dire di provenire dalla tua azienda, ma se l'IP del mittente non è autorizzato, il contenuto è stato alterato o il messaggio non supera i controlli di policy, la rivendicazione diventa meno affidabile.
Perché è così importante? Perché l'email rimane uno dei canali più facili da impersonare. Un messaggio contraffatto con il tuo dominio nel campo Da può confondere i clienti, danneggiare la fiducia e creare mal di testa nel supporto. L'autenticazione non ferma ogni tentativo di abuso, ma fornisce ai fornitori di caselle di posta e ai filtri di sicurezza prove molto migliori. Il risultato è di solito meno opportunità di spoofing e un percorso più sano verso il posizionamento nella posta in arrivo.
È importante anche per motivi ordinari e non malevoli. I grandi fornitori spesso trattano la posta non autenticata con cautela. Una newsletter legittima, un ripristino della password o una conferma d'ordine possono finire nello spam o essere rifiutati outright se la storia dell'autenticazione sembra debole. Questo è particolarmente doloroso per le email transazionali, dove la velocità e l'affidabilità contano. Se la tua applicazione invia messaggi di sistema, potresti anche voler dare un'occhiata a Configurazione DKIM SPF DMARC per transazionali per una prospettiva più focalizzata sulle transazioni.
Un modo utile per pensare all'autenticazione è questo: non riguarda solo la sicurezza, e non riguarda solo la consegna. È entrambe le cose. Quando la prova tecnica è chiara, i server di posta possono fidarsi di te più rapidamente, e gli attaccanti hanno più difficoltà a fingersi te.
Come funziona l'autenticazione email attraverso SPF, DKIM e DMARC
SPF, DKIM e DMARC sono correlati, ma non fanno la stessa cosa. Ogni standard controlla una parte diversa del viaggio del messaggio.
SPF, o Sender Policy Framework, verifica se l'IP di invio è autorizzato a inviare email per un dominio. Funziona pubblicando un elenco di fonti di invio consentite nel DNS. Quando un server ricevente riceve un messaggio, confronta l'IP del mittente con quell'elenco.
DKIM, o DomainKeys Identified Mail, firma il messaggio con una chiave privata. Il server ricevente recupera la chiave pubblica dal DNS e la utilizza per convalidare la firma. Se la firma corrisponde, il messaggio è dimostrato essere stato firmato da un dominio che controlla quella chiave, e le parti firmate dell'email non sono state alterate durante il transito.
DMARC, o Domain-based Message Authentication, Reporting, and Conformance, collega SPF e DKIM. Controlla se il dominio visibile all'utente è allineato con i domini che hanno superato SPF o DKIM. Poi informa il ricevente su cosa fare quando le cose non si allineano: monitorare, mettere in quarantena o rifiutare.
Il valore pratico di utilizzare tutti e tre è semplice. SPF aiuta con l'autorizzazione della sorgente. DKIM aiuta con l'integrità e l'identità. DMARC aiuta i riceventi a far rispettare la politica in modo coerente. Se un metodo fallisce, un altro potrebbe comunque passare, il che è utile perché l'email non è un sistema perfettamente ordinato. I messaggi passano attraverso relay, gateway e filtri, e non ogni percorso si comporta allo stesso modo.
Nella maggior parte delle configurazioni, SPF e DKIM sono i primi record da sistemare. Una volta che questi sono stabili, DMARC diventa molto più utile perché ha segnali autentici da valutare.
Configurazione SPF: Aggiungi Sorgenti di Invio Autorizzate al Tuo DNS
La configurazione SPF inizia con una domanda: chi è effettivamente autorizzato a inviare email per il tuo dominio? Sembra ovvio, ma in pratica spesso include più di un sistema. Il tuo sito web potrebbe inviare reset di password tramite un fornitore, il tuo team di marketing potrebbe utilizzare un'altra piattaforma, e il tuo software di helpdesk potrebbe inviare risposte di supporto da un terzo servizio.
Inizia elencando ogni mittente legittimo. Includi il tuo host di posta principale, il fornitore transazionale, la piattaforma CRM e qualsiasi infrastruttura che invia per conto del tuo dominio. Fai attenzione qui. Se dimentichi una sorgente, la posta di quel sistema potrebbe non superare SPF. Se aggiungi una sorgente che non utilizzi più, stai aprendo una porta che non ti serve.
Successivamente, crea un singolo record SPF per il dominio. SPF è pubblicato nel DNS come un record TXT. Il contenuto è una dichiarazione di politica che di solito inizia con v=spf1 e poi include meccanismi autorizzati come ip4, ip6, include o a, terminando con un qualificatore di politica come -all o ~all. La sintassi esatta dipende dal tuo ambiente, ma l'idea è sempre la stessa: definire chi può inviare, poi specificare cosa dovrebbe succedere per tutto il resto.
C'è una regola da ricordare: usa solo un record SPF per dominio. Più record TXT SPF possono causare problemi perché i riceventi si aspettano una singola dichiarazione di politica. Se hai bisogno di autorizzare più di un servizio, combinali in un solo record piuttosto che creare voci separate.
Un flusso di lavoro di base appare così:
- Inventaria ogni piattaforma che invia email per il dominio.
- Raccogli le istruzioni SPF da ciascun fornitore.
- Fusione in un unico record SPF TXT.
- Pubblica il record nel DNS.
- Aspetta la propagazione del DNS e testa il risultato.
Una cautela: SPF ha un limite sulle ricerche DNS durante la valutazione. Ciò significa che dovresti evitare di accumulare troppi include e helper annidati in un unico record. È allettante aggiungere semplicemente la stringa include di ogni fornitore e considerarla conclusa. Resisti a questa tentazione. I record SPF puliti invecchiano meglio e sono più facili da risolvere.
Se stai gestendo anche il comportamento di rimbalzo, la gestione di SPF e rimbalzi spesso viaggia insieme nella stessa conversazione operativa. L'autenticazione rende la posta più affidabile, mentre la gestione della soppressione e dei rimbalzi mantiene la tua lista sana. Per quel lato del lavoro, Le Migliori Pratiche per la Gestione dei Rimbalzi Email è una lettura sensata da accompagnare.
Impostazione DKIM: Firma le Email in Uscita con Chiavi Criptografiche
DKIM è la parte della configurazione che sembra un po' più tecnica, ma il concetto è semplice. Il tuo sistema di posta firma i messaggi in uscita con una chiave privata. Pubblici la chiave pubblica corrispondente in DNS. Quando un messaggio arriva, il destinatario controlla se la firma corrisponde alla chiave pubblicata e se le parti firmate del messaggio sono intatte.
Il primo passo è la generazione della chiave. Molte piattaforme email generano chiavi DKIM per te, che è spesso la strada più semplice. Se gestisci la tua infrastruttura di posta, potresti dover creare tu stesso la coppia di chiavi. L'importante è che la chiave privata rimanga sul lato di invio e solo la chiave pubblica venga pubblicata in DNS.
Una volta che hai la chiave pubblica, crei un record DNS TXT sotto un selettore. Il selettore è un'etichetta che identifica la chiave specifica in uso. Ti consente di ruotare le chiavi in seguito senza rompere tutto in una volta. Un record DKIM tipico include il selettore, il dominio e il valore della chiave pubblica.
Dopo che il record DNS è stato pubblicato, abilita la firma DKIM nel tuo fornitore di posta o MTA. Questo passaggio varia a seconda della piattaforma. Alcuni servizi richiedono di incollare il selettore e la chiave privata nel loro dashboard. Altri ti consentono di attivare la firma con un singolo interruttore dopo che il DNS è stato verificato. In ogni caso, assicurati che il sistema stia firmando il dominio From corretto o un dominio strettamente allineato, a seconda della tua configurazione.
Poi invia un messaggio di prova. Apri le intestazioni raw e cerca un'intestazione DKIM-Signature. Se è presente, il messaggio è stato firmato. Se il sistema ricevente riporta un pass DKIM, sei vicino. Se fallisce, la causa è solitamente una delle tre cose: il selettore è errato, la chiave pubblica in DNS non corrisponde alla chiave privata, o il messaggio è cambiato in un modo che rompe la firma.
DKIM è particolarmente prezioso perché sopravvive a più controlli dell'IP del mittente. Se un messaggio viene inoltrato o rilanciato, SPF potrebbe fallire anche quando il messaggio è legittimo. DKIM può comunque passare se il contenuto firmato rimane intatto. Quella flessibilità è una delle ragioni per cui è così fondamentale per l'autenticazione delle email.
Come Testare e Verificare i Tuoi Record
Il testing è dove la teoria diventa realtà. Un record può sembrare perfetto sulla carta e comunque fallire a causa di un errore di sintassi, un ritardo DNS o una impostazione del fornitore che è stata trascurata.
Inizia con un'ispezione DNS di base. Puoi interrogare direttamente i record TXT SPF e DKIM per confermare che esistano e contengano i valori che ti aspetti. Controlla il dominio, il selettore e il testo del record effettivo. Piccole imprecisioni contano. Un carattere errato in una chiave pubblica DKIM può rendere l'intera firma inutile.
Successivamente, invia un messaggio a una casella di posta che controlli e ispeziona le intestazioni complete. La maggior parte dei principali fornitori di caselle di posta include i risultati di autenticazione nei dettagli del messaggio. Cerca SPF pass o fail, DKIM pass o fail e qualsiasi risultato DMARC che faccia riferimento all'allineamento.
Puoi anche utilizzare strumenti di test esterni per visualizzare la tua configurazione dal lato del ricevente. Questi strumenti spesso riassumono se i tuoi record si risolvono correttamente e se il messaggio supera i controlli di autenticazione. Per flussi di lavoro di test più strutturati, gli strumenti di test di deliverability delle email possono essere utili quando hai bisogno di un secondo parere.
Quando esamini i risultati, non fermarti a “pass” o “fail.” Guarda il motivo. Un pass con avvisi può comunque suggerire un problema futuro, specialmente se stai per cambiare fornitore o aggiungere una nuova fonte di invio. Un fail può indicare problemi di propagazione DNS, problemi di allineamento o un mittente inaspettato.
Se utilizzi i report DMARC, sono particolarmente utili per vedere cosa sta accadendo nel tuo ecosistema di posta. Possono rivelare servizi dimenticati, indirizzi IP obsoleti o traffico non autorizzato che non potresti mai individuare da un singolo messaggio di test.
Errori comuni di configurazione e come risolverli
La maggior parte dei problemi di autenticazione non sono misteriosi. Sono di solito il risultato di uno dei pochi errori familiari.
Un problema comune è la pubblicazione di più record SPF per lo stesso dominio. È facile farlo quando diversi team gestiscono sistemi diversi. La soluzione è semplice: combina le fonti autorizzate in un unico record.
Un altro problema frequente è superare il limite di ricerca SPF. Questo accade quando il tuo record SPF si collega attraverso troppi include e meccanismi che richiedono ciascuno una valutazione DNS. Se ti trovi in questa situazione, semplifica il record, rimuovi i mittenti non utilizzati o chiedi a un fornitore una configurazione SPF più semplice.
Selettori DKIM mancanti o errati sono un altro classico. Se il selettore nel DNS non corrisponde al selettore che il tuo sistema di posta utilizza durante la firma, la verifica fallirà anche se la chiave pubblica stessa è corretta. Controlla di nuovo il nome del selettore, il dominio e il percorso esatto del record.
Le discrepanze delle chiavi sono comuni. A volte un fornitore ruota le chiavi, o qualcuno copia la chiave sbagliata nel DNS. Il risultato è una firma che sembra valida ma non verifica. Rigenera la coppia se necessario, poi ripubblica e ritesta.
I problemi di allineamento possono anche ostacolare DMARC. Un messaggio può superare SPF o DKIM in un senso tecnico, ma se il dominio autenticato non si allinea con il dominio visibile del mittente, DMARC potrebbe comunque considerarlo un fallimento. Ecco perché è importante testare il dominio esatto che gli utenti vedono, non solo il dominio di invio backend.
Infine, non trascurare la formattazione DNS. Le virgolette, i ritorni a capo e gli spazi erranti possono influenzare come vengono interpretati i record. In caso di dubbio, confronta il tuo record con l'esempio raccomandato dal fornitore carattere per carattere.
Checklist raccomandata per il rollout e la manutenzione
L'autenticazione non è un progetto una tantum. È una configurazione che mantieni mentre il tuo stack di posta evolve.
- Inventaria ogni mittente prima di apportare modifiche.
- Mantieni un record SPF per dominio.
- Usa DKIM per tutti i flussi in uscita importanti.
- Testa i nuovi record in una casella di posta controllata prima del rilascio ampio.
- Monitora i risultati di autenticazione dopo cambiamenti del fornitore o aggiornamenti dell'infrastruttura.
- Ruota le chiavi DKIM quando la tua politica di sicurezza o la configurazione del fornitore lo richiedono.
- Rivedi regolarmente i rapporti DMARC in modo da poter individuare precocemente mittenti sconosciuti.
- Aggiorna il DNS ogni volta che aggiungi, rimuovi o cambi i servizi email.
Un'attenta implementazione è importante. Se stai passando da una piattaforma all'altra, pubblica le nuove impostazioni SPF o DKIM prima di effettuare il passaggio, quindi testa sia i percorsi vecchi che quelli nuovi durante la transizione. Questo riduce la possibilità di un'improvvisa mancata autenticazione sul traffico attivo.
È anche intelligente coordinare l'autenticazione con altri lavori di deliverability. Se stai riscaldando un nuovo dominio o IP, l'autenticazione dovrebbe essere in atto prima dell'inizio del riscaldamento, non dopo. E se il tuo programma di posta include notifiche push o altri canali di messaggistica, può essere utile confrontare la tua igiene email con le pratiche in Web Push Notification Best Practices in modo che il tuo stack di comunicazione rimanga coerente.
Nel tempo, l'obiettivo è semplice: rendere il tuo dominio facile da fidare. SPF dice al mondo quali sistemi sono autorizzati a parlare per te. DKIM dimostra che il messaggio è stato firmato da te e è rimasto intatto. Insieme, costruiscono una base più solida per la deliverability, la sicurezza e la protezione del marchio. Questo è il tipo di impianto che nessuno nota quando funziona, che di solito è il miglior complimento che l'autenticazione possa ricevere.
In questa pagina
← Tutti gli articoliUn clic. Ci dice cosa scrivere dopo.
Nessuna valutazione ancora — la tua sarebbe la prima.
Commenti
I commenti vengono letti prima di apparire.