← RFC Reference

RFC 7505: MX Nulo — Sin Servicio para el Dominio

Por qué existe

No todos los dominios reciben correo electrónico. Un dominio utilizado únicamente para un sitio web, una API, una CDN o un registro de protección de marca no necesita correo entrante. Pero antes de RFC 7505, no había una forma clara de declarar "este dominio no acepta correo" en DNS.

Sin una señal explícita, los servidores de envío que encuentren correo dirigido a un dominio sin correo harían:

• Retroceder al registro A/AAAA. Según RFC 5321, si no existe un registro MX, el remitente intenta entregar en la dirección A o AAAA del dominio. Este intento de conexión falla (no hay servidor SMTP escuchando), pero solo después de un tiempo de espera, típicamente 30+ segundos.
• Generar rebote de correo no deseado. Si un spammer falsifica una dirección de retorno en el dominio sin correo, la notificación de rechazo (DSN) se envía a la dirección falsificada. El registro A del dominio acepta la conexión TCP (es un servidor web), pero la conversación SMTP falla. El servidor de envío pone en cola reintentos durante horas o días.
• Desperdiciar recursos. Cada intento de entrega fallido consume consultas DNS, conexiones TCP y espacios de cola en el servidor de envío.

RFC 7505 introduce el registro Null MX: una entrada MX única con preferencia 0 y un destino de . (el dominio raíz). Esto le dice a cualquier servidor de envío: "Este dominio no tiene servicio de correo. No lo intentes."

Cómo funciona

El registro Null MX

El registro tiene dos características definitorias:

• Preferencia 0: La prioridad más baja posible, asegurando que este registro se procese primero (y, dado que es el único MX, último).
• Destino . (punto): La etiqueta raíz de DNS. No es un nombre de host válido y no se puede resolver en una dirección IP. Es el equivalente de DNS a /dev/null.

Comportamiento del remitente

Cuando un servidor de envío busca los registros MX de un dominio de destinatario y encuentra un Null MX:

1. Reconoce el destino . como un Null MX.
2. Genera inmediatamente un fallo permanente (5.1.0 — "Otro estado de dirección") sin intentar ninguna conexión SMTP.
3. El remitente devuelve un rechazo al remitente original (o descarta el mensaje si era un rechazo en sí).

Contraste: Sin Null MX

Sin un Null MX, esto es lo que sucede cuando se envía correo a un dominio sin registros MX:

Detalles técnicos clave

Reglas para Null MX

• El Null MX debe ser el único registro MX del dominio. No puedes mezclar un Null MX con registros MX reales.
• El valor de preferencia debe ser 0.
• El destino debe ser exactamente . (un punto único, la raíz de DNS).
• Si un remitente encuentra un Null MX, no debe retroceder a registros A/AAAA. El Null MX es definitivo.

Combinado con SPF y DMARC

Para dominios que no envían ni reciben correo electrónico, Null MX debe ser parte de una configuración DNS completa de "sin correo":

Esta combinación proporciona protección integral: Null MX detiene los intentos de entrega entrante, SPF -all le dice a los receptores que rechacen correo saliente falsificado, y DMARC p=reject aplica la política con informes.

Códigos de respuesta SMTP

Impacto en SMTP VRFY y EXPN

Si se le pide a un servidor que verifique o expanda una dirección en un dominio Null MX, debe devolver un fallo permanente. No hay direcciones de destinatario válidas en un dominio que no acepta correo.

Errores comunes

• Mezclar Null MX con registros MX reales. Un Null MX debe ser el único registro MX. Agregar MX 0 . junto a MX 10 mail.example.com crea una configuración inválida. Algunos resolvers pueden ignorar el Null MX; otros pueden rechazar todo el correo.
• Usar Null MX en un dominio que envía correo electrónico. Null MX solo afecta el correo entrante. Pero muchos servicios usan el mismo dominio para enviar y recibir. Si configuras Null MX en tu dominio de envío, no recibirás rechazo, notificaciones de estado de entrega o respuestas a tus mensajes.
• Olvidar SPF y DMARC. Null MX previene la entrega entrante, pero no hace nada para evitar que alguien falsifique el dominio como remitente. Siempre combina Null MX con v=spf1 -all y v=DMARC1; p=reject.
• Usar MX 0 localhost en lugar de Null MX. Algunos administradores usan un nombre de host falso en lugar de .. Esto no funciona como un Null MX. Los remitentes intentarán resolver "localhost" y pueden conectarse a su propia interfaz de loopback, creando bucles de correo.
• No aplicar a subdominios. Si example.com tiene registros MX apropiados pero unused.example.com no, configura Null MX en el subdominio explícitamente. Los subdominios no heredan registros MX de dominios padre.
• Asumir que todos los remitentes soportan Null MX. RFC 7505 es bien soportado por MTAs principales (Postfix, Exim, sendmail, Exchange), pero algunos sistemas más antiguos o de nicho pueden no reconocerlo e intentarán retroceder a búsquedas A/AAAA de todas formas.

Impacto en la entregabilidad

• Procesamiento de rechazos más rápido. Cuando un remitente encuentra Null MX, lo rechaza inmediatamente en lugar de poner en cola reintentos durante horas o días. Esto reduce la presión de cola en la infraestructura de envío y proporciona retroalimentación más rápida al remitente original.
• Elimina rebote de correo no deseado. Los spammers que falsifican direcciones de ruta de retorno en dominios Null MX no activarán intentos de entrega. Esto protege el dominio de ser enterrado en rebotes mal dirigidos y protege a los servidores de envío de desperdiciar recursos en rebote de correo no deseado no entregable.
• Protección de marca para dominios estacionados. Las organizaciones que registran múltiples dominios para protección de marca pueden configurar Null MX + SPF + DMARC en cada dominio no utilizado, impidiendo que se exploten para phishing.
• Reduce carga de DNS y red. Sin Null MX, un servidor de envío puede hacer múltiples intentos de conexión durante horas antes de rendirse. Null MX elimina todos esos intentos con una única consulta DNS.
• Infraestructura de envío limpia. Para proveedores de servicios de correo electrónico, Null MX reduce el volumen de correo no entregable en colas de envío, liberando recursos para entrega legítima y mejorando el rendimiento general.

Related RFCs