Record DNS di sicurezza: guida completa per dominio ed email
Quando si configura un dominio, di solito si parte dai record necessari al funzionamento del sito e della posta elettronica. Si impostano A, AAAA, CNAME e MX, si controlla che tutto risponda e spesso ci si ferma lì.
Nella zona DNS possono però entrare in gioco anche altri record, meno visibili ma importanti per la sicurezza del dominio, la protezione delle email e l’affidabilità delle comunicazioni. Non servono necessariamente a rendere operativo un servizio, ma permettono di stabilire quali sistemi possono inviare posta, quali Certification Authority possono emettere certificati SSL e come devono comportarsi i server quando una verifica di sicurezza fallisce.
Tra questi rientrano CAA, SPF, DKIM, DMARC, DNSSEC e MTA-STS. A questi si possono aggiungere TLS-RPT, DANE e BIMI, che intervengono in ambiti più specifici.
La presenza del record, da sola, non dice però se la protezione sia davvero attiva. Una configurazione DMARC con policy di monitoraggio, un record SPF terminato con un criterio permissivo o una policy MTA-STS in modalità di test possono sembrare configurazioni complete, ma non applicano ancora un blocco effettivo.
Come verificare i record DNS di un dominio
Prima di toccare una zona DNS è meglio vedere cosa risulta già pubblicato. Nei sistemi Linux, macOS e negli ambienti in cui è disponibile il pacchetto DNS Utilities si può utilizzare il comando dig.
Per interrogare un record specifico:
dig TIPO_RECORD nome-dominio
Per ottenere una risposta più compatta:
dig +short TIPO_RECORD nome-dominio
Ad esempio, per verificare i record TXT pubblicati sul dominio principale:
dig +short TXT example.com
In Windows si può utilizzare anche nslookup:
nslookup -type=TXT example.com
Una risposta vuota può significare che il record non esiste. Prima di arrivare a questa conclusione conviene però verificare di aver interrogato il nome corretto, attendere l’eventuale propagazione DNS e ripetere il controllo utilizzando più resolver.
Per interrogare direttamente un resolver pubblico si può usare, ad esempio:
dig @1.1.1.1 +short TXT example.com dig @8.8.8.8 +short TXT example.com
I valori riportati di seguito servono solo come esempio. Non devono essere copiati senza prima verificare la configurazione reale del dominio, del servizio di posta e dell’infrastruttura utilizzata.
Record CAA: limitare l’emissione dei certificati SSL
Il record CAA, acronimo di Certification Authority Authorization, dà al titolare di un dominio la possibilità di indicare quali Certification Authority sono autorizzate a emettere certificati SSL/TLS per quel dominio.
Senza CAA, una Certification Authority pubblica può valutare la richiesta di emissione secondo le proprie procedure e le regole del settore. Pubblicando CAA si aggiunge invece un controllo esplicito nella zona DNS.
Il record può essere verificato con:
dig +short CAA example.com
Una configurazione che autorizza esclusivamente Let’s Encrypt per i certificati ordinari può essere simile alla seguente:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
La proprietà issue identifica le Certification Authority autorizzate a emettere certificati non wildcard.
Per autorizzare anche i certificati wildcard:
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
Per impedire espressamente l’emissione di certificati wildcard si può pubblicare:
example.com. 3600 IN CAA 0 issuewild ";"
Il punto e virgola come valore vuoto indica che nessuna Certification Authority è autorizzata a emettere certificati wildcard per il dominio.
È possibile autorizzare più Certification Authority pubblicando più record CAA:
example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 issue "digicert.com"
Esiste inoltre la proprietà iodef, utilizzabile per indicare un recapito al quale inviare segnalazioni relative a richieste di certificati non conformi alla policy CAA:
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"
Quando il record CAA può creare problemi
CAA non va configurato guardando soltanto la Certification Authority indicata nel certificato attuale. È necessario considerare tutti i servizi che possono richiedere automaticamente certificati per il dominio o per i suoi sottodomini.
Rientrano in questo scenario piattaforme di hosting, CDN, servizi SaaS, bilanciatori, pannelli di controllo, sistemi di posta e servizi esterni collegati tramite CNAME.
Se viene autorizzata soltanto Let’s Encrypt, ma uno dei servizi utilizza una CA differente, il rinnovo o l’emissione del certificato potrebbe fallire.
SPF: dichiarare quali server possono inviare email
SPF, acronimo di Sender Policy Framework, indica quali server sono autorizzati a inviare email utilizzando un determinato dominio nel comando SMTP MAIL FROM.
Il record viene pubblicato come TXT sul dominio interessato:
dig +short TXT example.com
Un record SPF semplice può essere:
v=spf1 ip4:192.0.2.10 -all
Il significato è il seguente:
v=spf1identifica la versione del protocollo;ip4:192.0.2.10autorizza l’indirizzo IPv4 indicato;-alldichiara non autorizzati tutti gli altri mittenti.
È possibile autorizzare più indirizzi e includere le policy SPF di servizi esterni:
v=spf1 ip4:192.0.2.10 include:_spf.example-provider.net -all
Differenza tra ~all e -all
La parte finale del record indica come trattare i sistemi che non corrispondono ai meccanismi elencati prima.
Con il soft fail:
~all
il dominio segnala che gli altri server probabilmente non sono autorizzati. Il server destinatario conserva comunque libertà decisionale e può accettare il messaggio, classificarlo come sospetto o applicare altre regole locali.
Con l’hard fail:
-all
il dominio dichiara che i server non inclusi nella policy non sono autorizzati.
L’uso di -all è indicato quando sono stati censiti tutti i sistemi che inviano email per conto del dominio. Prima di applicarlo occorre considerare almeno:
- server di posta principali;
- server SMTP dell’hosting;
- applicazioni web e moduli di contatto;
- gestionali e CRM;
- piattaforme per newsletter;
- sistemi di ticketing;
- servizi di fatturazione;
- servizi cloud e applicazioni SaaS.
Un servizio dimenticato potrebbe continuare a inviare messaggi, ma questi risulterebbero non autorizzati dalla policy SPF.
Il limite dei dieci lookup DNS
La valutazione SPF non può generare un numero illimitato di interrogazioni DNS. I meccanismi che richiedono risoluzioni DNS, come include, a, mx, exists e redirect, concorrono al limite previsto dal protocollo.
Se durante la valutazione si superano dieci termini che comportano lookup DNS, il risultato deve essere permerror. Non significa che il record non sia sintatticamente valido: significa che non può essere valutato correttamente entro i limiti previsti.
Un record apparentemente semplice può superare il limite perché ogni direttiva include può richiamare altri record SPF, che a loro volta contengono ulteriori inclusioni.
Vanno considerati anche i cosiddetti void lookup, ossia interrogazioni che restituiscono un nome inesistente oppure nessun dato utile. Le implementazioni SPF dovrebbero limitarli a due durante una singola valutazione.
Un solo record SPF per dominio
Per ciascun nome DNS deve essere pubblicato un solo record SPF che inizi con:
v=spf1
La presenza di due record SPF separati non somma le autorizzazioni. Produce invece un errore permanente.
Una configurazione errata:
v=spf1 include:_spf.provider-a.example -all v=spf1 include:_spf.provider-b.example -all
Deve essere accorpata in un unico record:
v=spf1 include:_spf.provider-a.example include:_spf.provider-b.example -all
DKIM: firmare crittograficamente i messaggi
DKIM, acronimo di DomainKeys Identified Mail, consente al server mittente di aggiungere una firma crittografica alle email.
Il sistema utilizza una coppia di chiavi:
- la chiave privata rimane sul server che firma i messaggi;
- la chiave pubblica viene pubblicata nel DNS.
Il server destinatario legge la firma presente nell’intestazione DKIM-Signature, recupera la chiave pubblica dal DNS e verifica che le parti firmate del messaggio non siano state alterate.
La chiave pubblica viene generalmente pubblicata come record TXT nel formato:
selettore._domainkey.example.com
Ad esempio:
mail._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=CHIAVE_PUBBLICA"
Il valore mail è il selettore, che consente di mantenere più chiavi DKIM sullo stesso dominio e di sostituirle senza dover modificare il nome principale.
Per verificare il record:
dig +short TXT mail._domainkey.example.com
DKIM non identifica necessariamente l’autore visibile
DKIM prova che un dominio ha firmato il messaggio e che le parti firmate non sono state modificate. Non garantisce, da solo, che il dominio firmatario coincida con il dominio mostrato nel campo From.
Questo collegamento viene stabilito da DMARC mediante il concetto di allineamento.
Rotazione delle chiavi DKIM
Le chiavi DKIM vanno ruotate periodicamente. Si crea un nuovo selettore, si pubblica la relativa chiave pubblica, si configura il server per utilizzare la nuova chiave e soltanto dopo un periodo adeguato si rimuove il vecchio record.
Ad esempio:
mail2025._domainkey.example.com mail2026._domainkey.example.com
La rimozione immediata della vecchia chiave può rendere non verificabili messaggi ancora in transito, accodati oppure conservati in sistemi che effettuano controlli successivi.
DMARC: applicare una policy ad SPF e DKIM
DMARC, acronimo di Domain-based Message Authentication, Reporting and Conformance, utilizza i risultati di SPF e DKIM per stabilire se un messaggio è coerente con il dominio visibile nel campo From.
Il record viene pubblicato come TXT sul nome:
_dmarc.example.com
Per verificarlo:
dig +short TXT _dmarc.example.com
Una configurazione iniziale può essere:
v=DMARC1; p=none; rua=mailto:[email protected]
La policy p=none richiede la raccolta dei dati, ma non chiede ai destinatari di mettere in quarantena o rifiutare i messaggi che non superano DMARC.
Le policy DMARC
DMARC prevede tre policy principali.
p=none
È una modalità di monitoraggio. Serve a ricevere report e a osservare chi utilizza il dominio per l’invio, senza richiedere un trattamento restrittivo per i messaggi che falliscono la verifica.
v=DMARC1; p=none; rua=mailto:[email protected]
p=quarantine
Richiede ai destinatari di trattare come sospetti i messaggi che falliscono DMARC. In base alle politiche del provider, il messaggio può essere spostato nella posta indesiderata oppure sottoposto ad altri controlli.
v=DMARC1; p=quarantine; rua=mailto:[email protected]
p=reject
Richiede il rifiuto dei messaggi che non superano DMARC.
v=DMARC1; p=reject; rua=mailto:[email protected]
Passare subito a p=reject è rischioso quando non sono stati ancora identificati tutti i flussi di posta. Prima si raccolgono e si analizzano i report, poi si correggono SPF, DKIM e gli eventuali servizi esterni. Soltanto dopo si applica una policy più restrittiva.
Allineamento SPF e DKIM
Per superare DMARC non basta che SPF o DKIM restituiscano un risultato positivo. Almeno uno dei due deve anche risultare allineato con il dominio presente nel campo From visibile all’utente.
Nel caso di SPF, DMARC confronta il dominio del campo From con quello utilizzato nell’identità SPF, normalmente associata a MAIL FROM.
Nel caso di DKIM, il confronto avviene invece tra il dominio del campo From e il valore d= presente nella firma DKIM.
In modalità rilassata sono ammessi domini appartenenti alla stessa struttura organizzativa. In modalità rigida deve esserci una corrispondenza esatta.
Le modalità possono essere impostate con:
adkim=s aspf=s
dove s indica l’allineamento rigido. Il valore r indica invece l’allineamento rilassato.
Policy per i sottodomini
Il parametro sp permette di definire la policy per i sottodomini:
v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]
Se sp non viene specificato, ai sottodomini si applica di norma la policy indicata in p, secondo le regole DMARC.
Report DMARC
Il parametro rua indica dove ricevere i report aggregati:
rua=mailto:[email protected]
I report aggregati vengono generalmente trasmessi in formato XML e contengono informazioni sui messaggi osservati, sugli indirizzi IP mittenti e sui risultati di SPF, DKIM e DMARC.
Su domini che inviano molta posta, i report diventano rapidamente numerosi e poco pratici da leggere a mano. In questi casi conviene utilizzare una piattaforma dedicata oppure un sistema interno di analisi.
Quando l’indirizzo indicato in rua appartiene a un dominio diverso da quello monitorato, può essere necessaria un’autorizzazione DNS aggiuntiva sul dominio che riceve i report.
DNSSEC: verificare autenticità e integrità delle risposte DNS
DNSSEC, acronimo di Domain Name System Security Extensions, aggiunge firme crittografiche ai dati DNS. Non cifra le interrogazioni. Serve a permettere a un resolver validante di verificare che la risposta ricevuta sia autentica e non sia stata modificata.
DNSSEC utilizza diversi tipi di record, tra cui:
DNSKEY, che contiene le chiavi pubbliche della zona;RRSIG, che contiene le firme dei gruppi di record;DS, che collega la zona figlia alla zona padre;NSECoNSEC3, utilizzati per dimostrare in modo autenticato l’assenza di un nome o di un record.
Perché il record DS è fondamentale
Firmare la zona sul server DNS non basta per attivare DNSSEC. Il record DS deve essere pubblicato nella zona padre, di solito attraverso il registrar del dominio.
Per un dominio .com, ad esempio, il DS viene inserito dal registrar nella zona .com. In questo modo si crea la catena di fiducia che parte dalla zona radice e arriva fino al dominio.
Il record DS può essere controllato con:
dig +short DS example.com
Per richiedere una risposta completa con i dati DNSSEC:
dig +dnssec example.com
Se si interroga un resolver validante, la presenza del flag ad, ossia Authenticated Data, indica che il resolver dichiara di aver validato la risposta.
dig @1.1.1.1 +dnssec example.com
Occorre distinguere tra:
- zona firmata sul server DNS;
- record DS pubblicato presso il registrar;
- risposta effettivamente validata dal resolver utilizzato.
Attenzione ai cambi di provider DNS
DNSSEC va gestito con attenzione durante un cambio di nameserver o una rotazione delle chiavi. Se il record DS pubblicato nella zona padre non corrisponde più alle chiavi della zona servita dai nameserver, i resolver validanti possono considerare il dominio non valido.
In questa situazione il dominio può risultare raggiungibile utilizzando resolver che non validano DNSSEC, ma irraggiungibile per chi si affida a resolver validanti.
Prima di cambiare provider DNS occorre quindi pianificare la rimozione, la sostituzione o il trasferimento corretto dei dati DNSSEC.
MTA-STS: impedire il downgrade della posta verso connessioni non protette
Durante la consegna SMTP tra server, TLS viene spesso negoziato tramite STARTTLS. Storicamente questa modalità è opportunistica: se la cifratura non è disponibile, il server mittente può tentare la consegna senza TLS.
MTA-STS, acronimo di Mail Transfer Agent Strict Transport Security, dà a un dominio destinatario la possibilità di dichiarare che i propri server MX supportano TLS e che i mittenti compatibili devono applicare una determinata policy.
La configurazione richiede due elementi:
- un record TXT DNS;
- un file di policy pubblicato tramite HTTPS.
Record DNS MTA-STS
Il record viene pubblicato su:
_mta-sts.example.com
Un esempio:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=2026073101"
Il valore id identifica la versione della policy. Quando la policy cambia, deve essere aggiornato, in modo che i server mittenti sappiano di doverla recuperare nuovamente.
La verifica si effettua con:
dig +short TXT _mta-sts.example.com
File di policy MTA-STS
Il file deve essere disponibile all’indirizzo:
https://mta-sts.example.com/.well-known/mta-sts.txt
Un esempio di policy:
version: STSv1 mode: enforce mx: mail.example.com mx: *.mail.example.com max_age: 604800
I campi principali sono:
version, che identifica la versione del protocollo;mode, che stabilisce il comportamento;mx, che elenca i server autorizzati a ricevere posta;max_age, che indica per quanti secondi la policy può essere conservata.
Modalità MTA-STS
La modalità testing permette di pubblicare la policy senza richiedere il blocco della consegna in caso di errore:
mode: testing
La modalità enforce richiede invece l’applicazione effettiva:
mode: enforce
Esiste anche la modalità none, utilizzata per indicare che il dominio non desidera più applicare una policy MTA-STS:
mode: none
Anche qui la modalità di test serve a osservare il comportamento, ma non applica ancora la policy.
Requisiti del sottodominio MTA-STS
Il nome mta-sts.example.com deve essere raggiungibile tramite HTTPS e deve presentare un certificato valido e riconosciuto. Non sono previsti certificati autofirmati per il recupero della policy.
Il contenuto deve essere pubblicato esattamente nel percorso /.well-known/mta-sts.txt e deve essere restituito senza reindirizzamenti incompatibili con le regole del protocollo.
TLS-RPT: ricevere report sui problemi TLS della posta
TLS-RPT, o SMTP TLS Reporting, rende possibile ricevere report relativi ai problemi riscontrati durante la consegna SMTP protetta.
Il record viene pubblicato come TXT su:
_smtp._tls.example.com
Un esempio:
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Per verificarlo:
dig +short TXT _smtp._tls.example.com
I report possono fornire informazioni su:
- errori nella negoziazione STARTTLS;
- certificati scaduti o non validi;
- nomi presenti nel certificato non coerenti con il server MX;
- errori nella policy MTA-STS;
- problemi nella validazione DANE;
- tentativi di consegna che non hanno rispettato la policy TLS.
MTA-STS e TLS-RPT non fanno la stessa cosa. MTA-STS pubblica la policy; TLS-RPT permette di osservare i problemi incontrati durante la sua applicazione.
DANE e record TLSA
DANE, acronimo di DNS-Based Authentication of Named Entities, rende possibile associare un certificato TLS o una chiave pubblica a un servizio mediante record TLSA protetti da DNSSEC.
Nel caso della posta SMTP, il record TLSA viene normalmente pubblicato sul nome composto dalla porta, dal protocollo e dal server MX:
_25._tcp.mail.example.com
La verifica si effettua con:
dig +short TLSA _25._tcp.mail.example.com
DANE può rendere la consegna SMTP resistente ai downgrade e consente di autenticare il server utilizzando la catena di fiducia DNSSEC.
A differenza di MTA-STS, che recupera una policy HTTPS e utilizza certificati collegati alle Certification Authority pubbliche, DANE dipende dalla corretta configurazione di DNSSEC.
La gestione dei record TLSA richiede attenzione durante il rinnovo o la sostituzione dei certificati e delle chiavi. Un record TLSA non aggiornato può causare il fallimento delle consegne da parte dei server che applicano DANE.
Per questo DANE non va configurato copiando un valore trovato altrove. Il record deve essere generato partendo dal certificato, dalla chiave o dalla catena effettivamente utilizzata dal server.
BIMI: associare un logo verificabile alle email
BIMI, acronimo di Brand Indicators for Message Identification, dà ai provider compatibili la possibilità di mostrare un logo associato al dominio mittente.
BIMI non sostituisce SPF, DKIM o DMARC. Si basa invece su una configurazione di autenticazione già funzionante e su una policy DMARC applicata.
Un record BIMI viene in genere pubblicato su:
default._bimi.example.com
Un esempio semplificato:
default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/logo-bimi.svg"
Il parametro l indica il percorso HTTPS del logo in formato SVG compatibile con i requisiti BIMI.
Alcuni provider richiedono anche un certificato del marchio. Il record può quindi contenere il parametro a:
v=BIMI1; l=https://example.com/logo-bimi.svg; a=https://example.com/certificato.pem
Il supporto e i requisiti possono variare tra i provider di posta. La pubblicazione del record non garantisce quindi che il logo venga visualizzato in ogni client o per ogni destinatario.
Prima di implementare BIMI è opportuno verificare che:
- SPF e DKIM siano correttamente configurati;
- DMARC sia applicato con una policy adeguata;
- i messaggi superino DMARC;
- il file SVG rispetti il profilo richiesto;
- l’eventuale certificato del marchio sia valido;
- il provider destinatario supporti BIMI.
Avere un record non significa applicare una protezione
Un errore frequente è considerare sufficiente la presenza del record DNS.
Le seguenti configurazioni possono essere formalmente presenti, ma non applicare ancora una protezione completa:
v=DMARC1; p=none v=spf1 include:_spf.provider.example ~all mode: testing
p=none raccoglie informazioni, ma non richiede quarantena o rifiuto. ~all dichiara un soft fail, lasciando maggiore libertà al destinatario. mode: testing pubblica una policy MTA-STS senza richiederne l’applicazione restrittiva.
Questi valori non sono sbagliati in assoluto. Possono rappresentare fasi corrette di un’attivazione graduale. Il problema nasce quando vengono lasciati in modalità di monitoraggio senza analizzare i risultati e senza completare il passaggio verso l’applicazione effettiva.
Ordine consigliato per la configurazione
Non esiste una sequenza valida per qualsiasi infrastruttura. Per la posta, però, conviene procedere per gradi.
- Censire tutti i sistemi che inviano email per conto del dominio.
- Configurare un solo record SPF corretto.
- Attivare DKIM su ogni servizio che lo supporta.
- Pubblicare DMARC con
p=nonee raccogliere i report. - Correggere i flussi non allineati o non autorizzati.
- Passare progressivamente a
p=quarantinee successivamente ap=reject. - Configurare MTA-STS inizialmente in modalità
testing. - Attivare TLS-RPT e analizzare gli errori ricevuti.
- Passare MTA-STS alla modalità
enforcedopo aver verificato gli MX e i certificati.
CAA e DNSSEC possono essere gestiti parallelamente, ma richiedono un inventario preciso dei servizi che emettono certificati e una procedura sicura per la gestione delle chiavi e delle deleghe.
Checklist per il controllo periodico del dominio
Nel controllo periodico della zona DNS conviene verificare almeno questi punti:
- il record CAA autorizza tutte e sole le Certification Authority effettivamente necessarie;
- esiste un solo record SPF;
- SPF non supera il limite dei lookup DNS;
- tutti i servizi mittenti sono inclusi nella policy SPF;
- le firme DKIM vengono applicate e superano la verifica;
- i selettori DKIM non più utilizzati vengono rimossi dopo un periodo adeguato;
- DMARC riceve report su un indirizzo monitorato;
- la policy DMARC corrisponde al livello di applicazione desiderato;
- SPF o DKIM risultano allineati con il dominio nel campo
From; - DNSSEC presenta una catena di fiducia valida;
- il record DS corrisponde alle chiavi attualmente utilizzate;
- la policy MTA-STS elenca tutti i server MX validi;
- il certificato HTTPS di
mta-stsè valido; - TLS-RPT invia i report a un indirizzo controllato;
- gli eventuali record TLSA corrispondono ai certificati o alle chiavi in uso;
- la configurazione BIMI rispetta i requisiti del provider destinatario.
Errori da evitare
Copiare record DNS appartenenti a un altro dominio
Questi record dipendono dall’infrastruttura realmente utilizzata. Copiare SPF, CAA, DKIM, MTA-STS o TLSA da un altro dominio può autorizzare servizi errati oppure bloccare quelli legittimi.
Applicare subito policy restrittive
DMARC con p=reject, SPF con -all e MTA-STS con mode: enforce devono essere applicati dopo aver verificato che tutti i flussi legittimi siano correttamente configurati.
Non leggere i report
Pubblicare rua in DMARC o TLS-RPT serve a poco se i report non vengono ricevuti, conservati e analizzati. Una casella piena, inesistente o ignorata rende inefficace il monitoraggio.
Dimenticare i servizi esterni
Newsletter, CRM, help desk, sistemi di fatturazione e applicazioni cloud possono inviare email utilizzando il dominio aziendale. Ognuno di questi servizi deve essere valutato in SPF, DKIM e DMARC.
Modificare DNSSEC senza pianificazione
Un errore nei record DS o nella rotazione delle chiavi può rendere l’intero dominio non validabile. Le modifiche devono tenere conto dei TTL, dei tempi del registrar e della procedura prevista dal provider DNS.
Il controllo va mantenuto nel tempo
Questi record non lavorano tutti sullo stesso livello. CAA interviene sull’emissione dei certificati, SPF e DKIM sull’autenticazione della posta, DMARC sull’allineamento e sulle policy, DNSSEC sull’integrità delle risposte DNS. MTA-STS, TLS-RPT e DANE riguardano invece il trasporto SMTP e la verifica delle connessioni.
Il punto non è pubblicare il maggior numero possibile di record, ma configurare quelli utili in modo coerente con i servizi realmente in uso. Un record SPF dimenticato, un vecchio selettore DKIM o un record DS non più allineato possono creare problemi anche molto tempo dopo la prima configurazione.
Per questo la zona DNS va ricontrollata periodicamente, soprattutto quando cambiano provider di posta, piattaforme newsletter, servizi cloud, nameserver o sistemi che gestiscono i certificati. Il DNS resta una parte operativa dell’infrastruttura: se viene lasciato fermo mentre tutto il resto cambia, prima o poi la configurazione smette di rappresentare ciò che esiste davvero.
