DNS della posta automatico: un clic o un token per tutti i domini

La configurazione DNS della posta richiede sei o sette record. Diversi contengono stringhe lunghe: basta un carattere sbagliato per causare un errore che non sembra affatto un refuso. Una chiave DKIM occupa alcune centinaia di caratteri in base64. Un record SPF elenca meccanismi il cui ordine conta e termina con un elemento che cambia il significato della politica. Anche il nome del sottodominio usato da DMARC è facile da sbagliare.

Configurando un solo dominio, probabilmente andrà tutto bene. Con quaranta domini di clienti, il rischio di lasciarsi sfuggire qualcosa aumenta. Potreste accorgervene soltanto un mese dopo, quando una fattura finisce nello spam.

La configurazione automatica evita di ricopiare i valori. Le possibilità sono due: autorizzare la modifica di un dominio presso il provider e tornare su TrekMail senza fornire un token, oppure usare un token API con permessi limitati per gestire anche un centinaio di domini, suddivisi in gruppi. In entrambi i casi potete esaminare le modifiche prima di applicarle.

Quali record DNS richiede la posta

«Necessario in molti scenari» non significa che gli RFC impongano DKIM e DMARC a ogni dominio. Google e Yahoo hanno introdotto requisiti per chi invia grandi volumi nel 2024; l'applicazione dipende dalla categoria del mittente e dalle regole vigenti. Anche i destinatari aziendali possono avere requisiti propri. Senza questi record non diventa automaticamente impossibile inviare posta, ma l'autenticazione e l'accettazione dei messaggi possono risultare più difficili.

Quattro errori comuni quando si configura il DNS a mano

Pubblicare due record SPF. È un errore frequente e dalle conseguenze importanti. Il nome sottoposto a verifica deve pubblicare un solo record SPF. Aggiungerne un secondo per un nuovo servizio non amplia la politica: una valutazione conforme al protocollo restituisce permerror. I meccanismi vanno riuniti in un unico record. Consultate gli esempi di record SPF.

Danneggiare una chiave DKIM incollandola. La rappresentazione di una chiave da 2048 bit supera il limite di 255 caratteri per singola stringa TXT. Il record deve quindi contenere più stringhe, concatenate alla lettura. Alcuni pannelli DNS gestiscono la divisione automaticamente, altri richiedono di prepararla e altri possono troncare il valore. Una chiave incompleta impedisce la verifica della firma senza rendere evidente la causa.

Pubblicare DMARC con il nome sbagliato. Il record va sotto _dmarc.example.com. Se lo inserite alla radice, i destinatari non lo troveranno cercando la politica DMARC di quel dominio.

Superare il limite di ricerche SPF. SPF limita a dieci i termini che richiedono ricerche DNS durante la valutazione. Ogni include: valutato conta, anche nelle inclusioni annidate. Il provider di posta, un CRM, uno strumento di marketing e un help desk possono far superare il limite, a seconda delle loro politiche. Il risultato è permerror. Il problema può emergere mesi dopo la configurazione iniziale, quando viene aggiunto un altro strumento. Consultate il limite di ricerche DNS di SPF.

L'automazione riduce gli errori di copia e individua i conflitti, ma non sostituisce il controllo del risultato. Integrare il record SPF evita di crearne un secondo; non dimostra che la politica finale rispetti il limite di valutazione.

Metodo 1: configurare il DNS con un clic, senza token

Per un dominio il cui DNS è gestito da Cloudflare, è il percorso più diretto. Non dovete fornire a TrekMail un token API né le credenziali dell'account.

1. Aprite la scheda DNS e stato del dominio.
2. Fate clic su Configura DNS automaticamente.
3. Cloudflare mostra i record proposti prima che autorizziate l'operazione.
4. Fate clic su Autorizza.
5. Tornate su TrekMail e viene richiesta una verifica. Il ritorno, da solo, non conferma che i record siano stati pubblicati correttamente.

Il percorso usa Domain Connect, un protocollo aperto per questo scambio: il servizio descrive i record necessari, il provider DNS presenta le modifiche al titolare del dominio e quest'ultimo le approva. Non viene creato né conservato un token API riutilizzabile. L'autorizzazione riguarda l'operazione proposta per quel dominio.

I server dei nomi del dominio devono puntare a Cloudflare. Se il dominio è soltanto registrato presso Cloudflare ma il DNS è ospitato altrove, questo percorso non è disponibile. Le modifiche devono avvenire presso il provider che gestisce realmente la zona DNS.

Metodo 2: configurare il DNS con un token API limitato

Per più domini, oppure quando Domain Connect non è disponibile, un token permette di configurare le zone autorizzate dell'account.

Create il token in Cloudflare usando il modello Edit zone DNS, con il permesso Zone → DNS → Edit. Nelle risorse di zona scegliete All zones per tutte le zone oppure Specific zone per limitare l'accesso. Verificate che i vincoli sugli IP e la durata di validità consentano l'uso previsto; non occorre modificarli senza motivo. Copiate il token quando viene mostrato e incollatelo in TrekMail.

Il punto è capire quali operazioni consentono questi permessi e quali escludono:

TrekMail conserva il token cifrato ed evita di registrarne il valore nei log. Potete scollegarlo da un dominio in TrekMail oppure revocarlo in Cloudflare per impedire nuove richieste con quel token. Scollegare un dominio non revoca necessariamente un token condiviso con altri domini. La revoca non annulla le modifiche già applicate.

Dopo la connessione vengono elencate le zone Cloudflare disponibili con l'azione prevista: Configura DNS per un dominio già presente nell'account TrekMail, oppure Aggiungi + DNS per aggiungerlo e configurarlo nello stesso percorso. I domini con DNS fuori da Cloudflare non compaiono come zone configurabili da questa integrazione.

L'anteprima e i suoi cinque stati

Prima di applicare la configurazione potete esaminare ogni record. L'anteprima distingue cinque stati:

Ogni record ha una casella di selezione. Potete applicare MX e SPF subito e occuparvi di DKIM in seguito, oppure escludere un record gestito con un altro sistema. I record deselezionati non vengono applicati in quell'operazione.

Leggete i conflitti invece di confermarli senza controllare. Una politica DMARC p=none non è sbagliata: può far parte di una fase intenzionale di monitoraggio. Sostituirla con p=quarantine prima di esaminare i rapporti può penalizzare messaggi legittimi che non si autenticano ancora correttamente. Mantenetela se necessario, completate l'adozione e solo dopo rendete la politica più restrittiva. I criteri sono spiegati in come scegliere una politica DMARC.

Perché integrare il record SPF esistente

SPF merita particolare attenzione perché una sola politica può autorizzare più servizi di invio. Sostituire il record senza esaminare quei servizi rischia di rimuovere autorizzazioni ancora necessarie.

Se il vostro dominio pubblica già:

v=spf1 include:_spf.google.com ~all

la politica autorizza l'infrastruttura Google, per esempio Workspace o uno strumento che invia attraverso di essa. Sostituirla con un record che include soltanto TrekMail non aggiunge semplicemente un mittente: elimina l'autorizzazione precedente. I messaggi che ne dipendevano possono iniziare a fallire la verifica SPF.

Per questo un record SPF esistente e valido viene normalmente integrato:

v=spf1 include:_spf.trekmail.net include:_spf.google.com ~all

Entrambi i servizi restano autorizzati in un unico record e il qualificatore finale viene conservato. Si aggiunge così TrekMail senza togliere l'autorizzazione precedente. Non significa che il record non venga mai sostituito: SPF duplicati o malformati possono richiedere la risoluzione di un conflitto. La politica risultante va comunque verificata.

Controllate poi due aspetti. Il nuovo include: conta nel limite di dieci termini con ricerche DNS e può comportare inclusioni annidate: valutate la politica completa. Se il vecchio provider non invia davvero più per il dominio, rimuovete la sua autorizzazione manualmente dopo averlo confermato. Un periodo senza attività non dimostra che il servizio sia stato dismesso.

Configurare il DNS per gruppi di domini

Con un token autorizzato per tutte le zone, la procedura guidata può scorrere i domini compatibili, aggiungere quelli nuovi, configurare i record e mostrare i risultati per dominio. Il massimo è di 50 domini per gruppo. I nuovi domini contano nel limite del piano: 10 su Nano, 50 su Starter, 100 su Pro e 1,000 su Agency, secondo la configurazione descritta nell'articolo originale. Controllate i limiti attuali dell'account prima di iniziare.

Per un'agenzia che acquisisce un cliente con una dozzina di domini, la configurazione in gruppo può risparmiare molto lavoro manuale. Rende però l'anteprima ancora più importante. Immaginate dodici domini, due con una politica DMARC in conflitto e uno con un CNAME autodiscover ancora diretto al provider lasciato nel 2023. È un esempio di cosa cercare, non una frequenza garantita.

L'ambito delle modifiche

È una domanda ragionevole prima di concedere a un'applicazione accesso in scrittura al DNS.

L'integrazione è progettata per gestire record di posta: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT e i CNAME di autoconfigurazione. Non dovrebbe modificare record A, CNAME del sito o TXT di altri servizi. Il permesso DNS del token, però, consente di modificare i record delle zone autorizzate, non soltanto quelli di posta. La tutela degli altri record dipende quindi anche dal comportamento dell'applicazione. Quel permesso non consente di cambiare i server dei nomi.

Sostituire un record in conflitto può rimuovere una configurazione precedente, perciò serve una conferma. Esaminate anche le altre modifiche e l'eventuale pulizia dei duplicati associata a un'azione: non è prudente considerare tutte le altre operazioni prive di conseguenze. Conservate i valori precedenti se dovete poterli ripristinare.

Uno stato in attesa può dipendere dalle cache DNS, ma anche da un record errato o da un'operazione incompleta. L'originale parla di un massimo di 48 ore; non è un termine universale, perché contano il TTL e le condizioni del provider. La verifica viene ripetuta automaticamente e Verifica DNS richiede un nuovo controllo. Se l'errore persiste il giorno successivo, controllate i valori pubblicati e consultate la risoluzione dei problemi DKIM quando il problema riguarda quella firma.

Domande frequenti

Serve un account Cloudflare per configurare il DNS con un clic?

Cloudflare deve gestire il DNS del dominio e dovete avere accesso all'account corrispondente per autorizzare la modifica. Non serve fornire un token API a TrekMail: approvate l'operazione nell'interfaccia di Cloudflare e non viene conservato un token riutilizzabile.

E se il mio DNS non è su Cloudflare?

Questa integrazione automatica non configura l'altro provider. I record vanno creati manualmente. La pagina DNS del dominio mostra i valori con pulsanti per copiarli; trovate istruzioni specifiche in configurazione DNS presso i provider più diffusi.

La configurazione automatica può compromettere il sito?

L'integrazione è progettata per modificare i record di posta e lasciare invariati record A, CNAME del sito e TXT estranei alla posta. Questo non significa che il token non possa modificarli: i suoi permessi coprono i record DNS delle zone autorizzate. Esaminate le modifiche proposte. Il permesso descritto non consente di cambiare i server dei nomi.

Cosa succede al mio record SPF esistente?

Normalmente viene integrato: si aggiunge l'include di TrekMail e si conserva il qualificatore. In questo modo gli altri servizi autorizzati non vengono rimossi per errore. SPF duplicati o malformati possono richiedere una sostituzione confermata. Verificate anche il limite di ricerche della politica finale.

Posso applicare soltanto alcuni record?

Sì. Ogni record ha una casella di selezione nell'anteprima. Deselezionate quelli gestiti con un altro sistema per escluderli dall'operazione.

Quanti domini può configurare un'esecuzione?

Fino a 50 per gruppo, entro il limite totale di domini del piano. I nuovi domini aggiunti dalla procedura guidata contano in quel limite.

Il mio token API è protetto?

TrekMail lo conserva cifrato ed evita di registrarne il valore nei log. Con i permessi descritti può modificare il DNS delle zone selezionate, ma non gestire fatturazione, WAF, server dei nomi o trasferimenti di domini. Revocatelo in Cloudflare per impedire nuove richieste; questo non annulla le modifiche precedenti. Autorizzate soltanto le zone necessarie.

Perché un record che non ho mai creato risulta «già configurato»?

Potrebbe averlo creato un provider precedente, oppure una configurazione autorizzata è già stata eseguita. Confrontate il valore pubblicato con quello proposto. Se coincidono, non serve sostituire il record, ma controllate che sia ancora adatto alla configurazione attuale.