Verifica MX:
il tuo server di posta risponde?

Digita il tuo dominio qui sopra. Interroghiamo i suoi record MX, li ordiniamo per priorità, risolviamo ogni hostname in IPv4 e IPv6, eseguiamo il round trip FCrDNS su ogni indirizzo, identifichiamo il provider di posta dallo schema, e poi ci colleghiamo a ogni server sulla porta 25 dalla nostra rete di sonde — leggendo il banner SMTP e verificando STARTTLS. Gratis, senza registrazione, pochi secondi dall'inizio alla fine.

Numero più basso = tentato per primo. I mittenti risalgono la lista solo quando gli host con priorità migliore non rispondono. Priorità uguali non sono un errore — sono bilanciamento round-robin, e i grandi provider le usano (il set classico di Google ha due host a 5 e due a 10). Il problema delle configurazioni multi-livello non sono i numeri — il livello di backup gira su software più vecchio e filtri più permissivi, ed è esattamente per questo che gli spammer lo prendono di mira.

Forward-confirmed reverse DNS: l'IP del tuo server di posta deve avere un record PTR, e il nome di quel PTR deve risolversi di nuovo allo stesso IP. È una prova economica che chi controlla l'IP controlla anche il nome — i cannoni di spam su range dirottati di solito non riescono a gestirlo. Le linee guida per i mittenti di Google rendono un PTR valido e corrispondente un requisito obbligatorio per consegnare a Gmail, e la maggior parte dei filtri lo valuta. E prima di archiviarlo come “solo in uscita”: anche il tuo host MX invia — ogni bounce, ogni risposta di assenza, ogni inoltro. Un round trip rotto sul server in ingresso penalizza silenziosamente tutto questo.

Un singolo MX con preferenza 0 e la root come host — 0 . — definito dalla RFC 7505. È il modo standard per dichiarare “questo dominio non accetta posta.” I mittenti lo vedono e restituiscono un bounce permanente in pochi secondi, invece di ricadere sulla regola MX implicita e martellare il tuo server web con tentativi per giorni. È il record giusto per i domini parcheggiati e solo-web — abbinato a v=spf1 -all e a un criterio DMARC reject, così nessuno può nemmeno inviare a nome del dominio.

Sorprendentemente, sì. La regola MX implicita della RFC 5321 dice che quando non esiste nessun MX, i mittenti trattano il record A/AAAA del dominio come un MX con preferenza 0 — quindi la posta viene consegnata a qualunque cosa risponda sull'IP del tuo server web. Se quel server per caso esegue un MTA, la posta scorre; c'è chi tiene la posta di produzione su questo incidente per anni. È fragile — sposti il sito, perdi la posta — e raramente è intenzionale. Pubblica record MX espliciti per la posta vera, oppure 0 . se non ne vuoi.

No — ed è un equivoco comune. L'MX risponde a “dove va la posta indirizzata a questo dominio”; la tua reputazione in uscita vive nell'IP di invio, in SPF, DKIM e DMARC, che i nostri strumenti gemelli valutano uno per uno. Due eccezioni: se fai self-hosting, il server MX è anche il server di invio, quindi la sua igiene di FCrDNS e TLS conta doppio; e alcuni receiver verificano che un dominio che invia posta possa anche riceverla — un set MX rotto fallisce questo controllo in silenzio.

La sonda apre una connessione TCP a ogni host MX sulla porta 25, legge il banner di benvenuto, invia EHLO e verifica se STARTTLS viene offerto — poi lo negozia e registra la versione TLS e il certificato. Non invia posta: la conversazione si ferma prima di MAIL FROM. Non puoi farlo da una connessione domestica perché gli ISP residenziali bloccano la porta 25 in uscita per contrastare lo spam da botnet. Un avvertimento da tenere a mente: STARTTLS sulla porta 25 è opportunistico — un attaccante on-path può rimuovere l'offerta. MTA-STS è il lucchetto; il nostro TLS Version Checker percorre ogni versione del protocollo che il tuo server è disposto a parlare.