Record MX e TXT spiegati

Cosa sono i record MX?

Un record MX mappa un dominio a uno o più mail exchanger, ciascuno con un intero di priorità (preferenza). I mittenti provano prima il numero più basso; priorità uguali possono essere bilanciate. Esempio: `10 mail.example.com` e `20 mail-backup.example.com`.

I target MX devono essere hostname con record A o AAAA — non IP nudi. Dopo aver cambiato MX, verifica con il DNS Checker e attendi la scadenza TTL sulle vecchie cache. Abbina i controlli MX al Blacklist Checker se la posta in arrivo finisce improvvisamente nello spam.

I domini di produzione dovrebbero pubblicare almeno due host MX su reti diverse. Se l'exchanger primario è irraggiungibile, RFC 5321 richiede ai siti mittenti di provare l'host con priorità successiva. Documenta entrambe le priorità nei ticket di change e riesegui il DNS Checker dopo ogni modifica MX così i thread support mostrano priorità live, non screenshot del pannello.

Cosa sono i record TXT?

I record TXT memorizzano stringhe di testo arbitrarie. Gli operatori mail pubblicano SPF all'apex (o sottodominio legacy) come `v=spf1 ...`, DKIM come selettori tipo `default._domainkey.example.com` e DMARC su `_dmarc.example.com`. La verifica sito usa token brevi (`google-site-verification=...`, `MS=ms...`).

Più stringhe in una risposta TXT sono normali. Alcuni pannelli dividono chiavi DKIM lunghe in chunk. In troubleshooting, copia il valore concatenato esatto dal DNS Checker invece di riscriverlo da un PDF.

TXT serve anche per BIMI, MTA-STS e TLS-RPT su setup mail avanzati — sempre pubblicato come testo su nomi prevedibili. Se il provider ruota selettori DKIM, vecchi e nuovi selettori possono coesistere brevemente; interroga TXT dopo ogni rotazione e annota TTL prima di rimuovere chiavi ritirate.

SPF, DKIM e DMARC in TXT

SPF elenca quali host possono inviare mail per il tuo dominio (`v=spf1 include:... ~all`). Può esistere un solo TXT SPF per owner name — stringhe SPF duplicate invalidano la policy del tutto. Unisci gli include invece di aggiungere un secondo record all'apex.

DKIM pubblica una chiave pubblica su `selector._domainkey.example.com`. L'allineamento con il dominio dell'intestazione From conta per pass/fail DMARC. Dopo onboarding di un relay, conferma il TXT del selettore nel DNS Checker rispetto alla dashboard del provider prima di campagne bulk.

DMARC su `_dmarc.example.com` imposta policy (`p=none`, `quarantine`, `reject`) e indirizzi report (`rua=`, `ruf=`). Inizia con `p=none` per raccogliere report aggregati, poi stringi quando SPF e DKIM si allineano in modo affidabile. Ricontrolla tutte e tre le famiglie con il DNS Checker dopo ogni migrazione mail — MX da solo non prova mai che SPF sia corretto.

Come controllare MX e TXT online

Passo 1 — Apri il DNS Checker e inserisci il dominio (apex o sottodominio). Passo 2 — Esegui lookup completo o concentrati su sezioni MX e TXT. Passo 3 — Confronta priorità, target e stringhe TXT con la guida setup del provider mail. Passo 4 — Se i valori sono obsoleti, nota la TTL e ri-interroga dopo la scadenza.

Per query MX mirata, apri il tool DIG, scegli tipo MX e ispeziona la sezione answer. Usa lo stesso dominio in WHOIS per confermare che i nameserver corrispondano al pannello DNS che hai modificato.

Archivia l'output del checker nei ticket: priorità, hostname exchanger, stringhe SPF/DKIM/DMARC complete e valori TTL. Se Authentication-Results mostra ancora fallimenti dopo un fix, attendi una finestra TTL completa e riesegui il DNS Checker — le cache ricorsive spesso sopravvivono al momento in cui clicchi Save nel pannello.

Verifica e token TXT di terze parti

Search Console, Microsoft 365, Stripe e vendor certificati chiedono ciascuno una prova TXT unica all'apex o su label `_dnsauth`. Questi token coesistono con SPF come record TXT separati sullo stesso nome — a differenza di SPF, più stringhe TXT non correlate su un owner sono valide.

Prima di eliminare TXT «vecchi» durante cleanup, conferma che nessuno sia verifica attiva o chiavi DKIM. Il DNS Checker elenca ogni risposta TXT su un nome così puoi confrontare con la doc del provider invece di indovinare a memoria.

Dopo aver aggiunto un TXT di verifica, interroga subito con il DNS Checker, poi di nuovo dopo TTL se il vendor segnala ancora fallimento. Alcuni registrar pubblicano zone a batch ogni pochi minuti — due esecuzioni identiche del checker a cinque minuti di distanza danno fiducia più rapidamente del solo refresh UI vendor.

Problemi comuni

SPF mancante è la via più rapida alle cartelle spam. Priorità MX errata invia mail a host dismessi. TXT di verifica con typo rompe Search Console o setup Microsoft 365. Risposte cache obsolete dopo TTL non abbassata prima del cutover sembrano «DNS rotto» mentre la propagazione è ancora in corso.

Record SPF duplicati sullo stesso nome invalidano SPF del tutto — unisci in un solo TXT. DMARC senza DKIM/SPF allineati segnala fallimenti ma non li risolve; tratta DMARC come layer di policy sopra record auth funzionanti.

Puntare MX a un label solo CNAME rompe la risoluzione su resolver strict. Pubblicare MX verso un hostname senza A/AAAA funzionanti crea perdita silenziosa di posta — conferma target exchanger nel DNS Checker dopo ogni cambio target MX.

MX e TXT durante le migrazioni

Le migrazioni mail falliscono silenziosamente quando MX è aggiornato prima che SPF/DKIM/DMARC siano pronti sul nuovo provider, o quando vecchi MX restano con numeri di priorità più bassi del previsto. Pubblica una baseline con il DNS Checker prima del cutover, poi confronta sezioni MX e TXT ogni ora nella finestra di migrazione.

Abbassa TTL su MX e TXT critici ventiquattro-quarantotto ore prima dello switch se il tuo host DNS lo consente. Conferma il TTL più basso pubblicamente con il DNS Checker — alcuni pannelli mostrano 300 secondi mentre la zona live serve ancora 3600 fino al completamento del prossimo ciclo di publish.

Mantieni MX del vecchio provider con priorità più alta (numero maggiore) finché non validi consegna in entrata sul nuovo stack, poi rimuovi exchanger ritirati. La posta in uscita può ancora usare vecchi include SPF finché non aggiorni TXT apex — controlla entrambe le direzioni con il DNS Checker prima di chiudere il ticket.

Documenta chi possiede ogni stringa TXT (verifica marketing, mail IT, report DMARC finance) così i futuri cleanup non cancellano per errore record di autenticazione di produzione.

Domande frequenti

Quanto tempo servono perché le modifiche DNS siano visibili?

La maggior parte dei resolver rispetta la TTL (time to live). Con TTL 3600 secondi, attendere fino a un'ora prima che le risposte in cache scadano. Abbassare la TTL prima delle migrazioni, applicare la modifica e verificare con il DNS Checker i nuovi valori.

Posso controllare MX e TXT senza installare dig?

Sì. Apri il DNS Checker, inserisci il dominio e filtra o scorri alle sezioni MX e TXT. Per un singolo tipo di record puoi usare anche il tool DIG con tipo MX o TXT.

Perché la mail funziona ma SPF fallisce ancora?

SPF autorizza solo IP mittenti o catene include. Un record MX funzionante non implica SPF corretto. Confronta gli IP SMTP in uscita con la catena include SPF e usa lookup TXT per confermare che la stringa live corrisponda alla documentazione del provider mail.

Devo usare più record MX?

Sì per la mail in produzione. Pubblica almeno due host MX con priorità diverse (numero più basso = preferenza maggiore). Se il primario è down, i mittenti provano la priorità successiva secondo RFC 5321.

Quale RFC definisce SPF?

SPF è definito in RFC 7208 (ex RFC 4408). DKIM è RFC 6376 e DMARC è RFC 7489. Tutti sono pubblicati come record TXT con nomi prevedibili.

Posso pubblicare MX e SPF sulla stessa etichetta hostname?

MX e SPF vivono di solito su nomi diversi — MX sull'apex o sottodominio mail, SPF come TXT sull'apex. Non mettere mai CNAME su un label che richiede anche MX o SPF. Usa il DNS Checker per confermare che tipi conflittuali non condividano lo stesso owner name.

Con quale frequenza ricontrollare MX e TXT in produzione?

Dopo ogni modifica DNS o del provider mail, più audit trimestrali per domini che inviano mail bulk. Il monitoraggio automatizzato via API DN01 può avvisare quando priorità MX o stringhe SPF deviano dai valori attesi.

DNS Checker memorizza i miei lookup?

I controlli riusciti possono comparire nella cronologia locale della sessione browser per comodità. Usa l'API documentata con il tuo token se serve monitoraggio ripetibile senza la web UI.