SPF contro DKIM: qual è la differenza e servono entrambi?

Introduzione

Molti errori SPF non sono causati da un record configurato in modo errato, ma dal fatto che l'e-mail è stata inoltrata.

Un amministratore IT configura correttamente l'SPF, verifica che il controllo abbia esito positivo e ritiene il lavoro concluso; poi un utente inoltra un messaggio tramite un relay di terze parti. Il server ricevente rileva un indirizzo IP che non figura nell'elenco autorizzato, il controllo fallisce, l'amministratore controlla il record e sembra tutto a posto. Il problema non è il record, ma il funzionamento dell'SPF.

L'SPF da solo non è sufficiente per l'autenticazione delle e-mail, e l'SPF e il DKIM non hanno lo stesso scopo. Ciascun protocollo protegge un livello diverso del processo di consegna delle e-mail. Se si elimina uno dei due, si creano delle lacune che sia l'infrastruttura di inoltro che gli hacker possono sfruttare, in modi diversi e per motivi diversi.

In questo blog scoprirai cosa distingue l'SPF dal DKIM, perché l'inoltro compromette il funzionamento dell'uno ma non dell'altro e perché entrambi sono necessari affinché il DMARC funzioni.

Che cos'è l'SPF e come funziona?

L'SPF (Sender Policy Framework) è un protocollo di autenticazione della posta elettronica che consente al proprietario di un dominio di specificare quali server di posta sono autorizzati a inviare messaggi per conto del dominio.

Il dominio pubblica un record SPF nel proprio DNS sotto forma di voce TXT che elenca gli indirizzi IP e i server approvati. Quando un server di posta ricevente riceve un messaggio, verifica il dominio del mittente confrontandolo con questo record pubblicato per confermare che il server mittente sia autorizzato. 

In base al risultato, il destinatario decide se accettare, segnalare o rifiutare il messaggio. L'SPF serve a impedire agli spammer e agli hacker di falsificare l'indirizzo del mittente, riducendo lo spoofing delle e-mail e il phishing. Funziona in combinazione con DKIM e DMARC per verificare la legittimità dei messaggi. 

Cosa controlla l'SPF

SPF verifica se il server che invia un messaggio è autorizzato a inviare posta per il dominio da cui dichiara di provenire. Ciò avviene nel momento in cui il server ricevente accetta la connessione in entrata, prima ancora di elaborare il corpo del messaggio.

Tuttavia, l'SPF non verifica l'indirizzo del mittente che i destinatari vedono effettivamente. Verifica solo il mittente della busta, noto anche come Return-Path o MAIL FROM, ovvero l'indirizzo utilizzato dietro le quinte durante la transazione SMTP. 

Pertanto, un malintenzionato può superare il controllo SPF sul dominio dell'involucro e comunque far apparire un indirizzo "Da" contraffatto nella posta in arrivo. DMARC contribuisce a colmare questa lacuna collegando il risultato del controllo SPF al dominio "Da" visibile.

Il server di ricezione accetta due input: 

1. L'indirizzo IP del mittente
2. Il dominio del mittente della busta

Quindi cerca il record SPF di quel dominio nel DNS. Segue in ordine i passaggi previsti dal record, come ad esempio ip4, ip6, a, mx, e include. Se l'IP mittente corrisponde a una fonte autorizzata, l'SPF viene superato. Se arriva fino al tag di chiusura tutti senza trovare una corrispondenza, il risultato dipende da come è stato configurato quel meccanismo.

SPF non restituisce un semplice sì o no. Restituisce uno dei seguenti risultati:

• Pass: Il server è autorizzato.
• Errore (-tutto): Non autorizzato. Vuoi che questa mail venga respinta.
• SoftFail (~tutti): Probabilmente non autorizzato. Accettalo, ma contrassegnalo come sospetto.
• Neutro (?tutti): Non stai affermando nulla in un senso o nell'altro.
• Nessuno: Non esiste alcun record SPF per il dominio.
• Errore permanente / Errore temporaneo: Il record è danneggiato oppure un problema DNS ha bloccato la ricerca.

Il server ricevente considera questo risultato come un ulteriore indicatore, insieme a DKIM e DMARC, per determinare la legittimità dell'e-mail prima che il messaggio venga consegnato, contrassegnato o respinto. 

Che cos'è il DKIM e come funziona?

DKIM (DomainKeys Identified Mail) è un protocollo di autenticazione della posta elettronica che appone una firma crittografica a ogni messaggio inviato da un dominio. Il server mittente firma il messaggio con una chiave privata e aggiunge la firma all'intestazione dell'e-mail. Il dominio pubblica la chiave pubblica corrispondente nel proprio DNS sotto forma di record TXT. 

Quando un server ricevente riceve il messaggio, recupera quella chiave pubblica e verifica la firma. Una firma valida conferma due cose: 

1. Il messaggio proviene effettivamente dal dominio indicato
2. Il contenuto non ha subito modifiche durante il trasporto. 

Il protocollo DKIM serve a prevenire la manomissione e la falsificazione del mittente e opera in combinazione con SPF e DMARC per verificare l'autenticità dei messaggi. 

Cosa firma DKIM

DKIM firma due parti di ogni messaggio: un insieme selezionato di campi dell'intestazione e il corpo del messaggio. Non firma l'involucro, l'IP di connessione né alcun altro elemento al di fuori di queste due aree. È questa la differenza fondamentale tra i due protocolli: SPF verifica l'involucro e il server mittente, mentre DKIM firma il messaggio stesso.

La firma non viene applicata al testo grezzo. Il server mittente calcola l'hash del corpo del messaggio e delle intestazioni selezionate, quindi crittografa tale hash con la propria chiave privata. Il risultato viene inserito nell'intestazione DKIM-Signature, che il server aggiunge al messaggio. All'interno di tale intestazione, alcuni tag indicano al destinatario esattamente cosa è stato firmato:

• h= elenca i campi dell'intestazione inclusi nella firma, come Da, A, Oggetto e Data.
• bh= contiene l'hash del corpo del messaggio.
• b= contiene la firma stessa, ovvero l'hash crittografato delle intestazioni firmate.
• c= imposta la canonicalizzazione, che determina il grado di corrispondenza richiesto per gli spazi bianchi e la formattazione.

L'intestazione "From" è sempre firmata. Il protocollo DKIM lo richiede, poiché lo scopo è quello di associare la firma al dominio che il destinatario vede effettivamente.

Tutto ciò che non è elencato in h= non è protetto. Se un'intestazione non è presente in tale elenco, può essere modificata durante il trasferimento senza compromettere la firma. Il corpo del messaggio è interamente protetto, a meno che il tag opzionale l= non limiti la firma alla sua prima parte; per questo motivo l'uso di l= è generalmente sconsigliato. Qualsiasi contenuto aggiunto dopo la lunghezza firmata verrebbe trasmesso senza firma.

Quando un server destinatario verifica il DKIM, ricalcola l'hash del corpo e l'hash dell'intestazione, decifra b= utilizzando la chiave pubblica pubblicata dall'utente e confronta i due valori. Se entrambi corrispondono, la firma è valida e le parti firmate del messaggio sono arrivate inalterate.

SPF contro DKIM

SPF e DKIM risolvono due problemi diversi. SPF autorizza i server autorizzati a inviare e-mail per conto del tuo dominio, mentre DKIM dimostra, tramite una firma crittografica, che un messaggio non è stato alterato e proviene effettivamente dal tuo dominio. Ecco una breve panoramica delle differenze tra SPF e DKIM.

Nessuno dei due protocolli sa cosa sa l'altro.

L'SPF può confermare che un messaggio provenga da un server autorizzato, ma una volta che il messaggio ha lasciato il server, l'SPF non è in grado di sapere cosa ne sia stato. 

Allo stesso modo, DKIM può confermare che il contenuto sia arrivato integro e che il dominio firmatario fosse in possesso della chiave privata, ma non dice nulla sul fatto che quel server fosse autorizzato a inviare il messaggio.

Ecco cosa significa quando un server ricevente valuta entrambi i risultati:

DMARC analizza entrambi i risultati e applica la politica pubblicata in base alla corrispondenza con il dominio . Ecco perché i due protocolli sono stati progettati per completarsi a vicenda, non per competere.

Perché l'SPF fallisce nell'inoltro mentre il DKIM no?

Il problema dell'inoltro SPF

SPF si interrompe quando un e-mail viene inoltrata. È uno dei motivi più comuni per cui un messaggio legittimo non supera il controllo SPF, e deriva direttamente dal funzionamento del protocollo.

SPF verifica se l'indirizzo IP del server che si connette corrisponde al record SPF del dominio del mittente dell'involucro. L'inoltro interrompe tale corrispondenza. Quando un server inoltra un messaggio, si verificano tre cose:

1. Il server di inoltro diventa il nuovo indirizzo IP di connessione.
2. Il mittente indicato sulla busta rimanda ancora al dominio del mittente originale.
3. Il record SPF del dominio originale non include il server di inoltro, quindi il controllo restituisce un errore.

Ad esempio, un messaggio proveniente dal tuo dominio supera il controllo SPF al primo hop. Il server del destinatario lo inoltra poi a un secondo indirizzo, come un account di ex studenti o una mailing list. In quella seconda destinazione, l'IP di connessione è ora quello del server di inoltro, ma il campo Return-Path continua a indicare il tuo dominio. Il tuo record SPF non ha mai autorizzato quel server, quindi il controllo SPF fallisce anche se il messaggio è autentico.

Questo si verifica più spesso nei seguenti casi:

• Mailing list
• Regole di inoltro automatico a livello di account in Gmail o Outlook
• Indirizzi di inoltro basati sugli ex studenti o sui ruoli
• Filtri antispam e gateway che inoltrano la posta

Ci sono due motivi per cui le e-mail inoltrate non vengono respinte:

1. SRS (Sender Rewriting Scheme): Il server di inoltro riscrive il campo Return-Path indicando il proprio dominio prima di inoltrare il messaggio. L'SPF verifica quindi il dominio del server di inoltro, che autorizza effettivamente quel server, quindi il controllo viene superato. La maggior parte dei servizi di inoltro affidabili applica l'SRS automaticamente.
2. DKIM e DMARC: Una firma DKIM rimane valida anche dopo l'inoltro, purché chi inoltra non modifichi il contenuto firmato. Pertanto, anche quando l'SPF non supera il controllo su un messaggio inoltrato, il DKIM può comunque superarlo, e il DMARC richiede che solo uno dei due sia conforme. Questo è il motivo principale per cui non dovresti fare affidamento esclusivamente sull'SPF.

Perché il DKIM resiste all'inoltro

Il DKIM non viene compromesso dall'inoltro perché firma il messaggio, non il percorso che questo compie. La firma è contenuta nell'intestazione DKIM-Signature, quindi accompagna l'e-mail in ogni fase del percorso. Indipendentemente dal numero di server che inoltrano il messaggio, la firma è ancora presente quando questo raggiunge la destinazione finale.

La verifica non dipende nemmeno dal server di connessione. Il destinatario recupera la chiave pubblica del dominio firmatario dal DNS di quel dominio e la utilizza per verificare la firma. L'indirizzo IP da cui è stato inviato il messaggio è irrilevante. Questo è l'opposto dell'SPF, che fallisce in caso di inoltro proprio perché verifica l'IP di connessione, mentre l'inoltro modifica tale IP.

Finché il server di inoltro inoltra il messaggio senza modificare il contenuto firmato, l'hash del corpo e quello dell'intestazione continuano a corrispondere e il controllo DKIM viene superato.

Il DKIM resiste all'inoltro semplice, ma non è immune a tutto. La firma viene compromessa quando un intermediario modifica il contenuto firmato. I casi più comuni sono le mailing list, che spesso:

• Aggiungere un piè di pagina o un link per annullare l'iscrizione al corpo del messaggio
• Aggiungi un tag del tipo [nome-elenco] nell'oggetto
• Riscrivere o inserire le intestazioni che si trovano all'interno della firma

Qualsiasi modifica di questo tipo altera l'hash e la firma non risulta più valida. ARC (Authenticated Received Chain) è stato creato proprio per questo caso, per preservare i risultati di autenticazione originali mentre un messaggio passa attraverso intermediari che lo modificano.

Ecco perché DKIM è importante per i messaggi inoltrati nell'ambito di DMARC. Il test DMARC viene superato se SPF o DKIM superano il test e sono allineati con il dominio "Da". Nei messaggi inoltrati, SPF solitamente fallisce, quindi è DKIM a garantire l'allineamento DMARC . Il dominio di firma rimane lo stesso durante l'inoltro, quindi l'allineamento rimane intatto. Affidarsi solo a SPF e alla posta inoltrata dal proprio dominio può far fallire il DMARC e far finire i messaggi nello spam.

Come interagiscono tra loro SPF, DKIM e DMARC?

SPF e DKIM risolvono ciascuno un problema diverso, ma nessuno dei due garantisce da solo la conformità. DMARC collega i risultati di entrambi a un'azione e ricollega entrambi i controlli al dominio che i destinatari vedono effettivamente.

Ecco cosa succede quando un server di ricezione analizza un messaggio in arrivo:

1. L'SPF viene eseguito per primo: Il server legge il mittente dell'involucro, il MAIL FROM scambiato durante la sessione SMTP, non l'intestazione From che vede il destinatario, e confronta l'IP mittente con il tuo record SPF. Se l'IP è autorizzato, l'SPF viene superato. In caso contrario, fallisce.
2. Successivamente viene eseguito DKIM: Il server legge il intestazione DKIM-Signature , cerca la tua chiave pubblica nel DNS utilizzando i tag selettore e dominio e verifica la firma crittografica rispetto al contenuto del messaggio. Una firma valida conferma che il messaggio proviene da un dominio che controlla la chiave privata e che non è stato alterato durante il transito.
3. DMARC viene valutato per ultimo: Recupera i dati della tua polizza e ne verifica la corrispondenza:
   1. Il dominio che ha superato il controllo SPF corrisponde al tuo dominio "Da"? 
   2. Il tag d= nella firma DKIM corrisponde al tuo dominio "Da"? 

Se uno dei due corrisponde, il test DMARC ha esito positivo. A quel punto, la politica pubblicata determina cosa succede al messaggio.

Cosa significa "allineamento" nella pratica

SPF può accettare qualsiasi dominio indicato nel mittente dell'involucro. DKIM può accettare qualsiasi dominio dotato di una chiave di firma valida. Nessuno dei due controlli, da solo, conferma l'intestazione "From", il campo che riporta [email protected] nella casella di posta del destinatario, sia legittimo. DMARC aggiunge tale verifica confrontando il dominio autenticato con il dominio "Da".

La funzione di allineamento funziona in due modalità:

1. In modalità "rilassata" (impostazione predefinita), è sufficiente che il dominio dell'organizzazione corrisponda, ovvero mail.tuaazienda.com corrisponde a yourcompany.com. 
2. In modalità rigorosa, i domini devono corrispondere esattamente. La maggior parte delle organizzazioni ricorre a un allineamento meno rigido, poiché la modalità rigorosa crea problemi di consegna per i sottodomini, a meno che ogni origine di invio non sia configurata con precisione.

I risultati relativi alla posta legittima rispetto a quella contraffatta

Per un messaggio legittimo configurato correttamente:

• L'IP mittente corrisponde al tuo record SPF → SPF superato
• La firma DKIM è valida, d= corrisponde al tuo dominio "Da" → DKIM superato
• Entrambi i risultati indicano che il dominio mittente supera il controllo DMARC
• Il tuo p=rifiuta → il messaggio viene consegnato

Per un messaggio contraffatto inviato da un server non autorizzato senza una chiave di firma valida:

• IP non autorizzato → Errore SPF
• Firma non valida → Errore DKIM
• Nessuno dei due risultati corrisponde al tuo dominio "Da" → Errore DMARC
• Il tuo p=rifiuta → il messaggio viene respinto prima di raggiungere qualsiasi casella di posta

Ecco perché l'uso combinato di SPF e DKIM risulta più efficace nell'ambito di DMARC rispetto all'utilizzo di uno solo dei due. DMARC può considerare validi entrambi i risultati, quindi quando SPF fallisce sui messaggi inoltrati, l'allineamento DKIM garantisce che DMARC continui a considerare validi i messaggi legittimi. Quando entrambi falliscono sui messaggi contraffatti, DMARC agisce in base alla politica definita.

Quando il tuo dominio raggiunge p=quarantena o p=reject con SPF e DKIM entrambi superati e allineati, avrai soddisfatto anche il prerequisito di applicazione per BIMI, lo standard che mostra il logo verificato del tuo marchio nelle caselle di posta compatibili come Gmail e Apple Mail.

Servono sia SPF che DKIM?

Sì, servono sia l'SPF che il DKIM. 

Un dominio che utilizza SPF senza DKIM non dispone di alcuna verifica dell'integrità a livello di messaggio. Non c'è modo di confermare che il contenuto non sia stato alterato durante il transito. Manca l'allineamento DKIM necessario per l'attuazione di DMARC, il che significa che se SPF fallisce (e fallirà, su qualsiasi email inoltrata), DMARC non ha alcuna soluzione di ripiego. Basta una sola regola di inoltro tra la casella di posta lavorativa di un utente e il suo account personale perché l'autenticazione venga compromessa su un'email che era del tutto legittima.

Google e Yahoo le hanno rese entrambe obbligatorie nel febbraio 2024.

Google richiede i record SPF, DKIM e DMARC per tutti i mittenti che inviano 5.000 o più messaggi al giorno. Yahoo richiede almeno uno tra SPF o DKIM più DMARC, anche se l'implementazione di uno solo comporta il mancato rispetto dei requisiti di Google. Se invii messaggi a destinatari su entrambe le piattaforme, configurare entrambi è l'unico modo per soddisfare tutti i requisiti contemporaneamente.

Anche al di sotto della soglia dei 5.000 messaggi, questi requisiti sono diventati di fatto lo standard di deliverability adottato dai principali provider di posta elettronica. 

Cosa offre l'uno che l'altro non offre:

Per come è stato progettato, in base alla RFC 7208, l'SPF non funziona correttamente con i messaggi inoltrati. L'IP del server di inoltro sostituisce quello originale; poiché quell'IP non è presente nell'elenco autorizzato, il controllo fallisce anche se non si è verificato alcun errore. Il DKIM, invece, non tiene conto dei cambiamenti di IP. La firma accompagna il messaggio e viene convalidata indipendentemente dai server attraverso cui è transitato, purché il contenuto non sia stato modificato.

Il DKIM conferma che il messaggio è integro e che il dominio firmatario controllava la chiave privata, ma non dice nulla sul fatto che il server che lo ha inviato disponesse dell'autorizzazione a livello di rete per farlo. Il controllo di questo aspetto è garantito dall'SPF.

Nessuno dei due sa cosa sa l'altro. Eseguendo entrambe le operazioni, il server di ricezione che esamina la tua e-mail avrà una visione completa, con percorso autorizzato e contenuto integro, anziché solo una parte.

Come configurare SPF e DKIM: guida passo passo

Se il tuo dominio non dispone ancora della configurazione SPF e DKIM, la procedura di configurazione è molto semplice. I passaggi riportati di seguito illustrano ciò che è necessario per configurare e verificare entrambi i protocolli. 

Passaggio 1: Crea il tuo record SPF

Inizia elencando tutti i servizi autorizzati a inviare e-mail dal tuo dominio, come:

1. Il tuo server di posta principale
2. Piattaforma di marketing
3. CRM
4. Strumento di assistenza
5. Fornitore di servizi di posta elettronica transazionale e qualsiasi altro servizio che invii messaggi per tuo conto.

Ogni servizio autorizzato riceve un include: un meccanismo nel record SPF, oppure un intervallo di IP diretto utilizzando ip4: o ip6:. Chiudere il record con -all per indicare ai server riceventi che qualsiasi IP non presente nell'elenco non è autorizzato.

Prima di aggiungere intervalli di indirizzi IP direttamente con ip4: o ip6:, assicurati che gli intervalli appartengano al servizio di invio corretto. La funzione di ricerca IP WHOIS di PowerDMARC ti permette di verificare la proprietà dell'IP prima che venga inserito nel tuo record. 

Un record SPF di base ha questo aspetto:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Tieni d'occhio il numero di ricerche DNS man mano che aggiungi servizi. La RFC 7208 limita la valutazione SPF a 10 ricerche. Ciascuna inclusione: consuma almeno una ricerca, e gli include annidati contano ai fini dello stesso limite. La maggior parte dei domini raggiunge il limite più rapidamente del previsto una volta che gestiscono quattro o cinque mittenti di terze parti contemporaneamente.

Usa il generatore gratuito di PowerDMARC Generatore SPF per creare il tuo record senza dover scrivere manualmente la sintassi, e PowerSPF per mantenerlo automaticamente al di sotto del limite massimo di 10 look-up man mano che la tua infrastruttura di invio cambia.

Passaggio 2: Genera e pubblica le tue chiavi DKIM

Per ogni servizio che effettua invii per tuo conto, è necessaria una coppia di chiavi DKIM: 

1. Una chiave privata che il server mittente utilizza per firmare la posta in uscita
2. Una chiave pubblica corrispondente pubblicata nel tuo DNS affinché i server riceventi possano effettuare la verifica.

Se un servizio come Google Workspace o Microsoft 365 gestisce la firma DKIM, fornisce il record della chiave pubblica e il nome del selettore. Pubblica il record nel DNS all'indirizzo selector._domainkey.tuodominio.com e abilita la firma nella console di amministrazione del servizio.

Negli ambienti in cui si generano autonomamente le chiavi, utilizzare almeno RSA a 2048 bit; quella a 1024 bit non è più considerata adeguata. Il generatore gratuito di DKIM di PowerDMARC generatore DKIM gratuito genera un record DNS pronto per la pubblicazione senza richiedere strumenti da riga di comando.

Se gestisci il DKIM su più servizi di invio, Hosted DKIM gestisce la generazione delle chiavi, la pubblicazione DNS e la rotazione da un unico punto, senza modifiche manuali al DNS ogni volta che è necessario cambiare una chiave.

Passaggio 3: Aggiungere un record DMARC

Una volta configurati SPF e DKIM, aggiungi un record DMARC al tuo DNS. Inizia da p=none per raccogliere dati di reportistica aggregati senza influire sulla consegna della posta.

Un record minimo iniziale:

v=DMARC1; p=none; rua=mailto:[email protected];

p=none non blocca i messaggi contraffatti. Imposta DMARC in modalità di monitoraggio, quindi riceverai rapporti aggregati che mostrano quali fonti superano e quali falliscono l'autenticazione, ma nessuna e-mail verrà messa in quarantena o respinta. 

Utilizza questi dati per individuare eventuali configurazioni errate e problemi di allineamento, quindi passa a messa in quarantena e infine p=reject.

Un dominio situato all'indirizzo p=none a tempo indeterminato non è protetto dallo spoofing. La fase di monitoraggio richiede un endpoint definito, non una tempistica aperta.

Passaggio 4: Verifica la configurazione

Dopo aver pubblicato i tuoi record, verifica che ciascuno di essi funzioni correttamente prima di considerare completata la configurazione.

Sebbene sia necessario che i record vengano risolti correttamente, ciò non è di per sé sufficiente. Effettua un test in tempo reale per verificare che le intestazioni di autenticazione vengano trasmesse dall'inizio alla fine. Lo strumento di test SMTP di PowerDMARC ti permette di testare la connessione del tuo server di posta e verificare che SPF, DKIM e DMARC passino sulla posta in uscita effettiva, non solo nel DNS. 

Errori comuni

I due errori più comuni che causano errori di autenticazione in produzione sono: 

Limite di ricerca SPF 10

L'SPF consente un massimo di 10 ricerche DNS quando un server ricevente valuta il tuo record, un limite stabilito dalla RFC 7208. Meccanismi come include, a e mx attivano ciascuno una ricerca e sono nidificati. 

La maggior parte dei domini supera il limite di 10 accumulando mittenti di terze parti, poiché ogni servizio che si autorizza tramite un’inclusione consuma delle ricerche. Una volta superato il limite, l’SPF restituisce un PermErrore i server di ricezione lo trattano come un record danneggiato che non autorizza più la tua posta. 

Appiattimento risolve il problema sostituendo i tuoi meccanismi di inclusione con gli intervalli IPv4 e IPv6 effettivi a cui risolvono, riducendo il numero di ricerche a zero.

Rotazione delle chiavi DKIM

La rotazione delle chiavi DKIM consiste nel sostituire periodicamente la coppia di chiavi DKIM, ritirando la vecchia chiave privata di firma e pubblicando al suo posto una nuova chiave pubblica. La rotazione limita il periodo di esposizione di ogni singola chiave, quindi, qualora una chiave venisse compromessa, il danno risulterebbe circoscritto. La maggior parte dei team effettua la rotazione ogni trimestre o due volte all'anno, mentre alcuni provider eseguono la rotazione delle proprie chiavi in modo automatico.

La maggior parte degli errori di rotazione deriva dalle operazioni relative allo swap. Ecco cosa sfugge più spesso agli amministratori.

Rimuovere la vecchia chiave pubblica troppo presto

I messaggi già in transito sono stati firmati con la vecchia chiave e il destinatario ha bisogno della chiave pubblica corrispondente nel DNS per verificarli. Elimina il vecchio record non appena effettui il passaggio; in tal caso, i messaggi in transito non supereranno il controllo DKIM. Mantieni la vecchia chiave pubblicata per un periodo di sovrapposizione fino a quando tutti i messaggi firmati con essa non saranno stati elaborati.

Riutilizzo dello stesso selettore

Ruota i selettori, non sovrascriverne uno. Pubblica la nuova chiave sotto un nuovo selettore, sposta la firma su di esso, quindi disattiva il vecchio selettore dopo il periodo di sovrapposizione. Sovrascrivere il record di un singolo selettore crea un vuoto in cui la posta firmata con la vecchia chiave non può più essere convalidata.

Effettuare il cambio prima che il DNS si propaghi

Se esegui il flip-sign con la nuova chiave prima che nuova chiave pubblica si sia propagata, i destinatari non riusciranno a trovarla e DKIM fallirà. Pubblica prima il nuovo record, attendi che scada il TTL del record, poi trasferisci la firma.

Esclusione dei mittenti di terze parti

Ogni servizio di invio, come il tuo ESP o CRM, gestisce le proprie chiavi e i propri selettori DKIM. La rotazione della chiave del dominio principale non influisce su questi elementi. Effettua la rotazione delle chiavi di ciascun servizio separatamente oppure verifica che sia il provider a occuparsene per te.

Divisione errata di un record a 2048 bit

Una chiave pubblica a 2048 bit, che rappresenta lo standard attuale e a cui vale la pena passare se si utilizza ancora quella a 1024 bit, spesso supera il limite di 255 caratteri di una singola stringa TXT DNS e deve essere suddivisa in più stringhe racchiuse tra virgolette. Una suddivisione errata compromette il record e la chiave non risulterà valida, anche se apparentemente è presente.

Rotazione senza monitoraggio

I rapporti aggregati DMARC consentono di verificare che la nuova chiave sia valida. Senza di essi, una rotazione non riuscita viene interpretata come un calo della deliverability anziché come un avviso. Controlla i rapporti dopo ogni rotazione.

Entrambi gli errori derivano da record che cambiano più rapidamente di quanto sia possibile aggiornarli manualmente. PowerDMARC mantiene il tuo SPF semplificato al di sotto del limite di 10 ricerche e le tue chiavi DKIM a rotazione regolare, avvisandoti nel momento in cui qualcosa si interrompe, prima che ciò comprometta la tua deliverability.

Inizia la tua prova gratuita per scoprire qual è lo stato attuale del tuo dominio.

Domande frequenti

Il DKIM sostituisce l'SPF?

No. Il DKIM verifica l'integrità del messaggio tramite una firma crittografica, ma non conferma che il server mittente fosse autorizzato. È l'SPF a occuparsi di tale verifica, pertanto entrambi sono necessari per garantire una copertura completa. 

Perché la mia e-mail non supera il controllo SPF dopo l'inoltro?

SPF verifica l'IP del server mittente confrontandolo con l'elenco autorizzato, mentre l'inoltro sostituisce l'IP originale con quello del server di inoltro, che non figura nel registro. Si tratta di un comportamento previsto dalla RFC 7208, e DKIM è progettato per gestirlo poiché convalida il contenuto, non il percorso. 

Cos'è più importante: l'SPF o il DKIM?

Nessuna delle due. SPF esegue l'autorizzazione a livello di server, DKIM effettua la verifica a livello di messaggio ed entrambi sono necessari per un allineamento DMARC affidabile. Disporre di entrambi consente alla posta di passare comunque anche se uno dei due fallisce durante l'inoltro. 

Quanti selettori DKIM posso avere?

Non ci sono limiti. Pubblicane quanti ne servono, in genere uno per ogni servizio di invio o ciclo di rotazione delle chiavi. Ciascuno di essi è un record TXT DNS separato all'indirizzo selector._domainkey.yourdomain.com. 

Cosa succede se ho solo l'SPF ma non il DKIM?

Si perde l'integrità a livello di messaggio e non si dispone di un sistema di fallback per l'allineamento DKIM, quindi DMARC può fallire su messaggi inoltrati legittimi quando SPF non funziona correttamente. Anche le regole di Google per i mittenti di massa impongono l'uso di DKIM, il che rende i mittenti con volumi elevati non conformi.