Comprobador MX:
¿responde tu servidor de correo?

Escribe tu dominio arriba. Consultamos sus registros MX, los ordenamos por prioridad, resolvemos cada nombre de host a IPv4 e IPv6, ejecutamos el viaje de ida y vuelta FCrDNS en cada dirección, identificamos el proveedor de correo a partir del patrón y luego conectamos con cada servidor por el puerto 25 desde nuestra red de sondas — leyendo el banner SMTP y probando STARTTLS. Gratis, sin registro, unos segundos de principio a fin.

Número más bajo = se prueba primero. Los remitentes suben por la lista solo cuando los hosts de mejor prioridad no responden. Las prioridades iguales no son un error — son balanceo de carga round-robin, y los grandes proveedores las usan (el conjunto clásico de Google tiene dos hosts en 5 y dos en 10). El problema con las configuraciones multinivel no son los números — el nivel de respaldo corre software más antiguo y un filtrado más laxo, que es exactamente por lo que los spammers apuntan ahí.

DNS inverso confirmado hacia delante: la IP de tu servidor de correo debe tener un registro PTR, y el nombre de ese PTR debe resolver de vuelta a la misma IP. Es una prueba barata de que quien controla la IP también controla el nombre — los cañones de spam en rangos secuestrados normalmente no pueden conseguirlo. Las directrices de remitentes de Google exigen un PTR válido y coincidente para entregar a Gmail, y la mayoría de los filtros lo puntúan. Y antes de que lo archives como «solo saliente»: tu servidor MX también envía — cada rebote, cada respuesta de ausencia, cada reenvío. Un viaje de ida y vuelta roto en el servidor de entrada penaliza en silencio todo eso.

Un único MX con preferencia 0 y la raíz como host — 0 . — definido por la RFC 7505. Es la forma estándar de declarar «este dominio no acepta correo». Los remitentes lo ven y devuelven un rebote permanente en segundos, en vez de recurrir a la regla del MX implícito y machacar tu servidor web con reintentos durante días. Es el registro correcto para dominios aparcados o solo-web — combinado con v=spf1 -all y una política DMARC de reject para que tampoco nadie pueda enviar en nombre del dominio.

Sorprendentemente, sí. La regla del MX implícito de la RFC 5321 dice que cuando no existe ningún MX, los remitentes tratan el registro A/AAAA del dominio como un MX con preferencia 0 — así que el correo se entrega a lo que sea que responda en la IP de tu servidor web. Si ese servidor resulta tener un MTA corriendo, el correo fluye; hay gente que lleva años con el correo en producción sobre este accidente. Es frágil — mueves el sitio web, pierdes el correo — y casi nunca es intencionado. Publica registros MX explícitos para correo real, o 0 . si no vas a recibir ninguno.

No — y es una confusión habitual. El MX responde a «adónde va el correo dirigido a este dominio»; tu reputación de salida vive en la IP de envío, SPF, DKIM y DMARC, que nuestras herramientas hermanas califican una por una. Dos excepciones: si te autoalojas, el servidor MX es el servidor de envío, así que su higiene de FCrDNS y TLS cuenta doble; y algunos receptores comprueban que un dominio que envía correo también pueda recibirlo — un conjunto MX roto falla esa comprobación en silencio.

La sonda abre una conexión TCP con cada host MX por el puerto 25, lee el banner de saludo, envía EHLO y comprueba si se ofrece STARTTLS — luego lo negocia y registra la versión de TLS y el certificado. No envía correo: la conversación se detiene antes de MAIL FROM. No puedes hacer esto desde una conexión doméstica porque los ISP residenciales bloquean el puerto 25 saliente para combatir el spam de botnets. Una salvedad que conviene saber: STARTTLS en el puerto 25 es oportunista — un atacante en la ruta puede eliminar el ofrecimiento. MTA-STS es el candado; nuestro comprobador de versiones TLS recorre cada versión del protocolo que hablará tu servidor.