Configurare SPF, DKIM e DMARC su Plesk senza errori

Nel mio lavoro quotidiano di assistenza tecnica per siti web, configurare SPF, DKIM e DMARC su Plesk è una delle richieste che ricevo più spesso dai clienti che usano il proprio dominio per inviare email. So bene quanto sia frustrante vedere le proprie email finire nello spam o ricevere notifiche di mancata consegna: chi gestisce un sito o lavora con la posta elettronica aziendale non può permettersi questi problemi.

Molti sottovalutano l’importanza di questi tre record DNS: SPF (Sender Policy Framework) serve a dire quali server possono inviare email per conto del tuo dominio; DKIM (DomainKeys Identified Mail) aggiunge una firma digitale alle email in uscita; DMARC (Domain-based Message Authentication, Reporting and Conformance) stabilisce come i provider devono gestire i messaggi che falliscono i controlli SPF e DKIM. Senza una configurazione corretta, rischi che le tue email vengano bloccate o contrassegnate come sospette.

Nella mia esperienza ho visto aziende perdere comunicazioni importanti solo per piccoli errori nei record DNS o opzioni non attivate in Plesk. In questa guida ti mostro, passo dopo passo e basandomi sui casi reali che ho risolto negli anni, come assicurarti di avere tutto configurato al meglio. Seguendo le procedure che applico ogni giorno, renderai il tuo sistema di posta solido e affidabile: niente più tentativi a vuoto, niente più bounce inspiegabili o messaggi finiti nel cestino dello spam.

I sintomi tipici di una configurazione errata SPF/DKIM/DMARC

Quando mi chiamano perché “l’email non arriva” o “il cliente dice che la mia mail è andata nello spam”, so già dove guardare per primo: la configurazione dei record SPF, DKIM e DMARC. Ecco i segnali più frequenti che vedo nei sistemi mal configurati:

• Email inviate da dominio personalizzato finiscono nello spam su Gmail, Outlook o altri provider
• Ricezione di report DMARC con segnalazioni di fail SPF o fail DKIM (molti ignorano questi report ma sono fondamentali)
• Bounce con messaggi tipo “SPF check failed” oppure “554 5.7.1 dmarc policy reject”
• Email recapitate ma con avvisi tipo “la firma digitale dell’email non è valida”
• Nessun problema apparente ma livello di deliverability molto basso (pochi tassi di apertura)

Nella mia esperienza, spesso bastano pochi minuti per risolvere questi problemi una volta individuata la causa. Di solito si tratta semplicemente di:

1. Mancanza totale dei record SPF/DKIM/DMARC nel DNS del dominio
2. Errori di sintassi nei record TXT (uno spazio fuori posto può bloccare tutto!)
3. Pannello Plesk che ha la firma DKIM disattivata sulle caselle in uscita
4. Sovrapposizione tra servizi esterni (tipo newsletter) e server Plesk non considerati nel record SPF
5. Policy DMARC troppo restrittiva senza controllare prima i risultati dei test

Prima di intervenire faccio sempre un check completo della zona DNS e delle opzioni attive in Plesk: così evito errori grossolani e posso agire subito dove serve.

La procedura completa e testata che applico sempre su Plesk

Dopo anni a lavorare con Plesk e i sistemi DNS, ho affinato una procedura step-by-step che risolve il 95% dei problemi legati a SPF, DKIM e DMARC. Ti spiego esattamente cosa faccio ogni volta:

1. Eseguo il backup della zona DNS: Prima di modificare qualsiasi record, esporto la zona DNS dal pannello Plesk (Strumenti & Impostazioni > Siti Web & Domini > DNS Settings). Un backup permette sempre il rollback rapido se qualcosa va storto.
2. Verifico lo stato attuale: Controllo se già esistono record SPF/DKIM/DMARC usando la sezione DNS Settings del dominio su Plesk e strumenti online gratuiti (come MXToolbox).
3. Sistemo/aggiungo il record SPF: Dal pannello vado su Siti web & Domini > Dominio desiderato > Impostazioni DNS. Creo/modifico un record TXT con questa sintassi base:
   @ TXT “v=spf1 +a +mx ~all”
   Se uso servizi terzi (ad esempio Google Workspace), aggiungo include:_spf.google.com. In caso di invio da server newsletter esterni inserisco anche il relativo include.
4. Configuro la firma DKIM in uscita: Rientro nella sezione Posta del dominio ("Posta" > "Impostazioni") e attivo l’opzione “Firma messaggi in uscita utilizzando DKIM”. Così facendo, Plesk genera automaticamente i valori pubblici da inserire nella zona DNS.
   Aggiungo poi manualmente il record TXT suggerito dal pannello:
   default._domainkey TXT “public key generata”
5. Aggiungo il record DMARC: Sempre dalla gestione DNS aggiungo un nuovo TXT:
   _dmarc TXT “v=DMARC1; p=none; rua=mailto:tuamail@tuodominio.it”
   Per iniziare consiglio sempre p=none, così ricevi solo report senza rischiare blocchi improvvisi sulle mail legittime. Più avanti puoi impostarlo su p=quarantine o p=reject.
6. Doppio controllo della propagazione: Verifico dopo qualche ora che tutti i nuovi record siano visibili pubblicamente con strumenti come dig/nslookup oppure web tool dedicati.
7. Eseguo test reali: Invio email verso vari provider (Gmail, Outlook ecc.) e analizzo gli header delle mail ricevute per vedere lo stato pass/fail dei controlli SPF/DKIM/DMARC.

Nella maggior parte dei casi queste azioni bastano per sistemare definitivamente il problema.

Casi reali che ho risolto grazie alla giusta configurazione DNS in Plesk

Lavorando su decine di domini al mese mi è capitato spesso di affrontare situazioni particolari dove un dettaglio faceva la differenza tra successo e fallimento nella protezione delle email.

• Email newsletter sempre in spam: Una volta ho trovato un cliente che usava sia il proprio server Plesk che Mailchimp per mandare DEM dal suo dominio. Nel suo SPF c’era solo l’IP del server principale, mancava l’include Mailchimp: bastava aggiungerlo (“include:servers.mcsv.net”) per vedere le sue campagne finalmente recapitarsi nella inbox invece dello spam.
• Errori causati da doppio DKIM: Su alcuni provider esterni era stato creato un altro selector DKIM diverso da quello generato da Plesk (“selector1” invece del classico “default”). Il risultato? Le firme risultavano invalidated ai controlli automatici. Eliminando i vecchi selector inutilizzati dalla zona DNS si è sistemato tutto al volo.
• Bounce improvvisi dopo cambio policy DMARC: Un’azienda aveva impostato direttamente “p=reject” nel record DMARC senza fare test preliminari. Dopo poche ore molte email interne venivano respinte! Tornando temporaneamente a “p=none”, analizzando i report ricevuti nella mail monitorata (rua), sono riuscito ad identificare tutti gli IP legittimi ma sconosciuti al DNS — li abbiamo poi inseriti correttamente nel nuovo SPF definitivo prima di riattivare la policy restrittiva.

Tutto questo dimostra quanto sia fondamentale conoscere bene ogni singola voce delle impostazioni DNS su Plesk , soprattutto quando più servizi interagiscono sullo stesso dominio.

Differenze chiave tra le versioni Linux/Windows di Plesk nella gestione email sicura

Nella mia esperienza trovo spesso clienti confusi tra versione Linux e Windows Server del pannello Plesk . Ecco alcune differenze concrete da tenere presente quando configuri SPF/DKIM/DMARC:

• Pannello Posta leggermente diverso: Su Linux si trova facilmente l’opzione “Abilita la firma DKIM”. Su Windows Server potrebbe trovarsi sotto voci diverse o richiedere moduli aggiuntivi installati a parte (esempio: MailEnable).
• Sintassi diversa nei record generati automaticamente :Certe build Windows propongono stringhe leggermente differenti o formattate con escape diversi — bisogna copiarle fedelmente così come suggerite dal pannello senza modificarle manualmente!
• L’invio relay SMTP esterno va gestito specificamente nei permessi firewall :Soprattutto in hosting Windows è fondamentale autorizzare esplicitamente gli IP dei relay nelle regole outbound/inbound ed eventualmente aggiornare anche policy antispam integrate lato server.

A prescindere dalla versione uso sempre lo stesso principio: copia esatta dei dati suggeriti dal pannello nelle zone DNS pubbliche e doppia verifica tramite tool esterni specifici per evitare sorprese dovute a minuscole differenze implementative tra versioni software diverse.

I miei test fondamentali post-configurazione: evitarne anche uno può vanificare tutto!

Dopo aver completato tutte le modifiche lato pannello controllo sempre scrupolosamente ogni aspetto perché anche una piccola svista può annullare giorni di lavoro sulla deliverability delle email.
Ecco la checklist finale che applico SEMPRE dopo aver messo mano ai record SPF/DKIM/DMARC su Plesk :

1. Eseguo una query dig/nslookup sui nuovi TXT appena caricati (dove @ rappresenta il root domain, default._domainkey ecc).
2. Mando almeno un’email test verso Gmail usando mittente reale del dominio verificando negli header ricevuti:
   • X-SPF-Result = pass;
   • X-DKIM-Result = pass;
3. Apro uno strumento online tipo MXToolbox o Google Postmaster Tools per visualizzare lo stato effettivo della reputazione mail/dominio/IP sorgente dopo qualche ora dall’invio delle prime mail real-life;

• Lancio periodicamente invii verso destinatari Outlook/Yahoo ecc perché alcuni provider hanno filtri leggermente diversi rispetto a Gmail;

Cosa fare se qualcosa ancora non funziona? Soluzioni pratiche dai miei interventi sul campo

Anche seguendo tutti i passi sopra indicati può capitare qualche intoppo imprevisto. Ecco come affronto io le situazioni anomale più frequenti durante/l’immediato dopo la configurazione dei tre record chiave :

• Record duplicati : Se ne trovo due uguali o sovrapposti sulla stessa voce ( esempio due _dmarc oppure due default._domainkey ), cancello SEMPRE quello superfluo lasciando solo quello effettivamente operativo .
• Sintassi errata / carattere mancante : Basta uno slash / virgola sbagliata , ed il server destinatario ignora completamente tutta quella policy . Per sicurezza copio –incollo SEMPRE le stringhe direttamente dal pannello , MA controllo anche via web tool dedicati ( tipo dnsviz ) per assicurarmi NON ci siano warning nascosti .
• Cache lenta / propagazione incompleta : Se vedo ancora errori sulle mail dopo poche ore , consiglio SEMPRE pazienza : certe zone DNS impiegano fino a 24 –48 ore prima della piena propagazione globale !
• Problemi con servizi terzi : Se usi piattaforme esterne come CRM , mailing list ecc , assicurati SEMPRE siano presenti tutti gli include necessari nell’SPF ed eventuale sotto –selector DKIM pubblicizzato dalla piattaforma stessa . Più volte mi sono trovato ad inserire fino a quattro include diversi nello stesso record !