Come configurare correttamente SPF, DKIM e DMARC in Plesk

In questa guida, vi mostrerò passo dopo passo come SPF DKIM e DMARC in Plesk, in modo che le vostre e-mail siano autenticate in modo affidabile. Riceverete procedure chiare per le voci DNS, gli switch di Plesk e i metodi di test con cui potrete aumentare la deliverability e bloccare i mittenti abusivi.

Punti centrali

• SPF determina quali sistemi sono autorizzati a inviare messaggi di posta elettronica per il vostro dominio.
• DKIM firma i messaggi in uscita e protegge dalle manipolazioni.
• DMARC collega SPF/DKIM con linee guida e rapporti.
• Plesk fornisce procedure guidate e modelli DNS per un avvio rapido.
• Monitoraggio dei rapporti DMARC rende più precisa la vostra politica operativa.

Controllare i prerequisiti in Plesk

Prima di effettuare qualsiasi impostazione, controllo il server di posta utilizzato in Plesk e la gestione del DNS. Su Linux di solito lavoro con Postfix, su Windows con SmarterMail, poiché questi servizi forniscono le funzioni SPF, DKIM e DMARC. Verifico anche se il dominio ha le sue zone DNS nel DNS di Plesk o con un provider esterno, perché così posso gestire le voci al di fuori di Plesk deve essere aggiunto. Per un funzionamento regolare, mantengo puliti il nome host, il reverse DNS e i certificati TLS validi, poiché i server di consegna controllano questi punti. Un punto di partenza pulito consente di risparmiare molto tempo in seguito e di rafforzare il sistema. La reputazione.

Impostazione di SPF in Plesk - passo dopo passo

Per iniziare, apro "Strumenti e impostazioni" → "Impostazioni DNS" e cerco un record TXT che inizia con v=spf1 inizia. Se manca, lo metto, ad esempio: v=spf1 a mx include:yourmailprovider.de -allin modo che i sistemi autorizzati possano inviare e tutti gli altri siano bloccati. Se il dominio utilizza altri mittenti, come Microsoft 365, Google Workspace o i servizi di newsletter, aggiungo l'apposita opzione includere-dalla loro documentazione. Dopo aver salvato, lascio trascorrere fino a 48 ore affinché la modifica abbia effetto a livello globale e verifico il record con un verificatore SPF tramite un'e-mail di prova a una casella di posta selezionata. È possibile trovare una classificazione compatta dell'interazione dei meccanismi nel documento Guida compattache spiega gli scenari più importanti.

Attivare il DKIM in Plesk - ecco come procedere

Per DKIM Vado in "Strumenti e impostazioni" → "Impostazioni del server di posta" e attivo l'opzione di firma delle e-mail in uscita. Apro quindi "Siti web e domini" a livello di dominio → Dominio → "Posta" → "Impostazioni" e controllo se la firma è attivata per ogni dominio. Se gestisco il DNS esternamente, esporto i dati da Plesk generato le chiavi pubbliche DKIM e inserirle come record TXT con il provider DNS (notare il nome del selettore). Dopo un massimo di 24-48 ore, i destinatari dovrebbero convalidare le firme DKIM, cosa che io confermo inviando una mail di prova a una casella di controllo DKIM o a un controllo dell'intestazione. Una firma valida rafforza la Consegnabilità percepibile.

Definire i criteri DMARC e utilizzare i rapporti

Ora ho impostato DMARC come record TXT su _dmarc.yourdomain.tld con il valore v=DMARC1; p=quarantena; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. Le etichette p, rua e chiamata politica di controllo e reporting, mentre adkim/aspf definire l'allineamento rigoroso (strict). In pratica, spesso inizio con p=nessunovalutare i rapporti per due-quattro settimane e quindi redigere quarantena oppure respingere . I rapporti mostrano quali sistemi inviano le e-mail per conto dell'utente e dove SPF o DKIM non funzionano, consentendo di apportare correzioni dirette. Una sequenza più dettagliata di passaggi descrive la Implementazione del DMARC con esempi concreti.

Propagazione DNS, test e best practice

Ogni modifica DNS richiede tempo, quindi prevedo fino a 48 ore per le modifiche DNS a livello mondiale. Propagazione on. In questa fase, invio messaggi di posta elettronica di prova a caselle esterne e verifico i risultati dell'autenticazione nell'intestazione di spf=pass, dkim=pass e dmarc=pass. Se una mail riceve un softfail oppure NeutroControllo i meccanismi SPF, i selettori DKIM e l'envelope-from (percorso di ritorno) per verificare l'allineamento con From:. Quando utilizzo i reindirizzamenti, controllo i risultati del DMARC, poiché l'SPF spesso si interrompe; il DKIM di solito lo compensa. Evito ~Tutti permanentemente e per configurazioni produttive affidarsi costantemente a -tutti.

Tag e valori DMARC - tabella compatta

Utilizzo la seguente panoramica per DMARC in modo rapido e affidabile e per evitare interpretazioni errate. Mantengo i valori coerenti tra i domini principali e i sottodomini e documento le modifiche in modo tracciabile. Per i domini produttivi, imposto un allineamento rigoroso e attivo sempre i report aggregati. Rapporti forensi (chiamata) Pianifico nel rispetto delle norme sulla protezione dei dati. La definizione di linee guida chiare stabilizza il La reputazione del dominio in modo sostenibile.

Giorno	Significato	Valori possibili	Raccomandazione
p	Politica per il dominio principale	nessuno, quarantena, rifiuto	Iniziare con nessuno, poi aumentare fino a rifiutare
sp	Politica per i sottodomini	nessuno, quarantena, rifiuto	sp=rifiuta per le configurazioni produttive
rua	Rapporti aggregati	mailto:adresse	Utilizzate il vostro indirizzo di segnalazione
chiamata	Rapporti forensi	mailto:adresse	Attivare solo se necessario
adkim	Allineamento DKIM	r (rilassato), s (rigoroso)	adkim=s per un'assegnazione chiara
aspf	Allineamento SPF	r (rilassato), s (rigoroso)	aspf=s per ridurre i falsi allarmi
pct	Percentuale di applicazione	0-100	Stringere passo dopo passo con il pct

Integrazione di mittenti esterni: Microsoft 365, Google, servizi di newsletter

Se un dominio utilizza percorsi di spedizione aggiuntivi, aggiungo l'SPF include per Microsoft 365, Google Workspace, Mailgun, SendGrid o strumenti di newsletter esattamente come documentato. Per ogni servizio, verifico se è attiva una chiave DKIM separata e se il dominio from è realmente firmato. Evito i duplicati o il numero eccessivo di includere-cascate, poiché l'SPF è limitato a dieci ricerche DNS. Se il budget per le ricerche non è sufficiente, consolido i mittenti o sposto i singoli flussi in sottodomini con una propria politica DMARC. In questo modo mantengo l'SPF snello e sicuro. Firme da.

Controlli approfonditi e selezione dei server

Per la posta in arrivo attivo in Plesk controllare SPF, DKIM e DMARC in modo che il server filtri lo spam in una fase iniziale. Questi controlli sono disponibili come standard su Linux, mentre su Windows sono implementati con SmarterMail. Mi assicuro che il server di posta sia aggiornato correttamente, in modo che le routine di firma e i parser rimangano aggiornati. Se si verificano problemi di falsi positivi, regolo le soglie di punteggio, ma mai le soglie di punteggio. Politica del proprio dominio. In questo modo mantengo alta la protezione e garantisco la consegna da parte di mittenti legittimi.

Errori comuni e soluzioni rapide

Pasti "SPF permerror", di solito c'è un errore di sintassi o è stato superato il limite di ricerca. Se DKIM fallisce, controllo il selettore, il record della chiave pubblica e la terminazione del valore TXT con virgolette corrette. Se DMARC fallisce fallireVerifico innanzitutto l'allineamento: From-Domain, Return-Path e DKIM-d= devono corrispondere perfettamente. Se l'SPF si rompe con i reindirizzamenti, mi affido a DKIM e mantenere stabile lo stato della firma. Con questa sequenza risolvo la maggior parte dei problemi di consegna senza una lunga ricerca.

Modelli DNS e automazione in Plesk

Se gestisco molti domini, imposto il parametro Modello DNS in Plesk e memorizzare i record standard per SPF, DKIM e DMARC. I nuovi domini ricevono immediatamente solide impostazioni predefinite che devo solo perfezionare. Implemento anche le modifiche pianificate, come un DMARC più rigoroso a livello di dominio, utilizzando modelli e script. Per la rotazione delle chiavi DKIM, lavoro con due selettori in modo da poter apportare modifiche graduali. In questo modo l'operazione rimane coerente su decine di domini e mantenibile.

Valutare i rapporti DMARC e rafforzare la policy

Dopo il go-live, analizzo quotidianamente i report aggregati e identifico Fontiche inviano per conto del dominio senza autorizzazione. Blocco gli IP imprevisti e ripulisco gli strumenti obsoleti prima di inasprire la politica. Il cambiamento da p=nessuno all'indirizzo quarantena e in seguito respingere Eseguo con pct in più fasi, in modo da poter misurare gli effetti in modo controllato. Se nel report fallito compaiono mittenti legittimi, correggo le inclusioni SPF o attivo la mia chiave DKIM. Questa routine rafforza il La reputazione visibile e riduce lo spoofing.

Comprendere correttamente l'allineamento

Così che DMARC Assicuro costantemente un allineamento corretto. Con SPF è il dominio nella busta da (percorso di ritorno) o l'identità HELO/EHLO, che deve corrispondere al dominio visibile da (strict: identico, relaxed: stesso dominio dell'organizzazione). Con DKIM Controllo il d=-L'attributo della firma: deve puntare allo stesso dominio (strict) o allo stesso dominio organizzativo (relaxed). In pratica, mi assicuro che:

• il percorso di rimbalzo utilizzato (percorso di ritorno) utilizza un dominio che corrisponde al dominio di provenienza o è deliberatamente esternalizzato a un sottodominio con una propria politica DMARC,
• tutti i fornitori di terze parti il dominio From segno (DKIM), non solo il proprio dominio di spedizione,
• la firma DKIM rimane intatta durante l'inoltro per compensare le interruzioni SPF.

Se manca l'allineamento, i ricevitori DMARC segnalano un errore nonostante un SPF/DKIM valido. dmarc=fallimento. Ecco perché controllo i campi nelle intestazioni delle e-mail Risultati dell'autenticazione, Percorso di ritorno e i parametri DKIM. Questo mi permette di riconoscere rapidamente se SPF o DKIM stanno fornendo l'allineamento e dove è necessario apportare miglioramenti.

Gestione delle chiavi e parametri DNS

Per la robustezza DKIM-Ho utilizzato chiavi a 2048 bit. In Plesk Posso impostare la lunghezza della chiave per ogni dominio; le chiavi più vecchie a 1024 bit vengono prontamente disattivate. Se necessario, divido i record TXT DKIM più lunghi in diversi segmenti con virgola invertita, in modo che il server DNS li consegni correttamente. Definisco anche dei record significativi TTL-valori: Nelle fasi di rollout vado a 300-900 secondi, in modo produttivo uso 1-4 ore. Questo mi permette di reagire in modo flessibile ai cambiamenti senza sovraccaricare le cache.

Il sito Rotazione Lo faccio senza problemi con due selettori:

1. Creare un nuovo selettore in Plesk e pubblicare la chiave pubblica come TXT nel DNS.
2. Cambiare il mittente con il nuovo selettore e osservare il monitoraggio (mostrare le intestazioni) s=nuovo selettore).
3. Una volta convertiti tutti i flussi, rimuovere il vecchio selettore nel DNS e disattivarlo in Plesk.

Ove possibile, utilizzo fornitori di terze parti, delegato record DKIM (ad esempio CNAME al selettore del provider). Questo mi permette di mantenere il controllo della mia zona e di ruotare le chiavi senza rischiare interruzioni operative.

Casi speciali: Inoltro, mailing list e gateway

In ambienti reali, vedo regolarmente reindirizzamenti, mailing list o gateway di sicurezza che riscrivono le e-mail. In questo caso presto particolare attenzione agli effetti:

• InoltroL'SPF spesso si interrompe perché l'IP di inoltro non è presente nell'SPF del dominio mittente. In questo caso mi affido a DKIMche fornisce la protezione del contenuto. Se la firma rimane invariata, il DMARC esiste tramite l'allineamento DKIM.
• Liste di distribuzioneMolte liste cambiano argomento o piè di pagina, rompendo così la firma DKIM. In questi casi, pianifico un allineamento rilassato e verifico se la lista utilizza SRS/ARC o le proprie firme. Se possibile, utilizzo un sottodominio con una propria politica DMARC per le liste.
• Gateway di sicurezzaI gateway che rifirmano i messaggi o riscrivono l'envelope-from devono essere correttamente allineati al dominio del mittente. Documento il loro ruolo e li ancoro nell'SPF (ip4/ip6) o tramite include in modo che l'allineamento sia mantenuto.

Incontrare le mail con spf=fail attraverso un inoltro, questo non è automaticamente critico, a patto che dkim=pass è presente e l'allineamento DKIM è corretto. Valuto l'insieme dei risultati dell'autenticazione invece dei singoli segnali isolati.

IP condivisi, HELO/EHLO e rDNS

Se più domini condividono lo stesso IP in uscita, mi affido ad un IP pulito rDNS e nomi HELO/EHLO coerenti. Il puntatore inverso punta a un FQDN (ad es. mail.hosting-example.tld), il cui record A punta allo stesso IP. L'MTA riporta esattamente questo nome. Mi assicuro che il Certificato SMTP TLS corrisponde al nome HELO (SNI se vengono serviti più nomi). Per ogni dominio mittente, mi assicuro anche che SPF/DKIM/DMARC siano completamente e correttamente allineati; il solo IP condiviso non influisce su DMARC finché l'autenticazione è efficace.

Per i mittenti dedicati (ad esempio, posta transazionale e marketing), mi piace separarli tramite sottodomini e, facoltativamente, IP propri. Questo aiuta a Gestione della reputazionesemplifica la valutazione delle segnalazioni DMARC e riduce al minimo le interferenze reciproche.

Monitoraggio e implementazione nella pratica

Per garantire un funzionamento regolare, combino la continua Analisi DMARC con chiare fasi di implementazione:

• Linea di base: 2-4 settimane p=nessunoraccogliere tutti i rapporti aggregati (rua), identificare le fonti di errore.
• PuliziaEliminare i mittenti non autorizzati, ripulire gli include SPF, attivare DKIM su tutti i sistemi legittimi.
• VestizioneCon pct gradualmente a quarantena, in seguito respingere aumento, misurare gli effetti in percentuale.
• AllarmeDefinire i valori di soglia (nuovi IP, tasso di fallimento per provider, nuovi domini) e impostare le notifiche.
• DocumentazioneMantenere i selettori, il TTL, i tempi di esecuzione delle chiavi, il budget SPF e le responsabilità sotto controllo di versione.

Controllo il Budget di ricerca SPF (max. 10 meccanismi con query DNS) e consolidare include. Meccanismi critici come ptr oppure +tutto In genere non li uso; ip4/ip6, a, mx e mirato includere rimangono i mezzi di scelta. In questo modo mantengo la configurazione stabile e verificabile.

Controllo rapido per ogni dominio

Alla fine di ogni installazione, eseguo un'analisi fissa di Controllo attraverso: Record SPF disponibile, budget di ricerca inferiore a dieci, meccanismi ordinati correttamente, -tutti Attivo. Firma DKIM valida, selettore documentato, lunghezza della chiave sufficiente, rotazione prevista. DMARC con record TXT valido, allineamento rigoroso, caselle di posta elettronica di segnalazione accessibili e archiviate. Mostra le mail di prova spf=pass, dkim=pass e dmarc=pass nell'intestazione. Uso questa sequenza per mantenere le configurazioni riproducibili e Errore basso.

Riassunto pratico per un rapido successo

Inizio ogni progetto con una chiara StandardMantenete l'SPF, attivate il DKIM per ogni mittente e introducete il DMARC con il reporting. Seguono da due a quattro settimane di monitoraggio per eliminare i punti ciechi e rafforzare le linee guida. Integrare i servizi esterni in modo controllato, documentare le inclusioni e tenere sotto controllo il budget per le ricerche. Utilizzo modelli DNS per diversi domini e pianifico la rotazione delle chiavi DKIM per mantenere fresche le firme. Riassumo le idee pratiche utili e i consigli per la risoluzione dei problemi nel mio Suggerimenti per Plesk 2025 insieme, in modo da mantenere una forte Consegnabilità raggiungere.