Validador de Dirección de Email y Registro MX
Valida una dirección de email y comprueba si su dominio puede recibir correo.
🌐 The domain is resolved server-side over DNS-over-HTTPS. Only the part after @ is looked up — the local part is never sent to a resolver, and no mail is sent.
Resumen
Se confunden dos preguntas distintas. «¿Está bien formada esta dirección?» se responde desde la cadena. «¿Llegará el correo enviado aquí?» se responde en parte desde el DNS. «¿Existe este buzón?» no se responde en absoluto sin enviar correo, y todo lo que afirme lo contrario está adivinando.
Esta herramienta responde a las dos primeras y lo dice con claridad sobre la tercera. Comprueba la sintaxis con las reglas que los servidores aplican en la práctica y luego resuelve el dominio para los registros MX, A/AAAA, SPF y DMARC — suficiente para distinguir una errata de un dominio que no puede recibir correo y de un dominio cuya autenticación está rota.
Cómo se usa
- Escriba o pegue una dirección.
- Lea los dos resultados principales: Syntax y Domain accepts mail.
- Lea las observaciones. Nombran el problema concreto en lugar de dar un veredicto.
Qué exige la comprobación de sintaxis
La RFC 5322 permite mucho más de lo que aceptan los sistemas de correo. Los comentarios entre paréntesis, las partes locales entre comillas con espacios y los espacios de plegado anidados son gramática legal que rechaza una parte considerable de los servidores reales. Un comprobador que acepte todo lo legal le dirá que una dirección está bien cuando va a rebotar.
Por eso las reglas aplicadas aquí son las prácticas:
- La parte local puede contener letras, dígitos y
!#$%&'*+-/=?^_`{|}~.— lo que incluye el apóstrofo, porque nombres comoo'[email protected]son reales, y+, porque el subdireccionamiento estilo Gmail se usa a diario. - Sin punto inicial, sin punto final, sin puntos consecutivos.
- La parte local está limitada a 64 caracteres y el dominio a 255, según la RFC 5321. Cada etiqueta del dominio está limitada a 63.
- El dominio debe ser un nombre de host válido con un TLD de al menos dos letras.
user@localhostse rechaza; solo tiene sentido dentro de una única máquina. - El no-ASCII debe ir en Punycode.
user@日本語.jpse rechaza en favor de su formaxn--, porque la entrega a la forma Unicode exige compatibilidad con SMTPUTF8 en todos los saltos.
Cómo leer el resultado del DNS
Los registros MX se listan por prioridad, de menor a mayor. Que haya varios es normal — son alternativas, y prioridades iguales reparten la carga.
El null MX (RFC 7505) es un único registro con prioridad 0 y host vacío.
Significa que el dominio no acepta correo de forma deliberada, y suprime el recurso
al MX implícito. Es la configuración correcta para un dominio usado solo para un
sitio web, y example.com la utiliza.
El MX implícito es la situación opuesta: no hay ningún registro MX, así que los remitentes recurren a la dirección A o AAAA. El dominio es técnicamente alcanzable y el resultado suele ser accidental. El correo llega a lo que haya en el puerto 25 del servidor web, es decir, a ningún sitio útil.
SPF se revisa buscando los fallos que rompen la entrega, no cuestiones de estilo.
Más de diez mecanismos con resolución DNS (include, a, mx, ptr, exists,
redirect) provoca un error permanente según la RFC 7208 §4.6.4 y la autenticación
falla sin más — un límite fácil de cruzar añadiendo un proveedor más. +all autoriza
a todo remitente de Internet y anula SPF por completo. ptr está obsoleto. Un
registro sin mecanismo all queda abierto, salvo que use redirect=, caso en el que
omitir all es lo correcto.
Dos registros SPF en un dominio también es un error permanente, y se informa porque
se presenta como un fallo de entrega intermitente e inexplicable. Ocurre siempre que
se añade el registro de un segundo proveedor junto al primero en lugar de integrarlo
con include:.
DMARC se lee de _dmarc.<dominio>. p=none se señala: solo recopila informes,
así que los fallos se registran y se entregan igualmente. Es el punto de partida
correcto y el lugar equivocado para detenerse.
Ejemplos
- Un formulario de registro que rechaza direcciones reales — compare su
validación con lo que se aplica aquí. Las expresiones regulares copiadas de
internet rechazan de forma habitual las etiquetas
+, los apóstrofos y los TLD largos. - «Nunca recibieron mi correo» — compruebe primero el dominio del destinatario. Un null MX o un MX ausente lo explica al instante y saca la conversación de su servidor.
- Auditar su propio dominio de envío — el número de resoluciones de SPF,
+ally un DMARC estancado enp=noneson los tres hallazgos que explican con más frecuencia que el correo acabe en spam. - Tras añadir un proveedor de correo — los proveedores le entregan un
include:y rara vez mencionan el techo de diez resoluciones. Compruebe el total, no la línea nueva. - Investigar un mensaje concreto — el analizador de encabezados de correo muestra la ruta de entrega y los veredictos SPF, DKIM y DMARC tal como los registró el destinatario, y el visor .eml abre un mensaje guardado. Esta herramienta responde a la pregunta antes de enviar; esas dos la responden después.
Notas
El DNS se resuelve mediante DNS-over-HTTPS con un tiempo de espera de cinco segundos por consulta. Si una consulta falla, los campos que habría rellenado se informan como ausentes y no como error, así que una resolución TXT lenta no descarta un resultado MX correcto.
El dominio solo se consulta si es un nombre de host válido. Una dirección que falla la comprobación estructural no genera tráfico DNS alguno.
La lista de dominios desechables cubre proveedores muy conocidos a modo de aviso, no
como autoridad — aparecen dominios nuevos constantemente y no estar en la lista no
significa nada. La comprobación de cuentas de rol es igualmente informativa: info@ y
admin@ son direcciones perfectamente válidas que simplemente no pertenecen a una
persona.
No se envía ningún correo, no se abre ninguna conexión SMTP, y la parte local de la dirección nunca se incluye en una consulta DNS. Véase la política de privacidad.