Policy TLS forzata per la posta in entrata
DNS e record
Lookup DNS Tutti i record DNS per qualsiasi dominio Lookup record A Indirizzi IPv4 di un dominio Lookup record AAAA Indirizzi IPv6 di un dominio Lookup MX Server di posta di un dominio Lookup NS Name server autoritativi Lookup TXT Record TXT, SPF, verifica Lookup CNAME Record di nome canonico (alias) Lookup SOA Record Start of Authority Lookup SRV Record di localizzazione dei servizi Lookup CAA Quali CA possono emettere certificati DNS inverso (PTR) Da indirizzo IP a hostname Verifica DNSSEC Il dominio è firmato e validato? Diagnostica DNS Un report completo di delega e DNSRecapitabilità email
Verifica SPF Valida il tuo record Sender Policy Framework Verifica DMARC Esamina e valuta la tua policy DMARC Verifica DKIM Trova e valida la tua chiave pubblica DKIM Verifica blacklist Verifica un IP rispetto alle blocklist email (DNSBL) Test SMTP Connettiti a un server di posta e verifica STARTTLS Verifica MTA-STS Policy TLS forzata per la posta in entrata Verifica BIMI Record del logo del brand per l'email Verifica TLS-RPT Policy di reportistica SMTP TLSRete e web
Verifica certificato SSL Esamina il certificato TLS e la scadenza di un sito Verifica header HTTP Esamina header di risposta, redirect e sicurezza Ping (TCP) Raggiungibilità e latenza su TCP Verifica porte Quali porte comuni sono aperteDominio
Lookup WHOIS Dati di registrazione per domini, IP e ASNMTA-STS consente a un dominio di richiedere che la posta in entrata venga consegnata su TLS autenticato, difendendo da attacchi di downgrade e man-in-the-middle. IPeek legge il record TXT _mta-sts e recupera il file di policy pubblicato su mta-sts.tuo-dominio. Colma la lacuna lasciata dallo STARTTLS opportunistico, che un aggressore può rimuovere silenziosamente.
MTA-STS usa due componenti. Un record TXT su _mta-sts.tuo-dominio contiene una versione e un ID di policy che comunica ai server mittenti che una policy esiste e che cambia quando la aggiorni. La policy stessa risiede in un file di testo servito su HTTPS all'indirizzo https://mta-sts.tuo-dominio/.well-known/mta-sts.txt. Quel file elenca la versione, la modalità, gli hostname MX consentiti e una durata di caching max_age. Un mittente che supporta MTA-STS recupera e memorizza in cache la policy, poi rifiuta di consegnare a qualsiasi MX il cui certificato non si convalida rispetto a essa.
IPeek mostra se il record TXT _mta-sts esiste e se il file di policy è raggiungibile su HTTPS. Il valore della modalità è ciò che conta di più. none significa che nessuna policy è in vigore, testing significa che i fallimenti vengono segnalati ma la posta scorre comunque, ed enforce significa che un mittente deve interrompere la consegna se l'autenticazione TLS fallisce. Verifica che le voci mx nella policy corrispondano ai tuoi record MX reali e che il certificato HTTPS sull'host della policy sia valido. Un max_age elevato, spesso 604800 secondi, migliora la protezione perché le policy in cache resistono alla manomissione in tempo reale.
L'errore più comune è un record TXT esistente mentre il file di policy restituisce un 404 o un reindirizzamento, il che rende la policy inutilizzabile. L'host della policy deve servire HTTPS valido, quindi un certificato scaduto o non corrispondente su mta-sts.tuo-dominio interrompe del tutto l'applicazione. Voci mx che si disallineano dal tuo DNS causano fallimenti di consegna una volta passati a enforce. Esegui il rollout prima in testing, monitora i report TLS-RPT per i fallimenti, e passa a enforce solo dopo aver confermato che ogni MX presenta un certificato valido e corrispondente.
In modalità testing, i mittenti che rilevano un fallimento TLS consegnano comunque la posta ma segnalano il problema, permettendoti di individuare gli errori senza bloccare il traffico. In modalità enforce, un mittente deve interrompere la consegna a qualsiasi MX il cui certificato non si convalida. Parti da testing, osserva i tuoi report TLS-RPT e passa a enforce solo quando non compaiono più fallimenti.
Il file di policy è servito su HTTPS all'indirizzo https://mta-sts.tuo-dominio/.well-known/mta-sts.txt, su un sottodominio chiamato mta-sts. Il record DNS TXT su _mta-sts.tuo-dominio si limita ad annunciare che una policy esiste e ne trasporta un ID; le regole effettive, tra cui modalità e host MX consentiti, risiedono in quel file HTTPS. Entrambi devono essere presenti e validi perché MTA-STS funzioni.
STARTTLS è opportunistico: offre cifratura ma un aggressore di rete può rimuovere l'annuncio STARTTLS e forzare la consegna in chiaro, senza essere rilevato. MTA-STS aggiunge una policy pubblicata che comunica ai mittenti che TLS è obbligatorio e quali certificati MX considerare attendibili, così una connessione TLS rimossa o non valida fa fallire la consegna anziché degradarla silenziosamente. Irrobustisce STARTTLS contro gli attacchi di downgrade.
No. MTA-STS si basa deliberatamente su HTTPS e sulla PKI web per la sua fiducia, non su DNSSEC, il che lo rende più facile da implementare rispetto a DANE. Il certificato HTTPS del file di policy fornisce l'autenticazione. Se il tuo dominio ha già DNSSEC, puoi usare DANE insieme a MTA-STS, dato che i due meccanismi si completano anziché entrare in conflitto.
Pubblica prima il record TXT e il file di policy in modalità testing, poi abilita TLS-RPT così i server mittenti ti inviano via email i report di eventuali fallimenti TLS. Conferma che gli hostname MX nella policy corrispondano al DNS e che ogni MX presenti un certificato valido. Una volta che i report non mostrano fallimenti per un normale ciclo di reportistica, cambia la modalità in enforce e aggiorna l'ID della policy.