Configurare SPF and DKIM su Postfix: differenze tra le versioni

Migliorata spiegazione per il multidominio
(Migliorata spiegazione per il multidominio)
 
(2 versioni intermedie di uno stesso utente non sono mostrate)
Riga 1: Riga 1:
{{Stub}}
{{Versioni compatibili|bullseye}}
{{Versioni compatibili|bullseye}}
==Introduzione==
==Introduzione==
Riga 9: Riga 8:


===Cosa è DMARC (Domain Message Authentication, Reporting and Conformance)?===
===Cosa è DMARC (Domain Message Authentication, Reporting and Conformance)?===
DMARC (Domain Message Authentication, Reporting & Conformance) permette di avvisare i mail server delle politiche del tuo nominio. Le politiche riguardano le mail che falliscono la validazione SPF o DKIM. Inoltre permette di richiedere un responso in caso di fallimento della varifica dai mail server riceventi.
DMARC (Domain Message Authentication, Reporting & Conformance) permette di avvisare i mail server delle politiche del tuo dominio. Le politiche riguardano le mail che falliscono la validazione SPF o DKIM. Inoltre permette di richiedere un responso in caso di fallimento della verifica del mittente da parte del mail server ricevente.


Le istruzioni che permettono di settare SPF, DKIM e DMARC sono generiche. Le istruzioni per configurare le politiche SPF e OpenDKIM in Postfix funzionano su ogni distribuzione. È solo necessario fare piccoli aggiustimenti di codice per il gestore dei pacchetti e identificare il percorso esatto del socket Unix.
Le istruzioni che permettono di settare SPF, DKIM e DMARC sono generiche. Le istruzioni per configurare le politiche SPF e OpenDKIM in Postfix funzionano su ogni distribuzione. È solo necessario fare piccoli aggiustamenti di codice per il gestore dei pacchetti e identificare il percorso esatto del Socket Unix.


{{Suggerimento | I passi richiesti in questa guida richiedono i permessi di root. Assicurati di eseguire i passi successivi come root o con il prefisso sudo.}}
{{Suggerimento | I passi richiesti in questa guida richiedono i permessi di root. Assicurati di eseguire i passi successivi come root o con il prefisso sudo.}}
Riga 23: Riga 22:


Il valore di un record DNS per SPF deve essere simile ai seguenti esempi. Per la sintassi completa vedere <ref>[http://www.open-spf.org/Specifications open-spf pagina delle specifiche]</ref>
Il valore di un record DNS per SPF deve essere simile ai seguenti esempi. Per la sintassi completa vedere <ref>[http://www.open-spf.org/Specifications open-spf pagina delle specifiche]</ref>
Add SPF records to DNS


;Esempio 1:Permette le mail da tutti gli host elencati nel record MX del dominio:
;Esempio 1:Permette le mail da tutti gli host elencati nel record MX del dominio:
Riga 50: Riga 48:
L'agente Python per SPF aggiunge il controllo politiche SPF a Postfix. Il record SPF del dominio di chi spedisce le mail in ingresso è verificato e, se esiste, la mail è trattata in rsipetto delle politiche. Ne esiste anche una versione in Perl, ma è carente di tutte le caratteristiche dell'agente policy scritto in Python.
L'agente Python per SPF aggiunge il controllo politiche SPF a Postfix. Il record SPF del dominio di chi spedisce le mail in ingresso è verificato e, se esiste, la mail è trattata in rsipetto delle politiche. Ne esiste anche una versione in Perl, ma è carente di tutte le caratteristiche dell'agente policy scritto in Python.


Se utilizzi SpamAssassin per filtrare la spam, potresti voler modificare il file <code>/etc/postfix-policyd-spf-python/policyd-spf.conf</code> per cambiare la configurazioen <code>HELO_reject</code> e <code>Mail_From_reject</code> a <code>False</code>. Questa modifica fa sì che l'agente per le politiche SPF, dopo aver effettuato i propri test, aggiunge una intestazione (header) al messaggio con il risultato dell'analisi e non rifiuta alcun messaggio. Inoltre si potrebbe fare questa modifica anche per vedere i risultati dell'analisi senza applicarle. In caso contrario lasciare le configurazioni di default.
Se utilizzi SpamAssassin per filtrare la spam, potresti voler modificare il file <code>/etc/postfix-policyd-spf-python/policyd-spf.conf</code> per cambiare la configurazione <code>HELO_reject</code> e <code>Mail_From_reject</code> a <code>False</code>. Questa modifica fa sì che l'agente per le politiche SPF, dopo aver effettuato i propri test, aggiunge una intestazione (header) al messaggio con il risultato dell'analisi e non rifiuta alcun messaggio. Inoltre si potrebbe fare questa modifica anche per vedere i risultati dell'analisi senza applicarle. In caso contrario lasciare le configurazioni di default.


Modificare il file <code>/etc/postfix/master.cf</code> ed aggiungere le seguenti righe alla fine:
Modificare il file <code>/etc/postfix/master.cf</code> ed aggiungere le seguenti righe alla fine:
Riga 66: Riga 64:
     ...</pre>
     ...</pre>


Assicurarsi di aggiungere il parametro <code>check_policy_service</code> dopo <code>reject_unauth_destination</code> per evitare che il sistemi si comporti come un open relay. Se <code>reject_unauth_destination</code> è l'ultimo elemento della lista, aggiugnere una virgola <code>,</code> subito dopo e infine aggiugnere l'opzione per <code>check_policy_service</code> come sopra.
Assicurarsi di aggiungere il parametro <code>check_policy_service</code> dopo <code>reject_unauth_destination</code> per evitare che il sistemi si comporti come un open relay. Se <code>reject_unauth_destination</code> è l'ultimo elemento della lista, aggiungere una virgola <code>,</code> subito dopo e infine aggiungere l'opzione per <code>check_policy_service</code> come sopra.


Infine riavviare Postfix
Infine riavviare Postfix
Riga 78: Riga 76:
Questi header non appaiono nelle mail in uscita o locali.
Questi header non appaiono nelle mail in uscita o locali.


L'agente politiche SPF inoltre scrive log in <code>/var/log/mail.log</code>. Nel file <code>mail.log</code> si pososno vedere anche messaggi del tipo:
L'agente politiche SPF inoltre scrive log in <code>/var/log/mail.log</code>. Nel file <code>mail.log</code> si possono vedere anche messaggi del tipo:


<pre>Nov  1 17:25:23 hostname policyd-spf[21065]: None; identity=helo; client-ip=127.0.0.1; helo=mail.example.com; envelope-from=test@example.com; receiver=me@otherdomain.org
<pre>Nov  1 17:25:23 hostname policyd-spf[21065]: None; identity=helo; client-ip=127.0.0.1; helo=mail.example.com; envelope-from=test@example.com; receiver=me@otherdomain.org
Riga 96: Riga 94:
  chown opendkim: /var/spool/postfix/opendkim
  chown opendkim: /var/spool/postfix/opendkim


===Configurazione opendkim===
===Configurazione OpenDKIM===
Passiamo ora alla configurazione di opendkim. La configurazione possiamo farla in due modi differenti: una modalità semplificata, adatta a gestire un singolo dominio, o una modalità più complessa, dove andremo a creare più file di configurazione, adatta alla gestione multi dominio. Potete scegliere quella più adatta alle vostre esigenze.
Passiamo ora alla configurazione di OpenDKIM. La configurazione possiamo farla in due modi differenti: una modalità semplificata, adatta a gestire un singolo dominio, o una modalità più complessa, dove andremo a creare più file di configurazione, adatta alla gestione multi dominio. Potete scegliere quella più adatta alle vostre esigenze.


====Semplificata: dominio singolo====
====Semplificata: dominio singolo====
Riga 105: Riga 103:
Selector                2021
Selector                2021
KeyFile        /etc/dkimkeys/2021.private</pre>
KeyFile        /etc/dkimkeys/2021.private</pre>
Ed al posto di 2021 inserire l'anno corrente.
Ed al posto di 2022 inserire l'anno corrente.


Più in basso, sempre nello stesso file attivare
Più in basso, sempre nello stesso file attivare
Riga 111: Riga 109:
ed assicurarsi che non ci siano altre righe relative a <code>Socket</code> non commentate.
ed assicurarsi che non ci siano altre righe relative a <code>Socket</code> non commentate.


Creiamo le chiavi crittografiche per Opendkim con
Creiamo le chiavi crittografiche per OpenDKIM con
  sudo -u opendkim opendkim-genkey -D /etc/dkimkeys -d mail.example.com -s 2021
  sudo -u opendkim opendkim-genkey -D /etc/dkimkeys -d mail.example.com -s 2022
In questo caso la chiave privata si troverà in <code>/etc/dkimkeys/2021.private</code> e quella pubblica in <code>/etc/dkimkeys/2021.txt</code>
In questo caso la chiave privata si troverà in <code>/etc/dkimkeys/2022.private</code> e quella pubblica in <code>/etc/dkimkeys/2022.txt</code>


====Completa: multi-dominio====
====Completa: multi-dominio====
Aprire il file <code>/etc/opendkim.conf</code> e modificare i parametri
Aprire il file <code>/etc/opendkim.conf</code> e aggiungere i parametri
<pre># Specify the list of keys
<pre># Specify the list of keys
KeyTable file:/etc/dkimkeys/keytable
KeyTable file:/etc/dkimkeys/keytable
Riga 126: Riga 124:
InternalHosts refile:/etc/dkimkeys/trustedhosts</pre>
InternalHosts refile:/etc/dkimkeys/trustedhosts</pre>


Ora creare i file per la lista delle chiavi, la corrispondenza tra chiavi e domini e la lista degli host per i quali i messaggi saranno firmati.
Più in basso, sempre nello stesso file attivare
<pre>Socket                  local:/var/spool/postfix/opendkim/opendkim.sock</pre>ed assicurarsi che non ci siano altre righe relative a <code>Socket</code> non commentate.Ora creare i file per la lista delle chiavi, la corrispondenza tra chiavi e domini e la lista degli host per i quali i messaggi saranno firmati.
  sudo -u opendkim touch /etc/dkimkeys/keytable /etc/dkimkeys/signingtable /etc/dkimkeys/trustedhosts
  sudo -u opendkim touch /etc/dkimkeys/keytable /etc/dkimkeys/signingtable /etc/dkimkeys/trustedhosts
Aprire il file <code>/etc/dkimkeys/keytable</code> ed aggiungere le informazioni sulle chiavi private con il seguente schema (uno per riga):
Aprire il file <code>/etc/dkimkeys/keytable</code> ed aggiungere le informazioni sulle chiavi private con il seguente schema (uno per riga):
  shortname yourdomain.org:mail:/etc/dkimkeys/mykey.private
  shortname yourdomain.org:selector:/etc/dkimkeys/mykey.private
 
Dove <code>shortname</code> è un nome breve per ricordarsi il dominio, mentre <code>selector</code> è il selettore per la chiave (esempio l'anno in corso, come <code>2022</code>).


Nel file <code>/etc/dkimkeys/signingtable</code>, specificare quale chiave firmerà quale dominio, qui un esempio:
Nel file <code>/etc/dkimkeys/signingtable</code>, specificare quale chiave firmerà quale dominio, qui un esempio:
Riga 143: Riga 144:
localhost
localhost
myhostname
myhostname
yourdomain.org</pre>
*yourdomain.org</pre>


In questo caso cambiare myhostname al name del proprio server ed yourdomain.org con il nome del dominio.
In questo caso cambiare myhostname con quello del proprio server e yourdomain.org con il nome del dominio (l'asterisco iniziale può essere omesso se non si vogliono includere tutti i sotto-domini).


Per ciascun dominio creiamo le chiavi crittografiche eseguendo il seguente comando, cambiando di volta in volta il selector (opzione -s scegliendo quello che desideriamo, è comune utilizzare l'anno di generazione) ed eventualmente rinominando le chiavi generate in /etc/dkimkeys per capire a quali domini si riferiscono
Per ciascun dominio creiamo le chiavi crittografiche eseguendo il seguente comando, cambiando di volta in volta il selector (opzione -s scegliendo quello che desideriamo, è comune utilizzare l'anno di generazione) ed eventualmente rinominando le chiavi generate in /etc/dkimkeys per capire a quali domini si riferiscono
  sudo -u opendkim opendkim-genkey -D /etc/dkimkeys -d yourdomain.org -s 2021
  sudo -u opendkim opendkim-genkey -D /etc/dkimkeys -d yourdomain.org -s 2022
In ogni caso, dopo la generazione ci si troverà la chiave privata si troverà in <code>/etc/dkimkeys/2021.private</code> e quella pubblica in <code>/etc/dkimkeys/2021.txt</code>
In ogni caso, dopo la generazione ci si troverà la chiave privata si troverà in <code>/etc/dkimkeys/2022.private</code> e quella pubblica in <code>/etc/dkimkeys/2022.txt</code>
In questo caso, avendo specificato che le chiavi si trovano in <code>/etc/dkimkeys/mykey.private</code> è necessario rinominarle con <code>mv</code> per rispettare il nome corretto.
In questo caso, avendo specificato che le chiavi si trovano in <code>/etc/dkimkeys/mykey.private</code> è necessario rinominarle con <code>mv</code> per rispettare il nome corretto.


Riga 162: Riga 163:
  systemctl restart postfix
  systemctl restart postfix


====Configurazione aggintiva====
====Configurazione aggiuntiva====
Il parametro <code>milter_default_action</code> determina cosa fare quando un milter fallisce. Per esempio nel caso in cui non risponda perché è andato in crash. Al fine di non perdere email sarebbe bene aggiungere la seguente riga:
Il parametro <code>milter_default_action</code> determina cosa fare quando un milter fallisce. Per esempio nel caso in cui non risponda perché è andato in crash. Al fine di non perdere email sarebbe bene aggiungere la seguente riga:
  milter_default_action = accept
  milter_default_action = accept


Postfix non passa messaggi generati internamente, come messaggi di bounce a opendkim, così, di base, i meessaggi di bounce non sono firmati con DKIM. Questo pul essere un problema se si utilizzano politiche DMARC strette (così come la riga di sopra). Infatti questo comporterebbe che i messaggi non firmati con DKIM verrebbero rifiutati. Il parametro <code>internal_mail_filter_classes</code> può essere usato epr fare sì che anche i messaggi di  bounces passino attraverso i milters come segue:
Postfix non passa messaggi generati internamente, come messaggi di bounce a OpenDKIM, così, di base, i messaggi di bounce non sono firmati con DKIM. Questo può essere un problema se si utilizzano politiche DMARC strette (così come la riga di sopra). Infatti questo comporterebbe che i messaggi non firmati con DKIM verrebbero rifiutati. Il parametro <code>internal_mail_filter_classes</code> può essere usato epr fare sì che anche i messaggi di  bounces passino attraverso i milters come segue:
  internal_mail_filter_classes = bounce
  internal_mail_filter_classes = bounce


Riga 172: Riga 173:
Le prima cosa da fare è aprire il file contenente la chiave pubblica precedentemente generata. Ricordo essere nella directory <code>/etc/dkimkeys/</code> ed ha estensione <code>.txt</code>.
Le prima cosa da fare è aprire il file contenente la chiave pubblica precedentemente generata. Ricordo essere nella directory <code>/etc/dkimkeys/</code> ed ha estensione <code>.txt</code>.
Il file avrà un aspetto di questo tipo
Il file avrà un aspetto di questo tipo
<pre>2021._domainkey IN TXT ( "v=DKIM1; h=sha256; k=rsa; "
<pre>2022._domainkey IN TXT ( "v=DKIM1; h=sha256; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzNujEZuDXhwTXrqyw4lvOlTfvevftY1bbKTKSiUXLTnT21fJ3y38DB88LFwW4XOtHq6hgx/bezivKuqa3Nvm5vn2S48aVDSKEM173KG20N/gapBvW3C0AVq607ds5TaeO3Wg5bBIZXSwJBboJaaJbNUMLJD31l25wkU+WD2gX2K32OSpJflXXPD5tWZIQPVQpM9q9ekoKxuUYD"
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzNujEZuDXhwTXrqyw4lvOlTfvevftY1bbKTKSiUXLTnT21fJ3y38DB88LFwW4XOtHq6hgx/bezivKuqa3Nvm5vn2S48aVDSKEM173KG20N/gapBvW3C0AVq607ds5TaeO3Wg5bBIZXSwJBboJaaJbNUMLJD31l25wkU+WD2gX2K32OSpJflXXPD5tWZIQPVQpM9q9ekoKxuUYD"
  "UFsrBj4u/OfmqO1hDRaJYLHRYKmDuw7UibnDEFlgQsczL6E9e7q5BjyVDC3pFvsM7jQatQVgYo+Ml3vBt4idoFwpTCt1MzE7bNMh/wwLni6/PKZXGGdjxoHqsp2o0UBXaXXZwfKwIDAQAB" )  ; ----- DKIM key a for yourdomain.org</pre>
  "UFsrBj4u/OfmqO1hDRaJYLHRYKmDuw7UibnDEFlgQsczL6E9e7q5BjyVDC3pFvsM7jQatQVgYo+Ml3vBt4idoFwpTCt1MzE7bNMh/wwLni6/PKZXGGdjxoHqsp2o0UBXaXXZwfKwIDAQAB" )  ; ----- DKIM key a for yourdomain.org</pre>
Quello che dobbiamo fare è, dal gestore del nostro DNS creare un nuovo record di tipo TXT, dare il nome che troviamo, cioè nel caso mostrato <code>2021._domainkey</code> dove al posto del <code>2021</code> troverete il nome che avete passato a <code>-s</code> al momento della generazione della chiave, cioè il selector.
Quello che dobbiamo fare è, dal gestore del nostro DNS creare un nuovo record di tipo TXT, dare il nome che troviamo, cioè nel caso mostrato <code>2022._domainkey</code> dove al posto del <code>2022</code> troverete il nome che avete passato a <code>-s</code> al momento della generazione della chiave, cioè il selector.


Nel campo inserire la seconda parte, ricordandosi di rimuovere i doppi apici <code>"</code> e gli accapo trovati. Cioè nel caso di esempio precedente dovremo inserire
Nel campo inserire la seconda parte, ricordandosi di rimuovere i doppi apici <code>"</code> e gli accapo trovati. Cioè nel caso di esempio precedente dovremo inserire
Riga 182: Riga 183:
===Test della configurazione===
===Test della configurazione===
Per testare la corretta firma e verifica delle chiavi si può utilizzare il comando <code>opendkim-testkey</code> nel seguente modo:
Per testare la corretta firma e verifica delle chiavi si può utilizzare il comando <code>opendkim-testkey</code> nel seguente modo:
  opendkim-testkey -d yourdomain.org -s 2021
  opendkim-testkey -d yourdomain.org -s 2022
Ricordandosi di sostituire a <code>yourdomain.org</code> il proprio dominio e a <code>2021</code> il selector impostato.
Ricordandosi di sostituire a <code>yourdomain.org</code> il proprio dominio e a <code>2022</code> il selector impostato.


Se tutto è andato per il verso giusto non dovresti ottnere alcun output. Se vuoi vedere più informazioni aggiungi l'argomento <code>-vvv</code> alal fine del comando. La procedura mostrerà l'output di debug. L'ultimo messaggio dovrebbe essere <code>key OK</code>. Appena prima si può vedere il messaggio <code>key not secure</code>. È normale e non è un messaggio di errore. Significa semplicemente che il dominio non è configurato per DNSSEC. In caso sia supportato DNSSEC (per esempio usando google DNS) si troverà <code>key secure</code>.
Se tutto è andato per il verso giusto non dovresti ottnere alcun output. Se vuoi vedere più informazioni aggiungi l'argomento <code>-vvv</code> alal fine del comando. La procedura mostrerà l'output di debug. L'ultimo messaggio dovrebbe essere <code>key OK</code>. Appena prima si può vedere il messaggio <code>key not secure</code>. È normale e non è un messaggio di errore. Significa semplicemente che il dominio non è configurato per DNSSEC. In caso sia supportato DNSSEC (per esempio usando google DNS) si troverà <code>key secure</code>.
Riga 191: Riga 192:
Il record DNS DMARC può essere aggiunto per avvisare i mail server su cosa fare con le email che rivendicano la provenienza dal tuo dominio nel caso falliscano la validazione SPF o DKIM. DMARC inoltre ti permette di essere avvisato sulle email che falliscono una o più controlli di validazione.
Il record DNS DMARC può essere aggiunto per avvisare i mail server su cosa fare con le email che rivendicano la provenienza dal tuo dominio nel caso falliscano la validazione SPF o DKIM. DMARC inoltre ti permette di essere avvisato sulle email che falliscono una o più controlli di validazione.


DMARC va configurato solo se si è configurato sia SPF che DKIM ed è stato verificato il corretto funzionamento. Nel caso si aggiunga un record DNS DMARC senza avere configurato correttamente sia SPF che DKIM, i messaggi provenienti dal tuo dominio falliranno la validazion e, pertanto, saranno scartati o marcati come SPAM dal server ricevente.
DMARC va configurato solo se si è configurato sia SPF che DKIM ed è stato verificato il corretto funzionamento. Nel caso si aggiunga un record DNS DMARC senza avere configurato correttamente sia SPF che DKIM, i messaggi provenienti dal tuo dominio falliranno la validazione, pertanto, saranno scartati o marcati come SPAM dal server ricevente.


Il record DMARC è un record TXT per l'host <code>_dmarc</code> nel dominio contenente i seguenti valori raccomandati:
Il record DMARC è un record TXT per l'host <code>_dmarc</code> nel dominio contenente i seguenti valori raccomandati:
  v=DMARC1;p=quarantine;sp=quarantine;adkim=r;aspf=r
  v=DMARC1;p=quarantine;sp=quarantine;adkim=r;aspf=r
Questa stringa richiede al mail server di inserire in quarantena (non eliminare, ma separare dai messaggi normali) ongi email che fallisce il controllo SPF o il DKIM. Nessun report è richiesto. In ogni caso, veramente pochi mail server implementano il software per generare report sui messaggi che falliscono la validazione, pertanto è spesso inutile richiedere il report.
Questa stringa richiede al mail server di inserire in quarantena (non eliminare, ma separare dai messaggi normali) ogni email che fallisce il controllo SPF o il DKIM. Nessun report è richiesto. In ogni caso, veramente pochi mail server implementano il software per generare report sui messaggi che falliscono la validazione, pertanto è spesso inutile richiedere il report.


Nel caso comunque tu voglia richiedere un resoconto, nel caso di mancata validazione, bisogna inserire una stringa simile alla seguente
Nel caso comunque tu voglia richiedere un resoconto, nel caso di mancata validazione, bisogna inserire una stringa simile alla seguente
Riga 233: Riga 234:
Si premette che le chiavi DKIM non hanno scadenza, pertanto è tecnicamente possibile non cambiarle mai. Però è consigliato la creazione e la revoca di nuove chiavi almeno una volta l'anno<ref>[https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/configure-anti-spoofing-controls-/create-and-manage-a-dkim-record UK National Cyber Secyrity Center: Creation and managin of DKIM record ]</ref>
Si premette che le chiavi DKIM non hanno scadenza, pertanto è tecnicamente possibile non cambiarle mai. Però è consigliato la creazione e la revoca di nuove chiavi almeno una volta l'anno<ref>[https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/configure-anti-spoofing-controls-/create-and-manage-a-dkim-record UK National Cyber Secyrity Center: Creation and managin of DKIM record ]</ref>


La procedura da eseguire è veramente semplice. Si genera una nuova coppia di chiavi (pubblica e privata) come nel passo per configurare [[#Completa:_multi-dominio|opendkim in modalità multi-dominio]] ed aggiornare il selector nel file di configurazione <code>keytable</code> che elenca le chiavi (per esempio da 2021 passare a 2022).
La procedura da eseguire è veramente semplice. Si genera una nuova coppia di chiavi (pubblica e privata) come nel passo per configurare [[#Completa:_multi-dominio|OpenDKIM in modalità multi-dominio]] ed aggiornare il selector nel file di configurazione <code>keytable</code> che elenca le chiavi (per esempio da 2022 passare a 2023).


Utilizzare il nuovo file .txt generato per aggiungere la nuova chiave al record DNS con il nuovo selector. Si ricorda di non rimuovere o modificare il record DKIM pre-esistente. Testare nuovamente la chiave (con il nuovo selector) sempre con il comando <code>opendkim-testkey</code>.
Utilizzare il nuovo file .txt generato per aggiungere la nuova chiave al record DNS con il nuovo selector. Si ricorda di non rimuovere o modificare il record DKIM pre-esistente. Testare nuovamente la chiave (con il nuovo selector) sempre con il comando <code>opendkim-testkey</code>.