MTA-STS non funziona? Guida completa alla risoluzione dei problemi

Q: Perché la mia policy MTA-STS non viene recuperata?

Il file mta-sts.txt deve essere accessibile all'URL esatto https://mta-sts.captaindns.com/.well-known/mta-sts.txt . Verifica che il sottodominio mta-sts risolva correttamente (CNAME o A record), che il certificato TLS sia valido e che il server risponda con un codice 200 e il Content-Type text/plain . I redirect HTTP verso HTTPS non sono accettati da tutti i client.

Q: Cosa significa l'errore 'MX non coperto dalla policy'?

Il tuo server MX reale non corrisponde a nessun pattern mx: nel file di policy. Ad esempio, se il tuo MX è captaindns-com.mail.protection.outlook.com ma la policy contiene mx: mail.protection.outlook.com (senza wildcard), il server mittente considera che il MX non è autorizzato. Aggiungi il wildcard: mx: *.mail.protection.outlook.com .

Q: Perché la modalità enforce blocca le email?

In modalità enforce , i server mittenti rifiutano l'invio se la policy MTA-STS non può essere soddisfatta (certificato non valido, MX non coperto, policy inaccessibile). Torna immediatamente in modalità testing , aggiorna il campo id del record DNS e analizza i report TLS-RPT per identificare la causa esatta prima di tornare in enforce.

Di CaptainDNS
Pubblicato il 9 febbraio 2026

Risoluzione dei problemi MTA-STS: diagnostica e correzione degli errori comuni

TL;DR

Verifica prima di tutto i tre fondamentali: record DNS _mta-sts, file di policy accessibile in HTTPS e certificato TLS valido sul sottodominio mta-sts
L'errore sts-policy-fetch-error significa che il file mta-sts.txt è inaccessibile — verifica l'hosting, il DNS e il certificato del sottodominio
I report TLS-RPT identificano con precisione il tipo di errore (certificate-expired, validation-failure, sts-webpki-invalid) per guidare la diagnostica
In caso di emergenza con la modalità enforce, torna immediatamente in testing e aggiorna il campo id del record DNS

Hai implementato MTA-STS sul tuo dominio seguendo tutti i passaggi: record DNS pubblicato, file di policy ospitato, TLS-RPT attivato. Eppure i report segnalano errori, il verificatore mostra problemi, o peggio ancora, le email vengono rifiutate in modalità enforce.

MTA-STS coinvolge diversi componenti che devono funzionare insieme: un record DNS TXT, un file di policy servito in HTTPS su un sottodominio specifico, certificati TLS validi e pattern MX che corrispondano esattamente ai tuoi server. Un singolo anello debole è sufficiente a rompere la catena.

Questa guida alla risoluzione dei problemi copre gli errori più frequenti, le loro cause e i comandi per diagnosticarli. Che tu utilizzi Microsoft 365, Google Workspace o Cloudflare per l'hosting, troverai la soluzione al tuo problema. Se non hai ancora implementato MTA-STS, consulta prima la nostra guida completa MTA-STS.

Diagnostica rapida: verificare la configurazione MTA-STS

Prima di cercare un problema specifico, verifica questi tre fondamentali nell'ordine indicato. La maggior parte dei problemi MTA-STS deriva da uno di questi tre punti.

Passaggio 1: Verificare il record DNS _mta-sts

Il record TXT su _mta-sts.captaindns.com deve esistere e contenere un valore valido:

dig TXT _mta-sts.captaindns.com +short
# Risultato atteso: "v=STSv1; id=20260208120000"

Problemi comuni:

Nessun risultato → il record non esiste o non si è ancora propagato
v=STS1 invece di v=STSv1 → errore di battitura nella versione
Assenza del campo id → campo obbligatorio mancante

Passaggio 2: Verificare il file di policy

Il file deve essere accessibile all'URL esatto https://mta-sts.captaindns.com/.well-known/mta-sts.txt:

curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Verifiche:

Codice HTTP 200 (non 301, 302, 403 o 404)
Content-Type text/plain (non text/html)
Contenuto valido con version: STSv1, mode:, mx: e max_age:
Nessun redirect HTTP → HTTPS (il server deve rispondere direttamente in HTTPS)

Passaggio 3: Verificare il certificato TLS

Il sottodominio mta-sts.captaindns.com deve avere un certificato TLS valido:

openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Verifiche:

Il certificato non è scaduto (notAfter nel futuro)
Il certificato copre mta-sts.captaindns.com (nel CN o SAN)
La catena dei certificati è completa (nessun errore unable to verify)

Checklist di diagnostica MTA-STS: record DNS, file di policy e certificato TLS

Errori comuni e soluzioni

Errore "Policy not found" (sts-policy-fetch-error)

È l'errore più frequente nei report TLS-RPT. Significa che il server mittente non è riuscito a recuperare il tuo file di policy.

Causa	Comando di diagnostica	Soluzione
File assente	`curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Creare e ospitare il file
DNS mal configurato	`dig A mta-sts.captaindns.com +short`	Verificare il CNAME o A record
Redirect HTTP	`curl -v http://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Configurare HTTPS direttamente
Certificato non valido	`curl -vI https://mta-sts.captaindns.com/`	Rinnovare o correggere il certificato
Cloudflare in pausa	Verificare la dashboard Cloudflare	Riattivare il proxy o il Worker

Errore "Certificate mismatch" (certificate-host-mismatch)

Il certificato TLS di un server MX non corrisponde al nome host MX. Non si tratta del certificato del sottodominio mta-sts, ma di quello del server MX stesso.

# Verificare il certificato di un server MX
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Con Microsoft 365 o Google Workspace: questo problema non dovrebbe verificarsi perché Microsoft e Google gestiscono i certificati dei propri MX. Se lo riscontri, verifica che i pattern MX nella policy corrispondano ai tuoi MX reali.

Errore "MX not covered by policy"

Il server MX del tuo dominio non corrisponde a nessun pattern mx: nel file di policy. Spesso è un errore di wildcard.

# Elencare i tuoi MX
dig MX captaindns.com +short

# Confrontare con la policy
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt | grep "^mx:"

Cause comuni:

Situazione	Pattern errato	Pattern corretto
Microsoft 365	`mx: mail.protection.outlook.com`	`mx: *.mail.protection.outlook.com`
Google Workspace	`mx: *.google.com` (solo)	`mx: .google.com` + `mx: .googlemail.com`
MX personalizzato	Pattern wildcard troppo restrittivo	Verificare ogni MX individualmente

Errore "Certificate expired" (certificate-expired)

Un certificato TLS è scaduto su uno dei tuoi server MX o sul sottodominio mta-sts.

# Verificare la data di scadenza del certificato mta-sts
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -enddate

Se si tratta del sottodominio mta-sts: rinnova il certificato tramite il tuo provider di hosting (Cloudflare lo fa automaticamente). Se si tratta di un server MX: con Microsoft 365 o Google Workspace, il rinnovo è automatico. Per un MX self-hosted, rinnova il certificato tramite Let's Encrypt o la tua autorità di certificazione.

Errore "Validation failure" (validation-failure)

La catena dei certificati è incompleta: manca il certificato root o un certificato intermedio.

# Testare la catena completa
openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>&1 | grep "Verify return code"
# Risultato atteso: Verify return code: 0 (ok)

Se il codice di ritorno non è 0, installa i certificati intermedi mancanti sul tuo server.

Problemi specifici per provider

Microsoft 365

Problema	Causa	Soluzione
MX non coperto	Pattern senza wildcard	Utilizzare `mx: *.mail.protection.outlook.com`
Report TLS-RPT vuoti	M365 invia i report con ritardo	Attendere 48-72h dopo l'attivazione
Certificato MX in errore	Raro (gestito da Microsoft)	Contattare il supporto Microsoft

Google Workspace

Problema	Causa	Soluzione
MX parzialmente coperti	Un solo pattern `mx:`	Aggiungere `mx: .google.com` E `mx: .googlemail.com`
Report TLS-RPT incompleti	Google aggrega su 24h	Attendere il report completo del giorno successivo
Cambio di MX Google	Migrazione verso nuovi MX	Verificare i MX attuali con `dig MX`

Cloudflare Pages / Workers

Problema	Causa	Soluzione
404 su mta-sts.txt	Percorso errato nel repository	Il file deve essere in `.well-known/mta-sts.txt`
Certificato TLS assente	Dominio personalizzato non configurato	Aggiungere `mta-sts.captaindns.com` in Custom Domains
Worker non risponde	Route mal configurata	Verificare che la route `mta-sts.captaindns.com/*` sia attiva
Content-Type errato	Worker restituisce `text/html`	Forzare `Content-Type: text/plain` nella Response
DNS non risolto	CNAME mancante	Aggiungere il CNAME verso il progetto Pages o l'AAAA `100::` per Workers

Leggere e interpretare i report TLS-RPT

I report TLS-RPT inviati dai provider email contengono i dettagli degli errori TLS. Ecco come leggerli.

Struttura di un report TLS-RPT

Un report JSON tipico contiene:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-08T23:59:59Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 150,
      "total-failure-session-count": 2
    },
    "failure-details": [{
      "result-type": "certificate-host-mismatch",
      "sending-mta-ip": "209.85.220.41",
      "receiving-mx-hostname": "captaindns-com.mail.protection.outlook.com",
      "failed-session-count": 2
    }]
  }]
}

Tabella di corrispondenza degli errori TLS-RPT

Codice TLS-RPT	Significato	Gravità	Azione
`starttls-not-supported`	Il MX non supporta STARTTLS	Critica	Attivare TLS sul server MX
`certificate-host-mismatch`	Il certificato non corrisponde al MX	Alta	Verificare il SAN del certificato
`certificate-expired`	Certificato scaduto	Alta	Rinnovare immediatamente
`certificate-not-trusted`	Certificato autofirmato o CA sconosciuta	Alta	Utilizzare un certificato di una CA riconosciuta
`validation-failure`	Catena dei certificati incompleta	Alta	Installare i certificati intermedi
`sts-policy-fetch-error`	File mta-sts.txt inaccessibile	Alta	Verificare l'hosting
`sts-policy-invalid`	Contenuto della policy non valido	Alta	Correggere la sintassi
`sts-webpki-invalid`	Certificato del sottodominio mta-sts non valido	Alta	Rinnovare il certificato

Flusso di diagnostica degli errori TLS-RPT: dall'errore alla soluzione

La modalità enforce blocca le email: cosa fare?

Se sei passato alla modalità enforce e le email legittime vengono rifiutate, agisci immediatamente:

1. Ritorno d'emergenza alla modalità testing

Modifica il file di policy:

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

2. Aggiornare il record DNS

Cambia il campo id per forzare i server mittenti a riscaricare la policy:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260208180000"

3. Tempo di propagazione

I server mittenti memorizzano in cache la tua policy per la durata del max_age precedente. Se avevi max_age: 2592000 (30 giorni), alcuni server potrebbero non riscaricare la policy per 30 giorni. Per questo motivo è consigliato aumentare il max_age progressivamente:

Fase	max_age	Durata	Utilizzo
Testing iniziale	`86400`	24 ore	Permette un rollback rapido
Testing avanzato	`604800`	7 giorni	Dopo 2 settimane senza errori
Enforce prudente	`604800`	7 giorni	Prime settimane in enforce
Enforce stabile	`2592000`	30 giorni	Dopo 1 mese in enforce senza problemi

Comandi di diagnostica essenziali

Ecco i comandi da tenere a portata di mano per diagnosticare qualsiasi problema MTA-STS:

# 1. Verificare il record DNS MTA-STS
dig TXT _mta-sts.captaindns.com +short

# 2. Verificare il record TLS-RPT
dig TXT _smtp._tls.captaindns.com +short

# 3. Recuperare il file di policy
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 4. Verificare gli header HTTP del file di policy
curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 5. Elencare i server MX
dig MX captaindns.com +short

# 6. Verificare il certificato del sottodominio mta-sts
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -dates -subject

# 7. Testare la connessione STARTTLS su un MX
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Piano d'azione consigliato

Identifica il problema: Utilizza il verificatore MTA-STS CaptainDNS per una diagnostica automatica completa
Verifica i tre fondamentali: Record DNS, file di policy, certificato TLS (in questo ordine)
Consulta i report TLS-RPT: Il campo result-type ti indica esattamente cosa sta fallendo
Correggi il problema identificato: Segui le soluzioni della sezione corrispondente qui sopra
Valida la correzione: Utilizza il validatore di sintassi MTA-STS per confermare che la policy è corretta
Monitora per 48h: Verifica che i report TLS-RPT non segnalino più l'errore

Verifica subito la tua configurazione MTA-STS: Utilizza il nostro verificatore MTA-STS per diagnosticare il tuo dominio in pochi secondi.

FAQ

Perché la mia policy MTA-STS non viene recuperata?

Il file mta-sts.txt deve essere accessibile all'URL esatto https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Verifica che il sottodominio mta-sts risolva correttamente (CNAME o A record), che il certificato TLS sia valido e che il server risponda con un codice 200 e il Content-Type text/plain. I redirect HTTP verso HTTPS non sono accettati da tutti i client.

Cosa significa l'errore 'MX non coperto dalla policy'?

Il tuo server MX reale non corrisponde a nessun pattern mx: nel file di policy. Ad esempio, se il tuo MX è captaindns-com.mail.protection.outlook.com ma la policy contiene mx: mail.protection.outlook.com (senza wildcard), il server mittente considera che il MX non è autorizzato. Aggiungi il wildcard: mx: *.mail.protection.outlook.com.

Come correggere un errore di certificato TLS su MTA-STS?

Identifica prima quale certificato è in causa. Se si tratta del certificato del sottodominio mta-sts: rinnovalo tramite il tuo provider di hosting (Cloudflare lo rinnova automaticamente). Se si tratta del certificato di un server MX: con Microsoft 365 o Google Workspace, è gestito automaticamente. Per un MX self-hosted, verifica la catena dei certificati completa e la data di scadenza.

Perché la modalità enforce blocca le email?

In modalità enforce, i server mittenti rifiutano l'invio se la policy MTA-STS non può essere soddisfatta (certificato non valido, MX non coperto, policy inaccessibile). Torna immediatamente in modalità testing, aggiorna il campo id del record DNS e analizza i report TLS-RPT per identificare la causa esatta prima di tornare in enforce.

Come tornare in modalità testing in emergenza?

Modifica il file mta-sts.txt sostituendo mode: enforce con mode: testing. Aggiorna quindi il campo id del record DNS TXT _mta-sts con un nuovo timestamp. I server mittenti riscaricheranno la policy e smetteranno di rifiutare le email. Il ritardo dipende dal max_age precedente.

Come leggere un report TLS-RPT?

I report TLS-RPT sono file JSON inviati quotidianamente all'indirizzo specificato nel tuo record _smtp._tls. Il campo result-type indica il tipo di errore (certificate-expired, sts-policy-fetch-error, ecc.), receiving-mx-hostname identifica il server MX interessato e failed-session-count fornisce il numero di errori.

MTA-STS non funziona con Cloudflare Workers: cosa verificare?

Verifica che la route mta-sts.captaindns.com/* sia configurata nel Worker, che il DNS contenga un record AAAA mta-sts che punta a 100:: (proxied) e che il Worker restituisca il Content-Type text/plain; charset=utf-8. Testa con curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt per confermare il codice 200 e gli header.

Quanto tempo bisogna attendere prima che le correzioni abbiano effetto?

I server mittenti memorizzano in cache la tua policy per la durata del max_age. Se avevi max_age: 86400 (24h), la correzione sarà effettiva in massimo 24h. Se avevi max_age: 2592000 (30 giorni), alcuni server potrebbero non vedere la correzione per 30 giorni. Per questo motivo è consigliato mantenere un max_age breve nella fase di test.

Glossario

MTA-STS: Mail Transfer Agent Strict Transport Security. Standard RFC 8461 che impone la crittografia TLS per la ricezione delle email.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Meccanismo di report quotidiano sui successi e gli errori di negoziazione TLS.
sts-policy-fetch-error: Codice di errore TLS-RPT che indica che il file di policy mta-sts.txt non è stato recuperato dal server mittente.
max_age: Direttiva della policy MTA-STS che indica la durata del caching in secondi. Determina il ritardo di propagazione delle modifiche.
STARTTLS: Estensione SMTP che consente di crittografare la connessione tra server email. MTA-STS ne impone l'utilizzo con un certificato valido.

Guide MTA-STS correlate

Fonti

Articoli simili

CaptainDNS · 6 febbraio 2026

MTA-STS: proteggere il trasporto email con la crittografia TLS obbligatoria

MTA-STS: la guida completa per proteggere il trasporto delle tue email

MTA-STS (RFC 8461) impone la crittografia TLS per la ricezione delle email. Scopri come configurarlo, scegliere tra testing ed enforce e validare il tuo deployment.

CaptainDNS · 8 febbraio 2026

Configurare MTA-STS per Microsoft 365, Google Workspace e Cloudflare

Configurare MTA-STS per Microsoft 365 e Google Workspace

Tutorial passo dopo passo per implementare MTA-STS su Microsoft 365, Google Workspace e Cloudflare. Pattern MX, file di policy, hosting e validazione inclusi.

CaptainDNS · 3 febbraio 2026

Guida al delisting: come rimuovere un IP dalle blacklist email

Come rimuovere il tuo IP da una blacklist: la guida completa al delisting

Il tuo IP è in una blacklist e le tue email vengono rifiutate? Questa guida illustra le procedure di delisting per ogni blacklist principale, con i tempi di attesa e le best practice per evitare un nuovo listing.