SPF, DKIM e DMARC con l'hosting CURIAWEB

SPF, DKIM e DMARC appartengono alle procedure più importanti per l'autenticazione delle e-mail. Aiutano i server di posta riceventi a valutare se un messaggio sia stato effettivamente inviato tramite sistemi autorizzati e se il dominio del mittente utilizzato corrisponda al messaggio.

Con un normale hosting CURIAWEB, i record DNS necessari per SPF, DKIM e DMARC vengono fondamentalmente configurati automaticamente. Se invii le tue e-mail esclusivamente tramite la regolare infrastruttura di posta CURIAWEB e la zona DNS è gestita da CURIAWEB, normalmente non devi creare questi record tu stesso.

Importante: Non modificare i record SPF, DKIM o DMARC alla cieca. Una configurazione errata può far sì che le email legittime non superino più l'autenticazione, peggiorandone la recapitabilità o facendole classificare come spam.

Cosa fanno SPF, DKIM e DMARC? #

I tre procedimenti assolvono a compiti diversi e si integrano a vicenda.

Procedimento	Compito
SPF	Determina quali server o indirizzi IP sono autorizzati a inviare e-mail per un dominio.
DKIM	Appone una firma crittografica ai messaggi in uscita, verificabile tramite una chiave pubblica nel DNS.
DMARC	Collega SPF e DKIM al dominio del mittente visibile e pubblica una policy per la verifica DMARC.

In parole semplici, l'interazione può essere rappresentata così:

Email in uscita
       ↓
SPF
Il percorso di invio è autorizzato?
       +
DKIM
La firma crittografica è valida?
       ↓
DMARC
Almeno un'autenticazione riuscita
corrisponde al dominio del mittente visibile?
       ↓
Considera la policy DMARC

SPF con hosting CURIAWEB normale #

SPF significa Sender Policy Framework. Il record SPF viene pubblicato come record TXT nel DNS di un dominio.

Con un normale hosting CURIAWEB, il record SPF viene creato automaticamente nella zona DNS.

Ad esempio, una tipica configurazione standard di CURIAWEB si presenta così:

v=spf1 +a +mx +ip4:144.76.63.89 ~all

I singoli componenti hanno funzioni diverse:

componente	Significato
v=spf1	Contrassegna il record TXT come versione SPF 1.
+a	Autorizzate i sistemi determinati tramite il meccanismo A.
+mx	Autorizza i sistemi rilevati tramite i record MX del dominio.
+ip4:144.76.63.89	Autorizza questo indirizzo IPv4 per l'invio.
tutti	Altre fonti di spedizione non precedentemente registrate ricevono un SPF softfail.

Importante: Il record SPF mostrato qui è un esempio della normale configurazione di hosting CURIAWEB. Non copiarlo su un altro dominio o in un altro ambiente di hosting senza prima verificare l'effettiva via di invio.

Cosa significa tutti? #

Il ~ ladro tutto indica in SPF un Softfail.

Con ciò il dominio dichiara che i sistemi non coperti dai meccanismi precedenti non sono intesi come fonti di invio regolari. Tuttavia, la gestione finale di un tale messaggio spetta al sistema ricevente e ai suoi ulteriori controlli.

Questo differisce ad esempio da:

-tutti

Il segno meno indica un SPF Fallimento.

Non dovresti quindi semplicemente modificare un record SPF esistente da tutti su -tutti modificare. Una policy più severa ha senso solo se l'intero ambiente di spedizione è noto e correttamente preso in considerazione.

DKIM per l'hosting CURIAWEB #

DKIM significa DomainKeys Identified Mail.

Mentre SPF autorizza il percorso di invio, DKIM lavora con una firma crittografica.

In parole semplici, DKIM è composto da due parti:

Chiave DKIM privata
→ si trova sul sistema mittente
→ firma l'e-mail in uscita

Chiave DKIM pubblica
→ viene pubblicata nel DNS
→ consente al destinatario di effettuare la verifica

La chiave privata non deve essere accessibile pubblicamente. Nel DNS si trova esclusivamente la parte pubblica.

Come appare un record DKIM? #

DKIM utilizza un cosiddetto Selettore. Ciò consente a un dominio di utilizzare diverse chiavi DKIM e di sostituire le chiavi in un secondo momento.

Un nome DNS DKIM segue fondamentalmente questo schema:

selector._domainkey.example.ch

Il record TXT corrispondente contiene, tra le altre cose, la chiave pubblica.

Schematicamente, un record DKIM appare ad esempio così:

v=DKIM1; k=rsa; p=PUBLIC_KEY

La chiave pubblica effettiva è molto più lunga e viene generata automaticamente per il dominio in questione.

Attenzione: Non utilizzare mai la chiave DKIM di un altro dominio e non copiare i record DKIM tra domini. La rispettiva coppia di chiavi appartiene alla specifica configurazione DKIM del dominio.

Normalmente non devi creare tu stesso il DKIM #

In una configurazione di hosting CURIAWEB regolare, DKIM viene impostato automaticamente.

Se il tuo dominio utilizza la zona DNS CURIAWEB e le e-mail vengono inviate tramite l'infrastruttura di posta prevista, non dovresti quindi creare ulteriormente un tuo record DKIM.

La presenza di più selettori DKIM è tecnicamente del tutto possibile. Tuttavia, dovrebbero essere presenti solo se i rispettivi sistemi di invio firmano effettivamente con queste chiavi di selettore.

Che cosa verifica DKIM? #

Durante l'invio, il messaggio viene firmato con la chiave privata DKIM. Il server di posta in arrivo legge, tra le altre cose, il dominio utilizzato e il selettore dalla firma DKIM.

Tramite questo selettore può recuperare la chiave pubblica associata nel DNS e verificare la firma.

Un risultato DKIM positivo può essere ad esempio:

dkim=pass

apparire nei risultati di autenticazione di un messaggio ricevuto.

Cosa significa un errore DKIM? #

Un errore DKIM può avere diverse cause. Ad esempio, potrebbe mancare la chiave pubblica, potrebbe essere stato utilizzato un selettore errato, oppure il messaggio o i relativi componenti firmati potrebbero essere stati modificati dopo la firma in modo tale che la firma non possa più essere validata con successo.

Un errore DKIM dovrebbe quindi essere esaminato in base al messaggio specifico e al suo percorso di invio.

DMARC per l'hosting CURIAWEB #

DMARC significa Domain-based Message Authentication, Reporting and Conformance.

DMARC si basa su SPF e DKIM, ma aggiunge un punto cruciale: la relazione con il dominio che il destinatario vede come mittente nel campo visibile Da:vede il campo dell'e-mail.

Con un normale hosting CURIAWEB viene creato automaticamente anche un record DMARC.

La configurazione standard di CURIAWEB è:

v=DMARC1; p=none;

Cosa significa v=DMARC1; p=none;? #

In questa configurazione di base, il record è costituito da due elementi essenziali.

componente	Significato
v=DMARC1	Contrassegna la voce come versione DMARC 1.
p=nessuno	Non pubblicare un record DMARC per mettere in quarantena o rifiutare i messaggi non riusciti basandosi esclusivamente sulla policy DMARC.

p=nessuno ciò non significa che SPF o DKIM siano disattivati. Allo stesso modo, non significa che un filtro antispam ricevente debba accettare un messaggio sospetto.

Ulteriori controlli di sicurezza e antispam del sistema ricevente rimangono invariati.

Dove si trova il record DMARC? #

DMARC viene registrato come record TXT sotto lo speciale nome host _dmarc pubblicato.

Per un dominio come:

example.ch

verrà inserito il record DMARC corrispondente sotto:

_dmarc.example.ch

richiamato.

Cosa sono p=nessuno, p=quarantena e p=rifiuta? #

DMARC conosce diverse policy di dominio.

Politica	Importanza fondamentale
p=nessuno	Nessuna istruzione di quarantena o rifiuto basata su DMARC.
p=quarantena	I messaggi che non superano il controllo DMARC devono essere trattati di conseguenza come sospetti dal sistema ricevente, tipicamente mediante quarantena o gestione dello spam.
p=rifiuta	I messaggi che non superano il controllo DMARC devono essere rifiutati.

Importante: Non limitarti a trasferire un dominio da p=nessuno su p=quarantena o p=rifiuta Mh. Innanzitutto bisogna assicurarsi che tutti i sistemi di spedizione legittimi siano autenticati correttamente tramite SPF e/o DKIM e raggiungano il necessario allineamento DMARC.

Cosa significa allineamento DMARC? #

DMARC non si limita a verificare se SPF o DKIM abbiano esito positivo da qualche parte in un messaggio. Ciò che è determinante è anche la relazione con il dominio del mittente visibile.

Questa relazione è considerata Allineamento definito.

In sintesi:

Mittente visibile:
info@example.ch

SPF:
Controllo del percorso di invio del mittente di busta (envelope sender) pertinente

DKIM:
Controllo della firma DKIM e del dominio di firma

DMARC:
Un'autenticazione riuscita corrisponde
al dominio del mittente visibile?

In questo modo DMARC rende tra l'altro più difficile per un attaccante autenticare correttamente una propria dominio, ma utilizzare un dominio esterno nel mittente visibile e spacciare tale autenticazione come prova per il dominio esterno.

Devono avere successo sia SPF che DKIM? #

Per un test DMARC riuscito, non è strettamente necessario l'SPF e DKIM gleichzeitig erfolgreich und aligned sein.

In linea di principio, DMARC può avere esito positivo se almeno uno dei due metodi di autenticazione ha esito positivo e viene soddisfatta la necessaria conformità con il dominio del mittente visibile.

Breve spiegazione: SPF e DKIM sono due diversi metodi di autenticazione. DMARC combina i relativi risultati con il dominio del mittente visibile.

Perché CURIAWEB utilizza per impostazione predefinita p=nessuno? #

Un dominio può utilizzare ulteriori sistemi per l'invio oltre al normale server di posta per l'hosting. A titolo esemplificativo, questi possono includere servizi di newsletter, negozi online, sistemi CRM, software di contabilità, sistemi di ticketing o servizi cloud esterni.

Una policy DMARC genericamente più rigida può diventare problematica se tali fonti di invio legittime non sono correttamente integrate nella struttura di autenticazione.

La configurazione predefinita con:

v=DMARC1; p=none;

evitate pertanto un'istruzione generale di mettere in quarantena o rifiutare i messaggi con DMARC non riuscito basandosi unicamente su questa policy.

Se per un dominio si desidera una strategia DMARC più rigorosa, è necessario prima analizzare l'intero panorama di invio.

Quando è necessario modificare la configurazione automatica? #

Fino a quando utilizzi esclusivamente la normale infrastruttura di posta elettronica di CURIAWEB, di solito non vi è alcun motivo di modificare le voci configurate automaticamente.

Tuttavia, una verifica o un adeguamento potrebbe rendersi necessario non appena ulteriori sistemi inviano e-mail con il tuo dominio come mittente.

Esempi tipici sono:

• Piattaforme di newsletter e marketing
• Sistemi CRM
• servizi SMTP esterni
• Microsoft 365 o altre piattaforme di posta elettronica esterne
• Sistemi di supporto e di ticket
• Negozio online e servizi di posta transazionale
• Filtraggio in uscita SpamExperts

Questi servizi potrebbero avere requisiti propri per SPF, DKIM o DMARC.

Non sovrascrivere i record DNS esistenti #

Se, ad esempio, un fornitore esterno richiede un meccanismo SPF aggiuntivo, il record SPF esistente non deve essere semplicemente eliminato e sostituito con il record di esempio del fornitore.

Con SPF, tutte le fonti di invio effettivamente autorizzate devono essere incluse in un record SPF valido.

Attenzione: Diversi record TXT separati, ciascuno con v=spf1 iniziare non è il metodo corretto per autorizzare più servizi di spedizione. I meccanismi necessari devono essere uniti in un'unica policy SPF.

Anche il DKIM può cambiare con i sistemi di invio esterni #

Un servizio di spedizione esterno può utilizzare un proprio selettore DKIM e richiedere la creazione di un record DNS aggiuntivo a tale scopo.

Ciò non significa automaticamente che la voce CURIAWEB-DKIM esistente debba essere rimossa.

Più selettori DKIM possono coesistere in parallelo quando diversi sistemi firmano ciascuno con la propria chiave associata.

SpamExperts richiede una considerazione separata #

Se viene utilizzato SpamExperts Outgoing Filtering, il percorso di invio delle e-mail non corrisponde più completamente alla normale configurazione standard di CURIAWEB.

In particolare, il record SPF deve quindi corrispondere all'infrastruttura di uscita di SpamExperts.

Spiegheremo la relativa configurazione separatamente su Configurare e verificare correttamente SPF per SpamExperts.

Anche il DKIM può essere configurato separatamente in SpamExperts Outgoing Filtering. È necessario tenere conto di una firma DKIM già esistente del sistema mittente.

Importante: Non utilizzare quindi semplicemente la normale configurazione CURIAWEB SPF o DKIM come modello per il filtraggio in uscita di SpamExperts. Il percorso di invio effettivo determina quali impostazioni di autenticazione sono necessarie.

SpamExperts verifica SPF, DKIM e DMARC per le e-mail in arrivo #

SpamExperts utilizza SPF, DKIM e DMARC anche nell'analisi dei messaggi in arrivo.

Questi controlli servono a includere informazioni sull'autenticità di un messaggio in arrivo o del relativo dominio del mittente nella decisione di filtraggio.

I relativi controlli dei canali dovrebbero essere sempre tenuti attivi.

Spieghiamo di più al riguardo sotto Impostazioni del filtro SpamExperts: perché la configurazione predefinita è solitamente la scelta migliore.

Controllare SPF, DKIM e DMARC in cPanel #

Su CURIAWEB puoi controllare le impostazioni DNS relative alla posta in cPanel.

Apri per farlo:

cPanel → Email → Recapito email

Lì è possibile visualizzare, tra le altre cose, informazioni relative a SPF e DKIM o problemi di configurazione rilevati per i domini in questione.

Per un controllo diretto della zona DNS, puoi anche Editor di zona usare.

Puoi trovare una guida dettagliata all'indirizzo Utilizzare l'editor di zone DNS in cPanel.

Rilevare SPF nel DNS #

Il record SPF è un record TXT il cui contenuto inizia con:

v=spf1

inizia.

In una normale configurazione CURIAWEB, ad esempio, potrebbe apparire così:

v=spf1 +a +mx +ip4:144.76.63.89 ~all

Riconoscere DKIM nel DNS #

I record DKIM si trovano sotto un nome host con:

._domainkey.

Ad esempio in modo schematico:

selector._domainkey.example.ch

Il selettore specifico e la chiave pubblica dipendono dalla configurazione del tuo dominio.

Rilevare DMARC nel DNS #

Il record TXT DMARC si trova presso:

_dmarc.example.ch

Nella configurazione standard di CURIAWEB, il contenuto è:

v=DMARC1; p=none;

Verificare l'autenticazione con un'email di prova #

Oltre al controllo DNS, puoi inviare un'email reale tramite il normale canale di spedizione e successivamente esaminare le sue intestazioni di messaggio complete o i risultati dell'autenticazione.

A seconda del servizio di posta elettronica ricevente, lì si possono trovare ad esempio risultati come:

spf=superato
dkim=superato
dmarc=superato

essere visualizzato.

La rappresentazione esatta varia a seconda del server di posta ricevente.

Consiglio pratico: Per un test significativo, utilizza esattamente il canale di spedizione che usi anche in produzione. Un'email di test tramite un altro servizio SMTP non dice nulla sul fatto che la normale configurazione di CURIAWEB funzioni correttamente.

Cosa fare in caso di spf=fail? #

Se un messaggio legittimo riceve un errore SPF, bisogna prima esaminare l'effettivo percorso di invio.

Verifica in particolare se il messaggio è stato inviato tramite il server di posta designato e se vengono utilizzati servizi di invio esterni aggiuntivi.

Su un normale hosting CURIAWEB si dovrebbe inoltre controllare se il record SPF configurato automaticamente è ancora completamente presente.

Cosa fare in caso di dkim=fail? #

In caso di errore DKIM, si dovrebbe verificare quale sistema ha firmato il messaggio, quale selettore è stato utilizzato e se la relativa chiave pubblica è stata pubblicata correttamente nel DNS.

Se il dominio o la sua configurazione DNS sono stati trasferiti di recente a un altro provider, è opportuno verificare in particolare se i record DKIM necessari siano stati trasferiti completamente.

Cosa fare in caso di dmarc=fallito? #

Un errore DMARC non significa automaticamente che sia SPF che DKIM abbiano entrambi fallito completamente.

È fondamentale anche l'allineamento con il dominio del mittente visibile.

Ecco perché, in presenza di un problema DMARC, SPF, DKIM, il dominio From visivo e il servizio di invio effettivamente utilizzato dovrebbero essere esaminati insieme.

Prestare particolare attenzione dopo una migrazione DNS #

SPF, DKIM e DMARC si trovano nel DNS. Pertanto, se i name server di un dominio vengono modificati o la zona DNS viene trasferita a un altro provider, anche i record DNS necessari per l'invio di e-mail devono essere presenti correttamente.

Un sito web può funzionare senza problemi dopo un trasferimento DNS, mentre l'autenticazione delle e-mail risulta comunque errata.

Pertanto, dopo un trasferimento DNS, non controllare solo i record A, AAAA o MX, ma anche i record TXT rilevanti.

Errori tipici di SPF, DKIM e DMARC #

Errore	Possibile conseguenza
Record SPF automatico sovrascritto	Il server di posta CURIAWEB o altri sistemi legittimi potrebbero non essere più autorizzati correttamente.
Create più record SPF separati	L'SPF non può essere valutato correttamente.
Record DKIM dimenticato durante il trasferimento DNS	Le firme DKIM non possono più essere verificate correttamente.
Selettore DKIM non valido	Il destinatario non trova la chiave pubblica corrispondente alla firma.
DMARC troppo prematuramente su p=rifiuta posto	I messaggi legittimi ma non autenticati correttamente o inviati senza un corretto allineamento possono essere rifiutati.
Servizio di posta esterno aggiunto, ma DNS non modificato	SPF, DKIM o DMARC potrebbero non riuscire per i suoi messaggi.
Configurazione di SpamExperts confusa con l'hosting standard	L'aututenticazione potrebbe non corrispondere al percorso di spedizione effettivo.

Quando dovresti modificare autonomamente SPF, DKIM o DMARC? #

In una normale configurazione di hosting CURIAWEB, la risposta è solitamente: per niente.

Un adattamento manuale è necessario soprattutto quando cambia il percorso di spedizione o quando ulteriori sistemi devono inviare e-mail per conto del tuo dominio.

Prima di apportare qualsiasi modifica, bisogna quindi chiarire sempre prima:

1. Quali sistemi inviano effettivamente e-mail per il dominio?
2. Quale server di posta o servizio SMTP viene utilizzato?
3. Quali sono i requisiti SPF per questi sistemi?
4. Quale sistema firma con DKIM?
5. Quali selettori DKIM vengono utilizzati?
6. È soddisfatto l'allineamento richiesto per DMARC?
7. Quale policy DMARC è attualmente pubblicata?

Riepilogo #

SPF, DKIM e DMARC costituiscono insieme un'importante base per l'autenticazione delle e-mail.

Con un normale hosting CURIAWEB, i relativi record DNS vengono generalmente configurati automaticamente.

Il record SPF nella configurazione standard di CURIAWEB può ad esempio apparire così:

v=spf1 +a +mx +ip4:144.76.63.89 ~all

DKIM viene configurato automaticamente per il dominio e consente la firma crittografica e la verifica dei messaggi in uscita.

Il record DMARC creato per impostazione predefinita è:

v=DMARC1; p=none;

Fino a quando utilizzi esclusivamente la normale infrastruttura di posta CURIAWEB, normalmente non dovresti modificare queste impostazioni.

Un adattamento individuale diventa necessario in particolare quando sistemi esterni come servizi di newsletter, piattaforme CRM, Microsoft 365, servizi SMTP esterni o SpamExperts Outgoing Filtering inviano e-mail per conto del tuo dominio.

Ciò che conta è sempre il percorso di invio effettivo. Per questo motivo, SPF, DKIM e DMARC non dovrebbero essere configurati sulla base di valori di esempio generali, ma in modo adeguato all'infrastruttura di posta elettronica effettivamente utilizzata.