MTA-STS Validator Gratuito

Perché usare un validatore offline

Un validatore di sintassi MTA-STS analizza il Suo record DNS TXT e il Suo file di policy senza pubblicarli né interrogare il DNS. Questo approccio offline copre tre casi d'uso chiave che un audit in tempo reale non può affrontare.

Casi d'uso tipici:

• Prima del deployment → Validi una bozza di policy prima della pubblicazione, per evitare una configurazione errata in produzione.
• Preparazione multi-dominio → Verifichi più policy in batch durante una migrazione o un audit interno.
• Debug offline → Riproduca e corregga un errore senza accesso al DNS pubblico, ad esempio in un ambiente isolato o di pre-produzione.
• Revisione di configurazione → Esamini un record ricevuto da un partner o esportato da uno strumento di terze parti prima di applicarlo.

Il validatore applica le regole di sintassi RFC 8461: versione, identificatore, modalità, pattern MX, max_age e coerenza tra il record DNS e la policy. Non si connette ad alcun server, non risolve DNS e non scarica alcun file remoto.

Come usare questo validatore in 3 passi

Passo 1: incollare il record e la policy

Può validare tre combinazioni:

• Solo il record TXT _mta-sts (modalità record_only)
• Solo il contenuto del file mta-sts.txt (modalità policy_only)
• Entrambi insieme per verificare la coerenza (modalità combinata)

Non viene effettuata alcuna connessione di rete. I Suoi dati rimangono nel Suo browser.

Passo 2: aggiungere un dominio (opzionale)

Aggiungere un dominio attiva la validazione ibrida: il validatore risolve i record MX del dominio e verifica che i pattern dichiarati nella policy corrispondano ai server reali. Questa modalità aiuta a rilevare una policy troppo restrittiva o un MX dimenticato.

Senza dominio, viene analizzata solo la sintassi pura.

Passo 3: analizzare il verdetto

I risultati sono classificati per livello di gravità:

• ❌ Errore → Problema bloccante, la policy sarà ignorata dagli MTA destinatari
• ⚠️ Avviso → Funzionale ma si raccomanda un miglioramento
• ✅ Valido → Sintassi conforme a RFC 8461

Corregga ogni avviso prima di pubblicare il Suo record e il Suo file in produzione.

Validatore o record check: quando usare ogni strumento

I due strumenti sono complementari. Non si sostituiscono: intervengono in momenti diversi del ciclo di vita di una policy MTA-STS.

Flusso di lavoro raccomandato:

1. Progetti la policy → validatore per verificare la sintassi
2. Pubblichi DNS + file → attenda la propagazione
3. Record check per confermare l'audit live completo

Il validatore rileva gli errori di inserimento prima che raggiungano i Suoi utenti. Il record check rileva i drift, i certificati scaduti e i problemi di fetch HTTPS che appaiono solo in condizioni reali.

Modalità di validazione

Il validatore supporta quattro modalità a seconda dei campi compilati.

Modalità record_only

Incolla solo il record TXT. Validazione di:

• Formato v=STSv1
• Presenza e formato del tag id
• Tag sconosciuti o duplicati

Modalità policy_only

Incolla solo il contenuto del file di policy. Validazione di:

• Direttiva version
• Direttiva mode (enforce, testing, none)
• Pattern mx (almeno uno richiesto)
• Direttiva max_age (limiti da 0 a 31557600)

Modalità combinata record e policy

Incolla entrambi. Validazione completa più:

• Coerenza di versione tra TXT e file
• Coerenza di intenzione (un mode: none con un id attivo è sospetto)

Modalità ibrida con dominio

Aggiunga un dominio alla modalità combinata per attivare:

• Risoluzione degli MX del dominio
• Verifica che ogni MX reale corrisponda ad almeno un pattern mx:
• Rilevamento di server MX dimenticati o pattern troppo stretti

Questa validazione MX rimane statica: confronta i pattern con gli host MX dichiarati senza testare le connessioni SMTP.

Regole di sintassi verificate

Record DNS

Il validatore applica le regole di RFC 8461 §3.1 sul TXT _mta-sts.dominio:

Esempio valido:

v=STSv1; id=20240115120000

File di policy

Il validatore applica RFC 8461 §3.2 su mta-sts.txt:

Esempio valido:

version: STSv1
mode: enforce
mx: mail.captaindns.com
mx: *.backup.captaindns.com
max_age: 604800

Coerenza tra record e policy

Quando entrambi sono forniti:

• L'id del TXT deve corrispondere a una policy coerente (un cambio di policy implica un nuovo id).
• mode: none con un TXT attivo viene segnalato: spesso indica un'intenzione di ritiro incompleta.

Pattern MX e regole wildcard

RFC 8461 §4.1 definisce un formato stretto per i pattern mx:. Il validatore applica il seguente matching esatto.

Nome host esatto

mx: mail.captaindns.com
mx: smtp.captaindns.com

Corrisponde al nome esatto, senza distinguere maiuscole/minuscole.

Pattern wildcard

mx: *.mail.captaindns.com

Regole rigorose:

• Il wildcard * deve essere l'etichetta più a sinistra
• Corrisponde a esattamente un'etichetta (server1.mail.captaindns.com corrisponde, a.b.mail.captaindns.com no)
• Nessun doppio wildcard (**.captaindns.com non è valido)
• Nessun wildcard nel mezzo o alla fine (mail.*.captaindns.com non è valido)

Più pattern in una policy

Una policy può contenere più righe mx::

mx: mail.captaindns.com
mx: smtp.captaindns.com
mx: *.backup.captaindns.com

Un MX reale deve corrispondere ad almeno un pattern. Il validatore segnala gli MX reali orfani quando viene fornito un dominio.

Pattern non validi tipici

Errori di sintassi comuni e correzioni

Versione non corretta

Causa: v=sts1, v=STSV1 o version: stsv1 invece di STSv1 esattamente.

Correzione:

- v=sts1; id=20240115
+ v=STSv1; id=20240115

Identificatore assente

Causa: il record TXT non contiene il tag id.

Correzione: aggiunga un identificatore unico (timestamp consigliato):

v=STSv1; id=20240115120000

Formato id errato

Causa: spazi, caratteri speciali o lunghezza eccessiva in id.

Correzione: usi solo caratteri alfanumerici, da 1 a 32 caratteri.

- id=my policy id
+ id=mypolicyid20240115

Modalità non valida

Causa: mode: strict, mode: ENFORCE o errore di battitura.

Correzione: uno solo dei tre valori consentiti:

- mode: strict
+ mode: enforce

max_age fuori limiti

Causa: negativo, non numerico o superiore a 31557600.

Correzione: intero in [0, 31557600]. Valore raccomandato per produzione: 604800 (1 settimana).

- max_age: 99999999
+ max_age: 604800

Pattern malformato

Causa: wildcard mal posizionato o caratteri proibiti in una riga mx:.

Correzione: veda la sezione pattern MX più sopra.

- mx: mail.*.captaindns.com
+ mx: *.mail.captaindns.com

Nessun pattern di server

Causa: nessuna riga mx: in una policy in modalità enforce o testing.

Correzione: aggiunga almeno una riga mx: che corrisponda alla Sua infrastruttura. In modalità none, l'assenza di mx: è tollerata.

Strumenti complementari e risorse

Guide correlate

• MTA-STS: la guida completa per proteggere il trasporto delle Sue email - Configurazione, deployment e best practice.
• Troubleshooting MTA-STS: errori comuni e soluzioni - Diagnosticare i problemi di policy in produzione.
• Passare MTA-STS dalla modalità testing alla modalità enforce - Migrazione progressiva senza compromettere la deliverability.

Specifiche

• RFC 8461 - SMTP MTA Strict Transport Security (specifica ufficiale)
• Formato del record DNS MTA-STS (§3.1)
• Formato del file di policy MTA-STS (§3.2)
• Documentazione MTA-STS Google (guida Workspace)

FAQ - Domande frequenti

D: Qual è la differenza tra il validatore e il record check MTA-STS?

R: Il validatore analizza la sintassi che incolla, prima della pubblicazione, senza toccare il DNS. Il record check interroga DNS e HTTPS per verificare la configurazione pubblicata. Usi il validatore a monte, il record check a valle.

D: Perché validare la sintassi MTA-STS offline?

R: Per rilevare gli errori prima che impattino i Suoi utenti. Una policy non valida viene ignorata dagli MTA destinatari: il Suo dominio resta esposto. Meglio correggere un refuso in una bozza che diagnosticare un fallimento in produzione.

D: Quali sono gli errori di sintassi comuni?

R: I classici: STSV1 invece di STSv1, mode: strict invece di enforce, max_age non numerico, wildcard mal posizionato (mail.*.captaindns.com), assenza del tag id nel TXT o più righe version nel file.

D: Quali formati di pattern MX sono validi?

R: Nome esatto (mail.captaindns.com) o wildcard a etichetta singola in posizione leftmost (*.mail.captaindns.com). Nessun wildcard nudo, nessun doppio wildcard, nessun wildcard in mezzo a un nome.

D: Quali valori max_age sono raccomandati?

R: RFC 8461 impone 0 ≤ max_age ≤ 31557600 (1 anno). Valori comuni: 86400 (1 giorno) per la fase di testing, 604800 (1 settimana) per produzione stabile, 31557600 (1 anno) per una policy matura e fissa.

D: Come correggo un errore 'versione non valida'?

R: La versione deve essere esattamente STSv1 (case-sensitive) nel TXT (v=STSv1) e nella policy (version: STSv1). Controlli maiuscole/minuscole, spazi e l'assenza di caratteri parassiti.

D: Come valido la sintassi MTA-STS per Microsoft 365?

R: Incolli il Suo TXT e la Sua policy. Si assicuri che i Suoi pattern MX coprano *.mail.protection.outlook.com. Il validatore verifica la conformità RFC 8461 prima della pubblicazione DNS, poi utilizzi il record check dopo il deployment.

D: Come verifico la sintassi MTA-STS per Google Workspace?

R: Incolli il Suo TXT e la Sua policy. Gli MX Google sono a *.google.com (o aspmx.l.google.com). Si assicuri che i Suoi pattern corrispondano a questi hostname prima della pubblicazione.