Configurazione DKIM SPF DMARC per un dominio

Impostazione di DKIM SPF DMARC per un dominio: una guida completa all'autenticazione delle email

L'email è ancora una delle parti più vulnerabili di qualsiasi dominio, e un sito web può essere costruito in modo ordinato e il server ben protetto. Se i messaggi inviati a nome dell'azienda sono facili da falsificare, i problemi iniziano rapidamente: campagne di phishing, lamentele degli utenti, perdita di fiducia e, nel peggiore dei casi, una peggiore deliverability per le proprie email. Ecco perché Impostazione di DKIM SPF DMARC per dominio non è un “piccolo dettaglio tecnico” — è una questione di igiene fondamentale dell'infrastruttura email ed è una parte importante dell'autenticazione email.

Se hai mai visto email finire nello spam senza un motivo apparente, o un cliente che chiede: “Hai davvero inviato questo?” — è già tempo di lavorare sull'autenticazione del dominio. E prima lo fai, meglio è. In questo senso, l'email funziona molto come un sito web: senza attenzione regolare, anche un sistema solido inizia a comportarsi in modo imprevedibile. Parliamo spesso di questo nel contesto di sicurezza del sito web: la protezione non è un plugin o un'impostazione, ma un insieme di misure che lavorano insieme. Se ti stai chiedendo come configurare SPF DKIM DMARC, la chiave è trattarli come un processo coordinato piuttosto che come soluzioni separate.

Cosa sono DKIM, SPF e DMARC e perché sono importanti

DKIM, SPF e DMARC risolvono un problema simile, ma lo fanno in modi diversi. È importante non confondere i loro ruoli se stai pianificando l'impostazione dell'autenticazione email per il dominio.

SPF risponde alla domanda: “Quali server sono effettivamente autorizzati a inviare email per conto di questo dominio?” In DNS, pubblichi un elenco di mittenti approvati, e il server di posta del destinatario lo confronta con l'indirizzo IP reale da cui è arrivato il messaggio.

DKIM aggiunge una firma crittografica al messaggio. Il destinatario verifica se l'email è stata realmente firmata dal tuo dominio e se è stata modificata lungo il percorso. Questo è più di una semplice lista di autorizzazione — è una prova dell'identità del mittente e dell'integrità del messaggio.

DMARC collega SPF e DKIM in un'unica politica, e dice ai sistemi di posta cosa fare se un messaggio non supera i controlli: consegnarlo, inviarlo in quarantena o rifiutarlo outright. DMARC ti consente anche di ricevere rapporti su chi sta cercando di inviare email dal tuo dominio e come.

Ecco perché questi meccanismi non riguardano solo la prevenzione delle email contraffatte. Influenzano direttamente la deliverability. I servizi di posta guardano sempre di più non solo al contenuto di un messaggio, ma anche a quanto bene è impostata la sua autenticazione. Per un dominio aziendale, questo è fondamentale: perdere alcuni messaggi è una cosa, ma finire ripetutamente nello spam per clienti, partner e servizi è un'altra cosa completamente.

Come funzionano insieme DKIM SPF DMARC

Ogni protocollo è utile da solo, ma insieme creano un sistema di verifica molto più affidabile.

SPF conferma che il messaggio proviene da un server approvato. Ma ha una limitazione: se l'email viene inoltrata, SPF può "rompersi" perché l'indirizzo IP dell'ultimo mittente cambia. DKIM spesso aiuta in quei casi perché la firma rimane valida anche dopo l'inoltro, purché il messaggio stesso non sia stato modificato.

DMARC, a sua volta, controlla non solo se SPF e DKIM esistono, ma anche se sono allineati con il dominio nel campo From. Questo è importante. Un messaggio può essere tecnicamente firmato, ma l'utente vede un dominio completamente diverso nel nome del mittente, e DMARC aiuta a prevenire quella confusione e blocca le ovvie contraffazioni.

Per dirla semplicemente: SPF è una lista degli invitati all'ingresso, DKIM è un sigillo sul documento, e DMARC è la regola di sicurezza su cosa fare con i visitatori che non hanno né un pass né un sigillo. Una misura senza le altre lascia un vuoto.

Ecco perché dovrebbero essere implementati insieme. Questo è particolarmente importante per le aziende che utilizzano più fonti email: sistemi CRM, servizi di newsletter, piattaforme di ticketing, moduli di contatto, notifiche transazionali. Se questi non sono allineati, l'infrastruttura email inizia a comportarsi come una raccolta di isole disconnesse.

Prepararsi per la configurazione: dominio, DNS e servizio email

Prima di creare qualsiasi record, è necessario capire chi esattamente invia email per conto del dominio. Potrebbe essere un servizio email, o più di uno: email aziendale, una piattaforma di mailing, un sistema di notifiche, un servizio SMTP separato per il sito web. Senza questa visione, rischi di consentire troppo o, al contrario, di bloccare accidentalmente un mittente necessario.

Avrai bisogno di accesso al pannello DNS del dominio. Di solito si tratta dell'interfaccia del registrar, del tuo fornitore di hosting o di un fornitore DNS separato. È importante sapere esattamente dove vengono modificati i record: a volte una persona cerca il problema nel servizio email, mentre il record vive effettivamente con un altro fornitore.

Un altro passo essenziale è raccogliere dettagli dal fornitore di email. Di solito avrai bisogno di:

• dati SPF o un record SPF raccomandato;
• una chiave DKIM o istruzioni per generarne una;
• il nome del selettore DKIM, se il fornitore ne utilizza uno;
• raccomandazioni DMARC;
• un elenco di domini e sottodomini utilizzati per l'invio;
• una comprensione di quali servizi inviano email ora e quali saranno aggiunti in seguito.

Se non stai lavorando con un nuovo dominio, è una buona idea rivedere prima la configurazione attuale. A volte l'SPF esiste già, ma elenca ancora servizi obsoleti. A volte il DKIM è stato abilitato a un certo punto, ma il sistema di mailing si è poi spostato su un altro fornitore. E a volte il DMARC è presente, ma solo "per finta", senza report e senza una politica significativa, ed è meglio individuare queste cose prima di apportare modifiche, non dopo le lamentele degli utenti.

Configurare SPF per il dominio

Un record SPF è pubblicato nel DNS come un record TXT. Il suo compito è elencare le fonti di invio approvate. L'idea di base è semplice: specifichi quali servizi e server sono autorizzati a inviare email per conto del dominio, e tutto il resto è considerato non autorizzato.

Quando lo imposti, ricorda questo: un dominio dovrebbe avere un record SPF. Non due, non tre — uno. Se aggiungi più record TXT con SPF, molti destinatari lo tratteranno come un errore. Questo è uno dei problemi più comuni nel supporto all'infrastruttura email, e l'impostazione dell'autenticazione email per il dominio è particolarmente sensibile ai dettagli qui.

La logica SPF tipica è costruita attorno a meccanismi come include, ip4, ip6 e mx. In pratica, ciò significa che puoi includere un servizio di mailing di terze parti, indirizzi IP specifici o i server di posta del dominio. Ma c'è un problema: ogni voce aggiuntiva rende il record più lungo e complesso.

Un altro errore comune è essere troppo generali. A volte le persone usano regole eccessivamente permissive solo per “evitare di rompere qualcosa.” Di conseguenza, più mittenti sono autorizzati del necessario. Questo è comodo all'inizio, ma peggio per la sicurezza, e se proteggere contro messaggi falsificati è importante per te, SPF dovrebbe essere preciso, non solo “approssimativamente corretto.”

Dopo aver pubblicato il record, controlla che sia effettivamente visibile nel DNS e corrisponda alle tue attuali fonti di invio. Se invii email attraverso più piattaforme, verifica ciascuna di esse. Altrimenti, puoi facilmente trovarti in una situazione in cui le email CRM passano, ma le notifiche del sito web no.

Impostazione di DKIM: generazione di una chiave e pubblicazione del record DNS

DKIM funziona con una coppia di chiavi: la chiave privata rimane con il mittente e la chiave pubblica è pubblicata nel DNS, e quando un messaggio viene inviato, il server lo firma con la chiave privata. Il destinatario prende la chiave pubblica dal DNS e verifica la firma. Se tutto corrisponde, il messaggio è considerato autentico.

DKIM è solitamente configurato tramite il servizio email. Nel pannello di controllo del fornitore, selezioni il dominio, genera una chiave o ricevi impostazioni pronte, e poi pubblichi un record TXT con la parte pubblica della chiave. Un selettore è spesso incluso nel record: un nome speciale che aiuta a distinguere una chiave dall'altra. Questo è particolarmente utile se il dominio ha diversi sistemi di invio o se si prevede di ruotare le chiavi.

Dopo aver pubblicato il record DNS, è necessario abilitare la firma per i messaggi in uscita nel servizio stesso, e senza questo, il record DNS è inutile: la chiave rimarrà nella zona, ma le email rimarranno non firmate. Da un punto di vista della risoluzione dei problemi, questa è una trappola comune: “Il record è stato aggiunto, ma DKIM non funziona.” In realtà, la firma semplicemente non è stata abilitata dal lato del mittente, quindi il l'impostazione dell'autenticazione email per il dominio rimane incompleto.

Tecnicamente, è importante controllare:

• se il selettore corrisponde tra DNS e le impostazioni del servizio;
• se il record TXT è stato pubblicato correttamente;
• se la chiave è stata accidentalmente tagliata quando incollata;
• se tutti i tipi di messaggi necessari sono firmati, non solo alcuni di essi;
• se il messaggio cambia dopo la firma, ad esempio a causa di un'elaborazione extra da parte di un servizio intermedio.

DKIM è particolarmente utile per le email transazionali: conferme di registrazione, reset della password, notifiche d'ordine. Questi messaggi devono arrivare in modo coerente. Se il sito ha una struttura ben organizzata e un solido supporto post-lancio, come supporto del sito web dopo il lancio, l'autenticazione email è di solito una delle cose che non viene rinviata "a dopo". E questo è l'approccio giusto.

Impostazione della politica e dei report DMARC

DMARC aggiunge controllo. Senza di esso, puoi vedere SPF e DKIM separatamente, ma non hai una regola chiara su cosa fare con i messaggi sospetti. Un record DMARC è anche pubblicato nel DNS come un record TXT, di solito sotto il sottodominio _dmarc.

All'inizio, molte persone scelgono una politica none. Questa è una modalità di monitoraggio: i messaggi non vengono bloccati, ma il proprietario del dominio riceve report e può vedere chi sta inviando email, se i controlli stanno passando e dove sono le lacune. È un primo passo sensato, soprattutto se l'infrastruttura è complessa e non vuoi interrompere improvvisamente messaggi legittimi.

Dopo un periodo di monitoraggio, la politica può essere inasprita: la quarantena invia messaggi sospetti nello spam o in quarantena, mentre il rifiuto li blocca completamente. Quale opzione scegliere dipende da quanto è maturo il tuo setup email e da quanto sei sicuro che tutte le fonti legittime siano già contabilizzate.

Nei report DMARC, è utile cercare non solo errori, ma anche fonti di invio inaspettate, e a volte servizi obsoleti, piattaforme di test o integrazioni dimenticate compaiono lì. Questa è una buona opportunità per sistemare le cose.

Se stai implementando DMARC per un dominio aziendale, vale la pena controllare se processi importanti dipendono da servizi di terze parti. Ad esempio, se il sito utilizza attivamente moduli e notifiche email, e la struttura del sito è costruita in modo che i messaggi passino attraverso diversi moduli, è utile allineare ogni punto di invio in anticipo. Copriamo anche domande correlate nel tema di struttura del sito web aziendale: più chiara è l'architettura, meno sorprese ci saranno a livello di email e più fluido sarà il setup dell'autenticazione email.

Verifica e risoluzione dei problemi dopo il deployment

Dopo la configurazione, non fare affidamento sulla sensazione che “sembra funzionare.” La verifica dovrebbe essere deliberata e metodica.

Prima di tutto, assicurati che il record SPF sia visibile in DNS e contenga solo fonti attuali. Poi invia un messaggio di prova e controlla le intestazioni dal lato del destinatario: di solito mostrano se lo SPF è passato, se c'è una firma DKIM e se DMARC è stato attivato.

Se il messaggio non supera la verifica, cerca la causa passo dopo passo:

1. i record DNS sono stati inseriti correttamente;
2. è passato abbastanza tempo per la propagazione DNS;
3. il dominio nel campo From corrisponde al dominio di firma;
4. il messaggio è firmato dal servizio che ti aspetti;
5. un sistema intermedio sta modificando il messaggio dopo la firma.

È molto utile testare non solo un messaggio, ma diversi scenari: un modulo sul sito web, un'email CRM, una notifica di registrazione, una newsletter inviata tramite un servizio di email marketing. A volte il problema appare solo in un canale mentre gli altri sembrano perfetti.

Vale anche la pena controllare come vengono interpretati i record DNS. Gli errori possono essere banali: uno spazio extra, la citazione sbagliata, un selettore errato, più record SPF invece di uno solo. Piccoli dettagli come questi possono rovinare il risultato, anche quando tutto sembra corretto a prima vista.

Domande comuni e raccomandazioni per mantenere l'impostazione sana

Cosa dovresti fare se il tuo servizio email cambia? Prima, aggiungi il nuovo mittente a SPF, configura DKIM con il nuovo fornitore, testa l'invio e solo allora disattiva il vecchio, e non puoi semplicemente "cambiare" servizi e sperare che i vecchi record smettano di avere importanza da soli. L'infrastruttura email ama la precisione, e l'impostazione dell'autenticazione email per il dominio richiede una sequenza.

E se vengono inviati diversi messaggi, e alcuni provengono dal sito web mentre altri provengono da una piattaforma esterna? Allora è importante fare un elenco completo di tutti i mittenti. Per un sito web, questo potrebbe includere un plugin SMTP, un sistema di notifiche, un servizio di mailing e persino uno strumento di modulo di contatto separato. Più chiaro è l'elenco, più facile è mantenere SPF e DMARC senza conflitti.

Le impostazioni necessitano di controlli regolari? Sì. Soprattutto se hai cambiato hosting, spostato il dominio, collegato un nuovo CRM o aggiornato il tuo sistema di mailing. A volte i record DNS rimangono obsoleti semplicemente perché nessuno li ricorda più. E i record dimenticati sono spesso una fonte nascosta di errori.

Se non sei sicuro che la tua attuale configurazione di invio email sia trasparente, ha senso guardarla nel suo insieme: chi invia, chi firma, dove sono memorizzati i record e chi è responsabile delle modifiche. Nei progetti più complessi, questo diventa parte del supporto generale e dell'architettura tecnica, non un "compito IT" di cinque minuti.

E un altro consiglio pratico: non affrettarti ad abilitare una politica di rifiuto rigorosa se il dominio è vecchio e ha molti mittenti non correlati. Prima raccogli i dati, attiva la segnalazione, rimuovi ciò che è superfluo e solo allora inizia a stringere gradualmente la politica, e nell'autenticazione email, affrettarsi porta quasi sempre a bloccare la posta di cui hai realmente bisogno.

Se desideri un dominio che non solo abbia un bell'aspetto nella barra degli indirizzi ma che superi anche i controlli della posta con fiducia, SPF, DKIM e DMARC dovrebbero essere considerati una parte obbligatoria del progetto. Non è una misura decorativa — è un modo per proteggere il tuo marchio, costruire fiducia e rendere la consegna delle email prevedibile. E la prevedibilità, come dimostra la pratica, vale più di qualsiasi configurazione appariscente ma fragile.