Dominio sin correo: la configuración Null MX
Por CaptainDNS
Publicado el 29 de agosto de 2026
- Publica un único MX con prioridad
0cuyo destino sea.: la ausencia de MX sigue activando un repliegue hacia la dirección A o AAAA. - Para el envío, usa el SPF desnudo
v=spf1 -ally DMARC conp=reject; sp=reject; np=reject. Coloca elruaen otro dominio que sí reciba correo. - No publiques ningún selector DKIM. Un
p=vacío revoca una clave antigua; no es la política de un dominio que no envía. - El análisis público muestra una recepción completa, pero una zona de referencia se queda en la banda Bueno, alrededor de 80-85 según
ruay DNSSEC.
Un dominio sin correo parece sencillo de administrar: ningún buzón, ningún servidor SMTP, así que aparentemente no hay nada que configurar. Ahí está justamente la trampa. Una zona que conserva los valores del registrador puede seguir conteniendo un MX por defecto. Un SPF demasiado amplio puede seguir autorizando a un antiguo proveedor. Sin política DMARC, los destinatarios no reciben ninguna consigna firme contra la suplantación.
Otro error frecuente: eliminar todos los MX y creer que la recepción queda cerrada. El protocolo SMTP previó un repliegue hacia las direcciones A o AAAA cuando no existe ningún MX. En el caso de un sitio web, ese repliegue apunta precisamente al servidor que sirve el sitio. Puede que responda mal o tarde, pero el remitente remoto habrá intentado igualmente entregarle correo.
La receta que sigue trata dos usos dentro de la misma zona de referencia: un sitio escaparate o una aplicación HTTPS sin ningún buzón, y luego un dominio defensivo sin sitio y sin certificado. Su base de correo es idéntica. Su CAA difiere, porque el primero debe seguir renovando su certificado mientras que el segundo debe prohibir toda emisión.
Comprueba la zona y genera tu política DMARC
El problema de una zona dejada por defecto
Un dominio sin correo debe anunciar explícitamente que no recibe ni envía nada. El silencio del DNS deja intactos los comportamientos de repliegue y las autorizaciones antiguas.
Empieza por inventariar la zona. Busca los MX añadidos por el registrador, los TXT SPF históricos, _dmarc, los selectores bajo _domainkey, las direcciones A y AAAA, y después los CAA. Un MX que apunta a una oferta de correo gratuita no es inofensivo: si alguien crea un buzón más adelante por error, el dominio vuelve a recibir. Un SPF que contiene include: sigue autorizando al servicio designado a presentar este dominio en el sobre SMTP.
Una zona sin DMARC también deja que cada destinatario decida por su cuenta qué hacer con un mensaje suplantado. SPF puede fallar, pero DMARC es la capa que conecta la autenticación con el dominio visible en la dirección From y publica una política. Para este caso cerrado el objetivo es claro: no existe ninguna fuente legítima, así que todo mensaje que diga venir del dominio debe ser rechazado.
El resultado esperado no es una colección de mecanismos de correo. Es una declaración negativa coherente: ningún destino de recepción, ningún emisor autorizado, una política de rechazo y ninguna clave DKIM inventada. Menos registros, pero cada uno con un sentido preciso.
Null MX cierra explícitamente la recepción
Un Null MX es un único registro MX con prioridad 0 cuyo destino es el nombre raíz .. El RFC 7505 lo define para anunciar que un dominio no acepta ningún correo.
La representación en la zona es corta:
example.com. IN MX 0 .
Según la interfaz DNS, el destino puede aparecer como un punto, un valor vacío o una opción específica "Null MX". El resultado publicado debe seguir siendo un solo MX con preferencia cero y un nombre de intercambio vacío. No añadas un segundo MX de respaldo: la presencia de otro destino contradice la declaración.
La ausencia de MX no significa lo mismo
Sin respuesta MX, un remitente SMTP puede probar la dirección A o AAAA del dominio como si fuera un intercambiador implícito. Este comportamiento histórico es la razón principal para publicar Null MX incluso en un dominio que no aloja ningún sitio web.
Con Null MX, el remitente entiende que la entrega es imposible y no prueba el servidor web. En el análisis de CaptainDNS, esta configuración obtiene la recepción completa. MTA-STS, DANE y TLS-RPT no hacen falta entonces: protegen un transporte SMTP que no existe, y el análisis concede los puntos correspondientes.
El matiz también cuenta cuando el dominio no tiene ni A ni AAAA. La ausencia de MX sigue siendo una ausencia, no una declaración Null MX. Publicar 0 . documenta la intención, resiste a la incorporación futura de una dirección web y ofrece a los remitentes una respuesta sin ambigüedad.
Cerrar el envío con SPF y DMARC
El SPF desnudo v=spf1 -all declara que ninguna dirección IP está autorizada a enviar en nombre del dominio. DMARC completa esa declaración con una política de rechazo para el dominio y sus subdominios.
Publica en el ápice:
example.com. IN TXT "v=spf1 -all"
Mantén ese valor tal cual. No añadas ni a, ni mx, ni include, ni un rango de IP. Cada uno de esos mecanismos reintroduciría un emisor autorizado. El calificador -all es un fallo rotundo; ~all expresaría solo un fallo blando, inútil cuando no hay ninguna fuente legítima que preservar. El generador SPF ayuda a revisar la sintaxis, pero aquí el valor final se reduce a dos elementos.
Publica después en _dmarc:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc@captaindns.com"
p=reject cubre el dominio organizativo. sp=reject aplica el rechazo a los subdominios existentes, y np=reject a los subdominios inexistentes cuando un destinatario admite esa etiqueta. Las alineaciones estrictas adkim=s y aspf=s encajan aquí: ningún flujo legítimo depende de una alineación relajada.
El informe rua cambia la nota
La etiqueta rua no es decorativa. Su ausencia cambia la nota DMARC en el análisis. Sirve para recibir los informes agregados que revelan las fuentes que presentan el dominio, aunque la política las rechace.
La dirección nunca debe pertenecer al dominio sin correo. rua=mailto:dmarc@example.com crearía una dirección huérfana: Null MX anuncia que example.com no recibe nada. Usa una dirección en otro dominio que reciba de verdad, como dmarc@captaindns.com, o un servicio de ingesta DMARC. El mismo principio vale para ruf si lo utilizas, y para la dirección iodef de un CAA.
Los informes externos pueden requerir una autorización DNS adicional en el dominio destinatario, según DMARC. Comprueba esa delegación con el proveedor elegido. La ingesta de CaptainDNS a 5 euros es un segundo nivel posible para centralizar esos informes; no es un requisito previo para lanzar el análisis gratuito.
DKIM: no publiques ningún selector
No existe un registro DKIM ideal que pegar en un dominio que no envía. La configuración correcta es la ausencia de todo selector bajo _domainkey.
DKIM autentica una firma que lleva un mensaje. Aquí no sale ningún mensaje legítimo. Publicar una clave RSA o Ed25519 "por si acaso" crearía una superficie de configuración sin uso. Publicar un valor vacío sería peor, porque su significado ya está definido.
El RFC 6376 describe una etiqueta p= vacía como la revocación de una clave publicada anteriormente. El firmante que conoce ese selector quiere que fallen las firmas que lo emplean. El mismo RFC precisa que un verificador no da un sentido distinto a una clave revocada y a un registro de clave suprimido: en ambos casos, ninguna validación DKIM tiene éxito. El RFC 5863 presenta ese valor vacío como una lápida útil al retirar un selector, para evitar su reutilización accidental.
Esto no crea una política general de "este dominio no envía". Un comodín *._domainkey con un p= vacío aplica la semántica de revocación a nombres de selector que nunca han existido. M3AAWG retiró esta antigua receta de su BCP de 2022: DKIM no es necesario para un dominio sin correo, y no debería publicarse ninguno.
El comportamiento de CaptainDNS sigue esta lectura. El análisis público deja DKIM y BIMI a cero, conserva sus recomendaciones y muestra después esta indicación cuando Null MX y el SPF desnudo están presentes: "Si este dominio no envía correo, DKIM y BIMI no son necesarios. La nota no cambia." Ese texto explica el caso; no maquilla la nota.
En la vigilancia, la casilla "Este dominio no envía correo" cambia la capa de evaluación. DKIM y BIMI salen entonces de la nota, y se emite una alerta si aparece un MX real o una clave DKIM. Las dos vistas son por tanto coherentes: la pública muestra las recomendaciones generales y la nota limitada; la vigilancia aplica la intención declarada del dominio.
Ninguna dirección huérfana en la zona
Todo URI mailto: publicado por un dominio sin correo debe apuntar a otro dominio capaz de recibir. Esta regla cubre DMARC, los avisos CAA y cualquier dirección operativa añadida más tarde.
Haz una búsqueda textual en la zona exportada. Los sitios habituales son rua, ruf e iodef. Una dirección de contacto en un registro TXT propio merece el mismo control. Si la parte derecha después de @ es el dominio que Null MX acaba de cerrar, el informe se perderá.
En un sitio sin correo, no confundas la dirección visible en una página web con la mensajería del dominio. Puedes mostrar una dirección alojada en otro dominio, o un formulario conectado a un sistema externo. El DNS del sitio sigue sin correo. En un dominio defensivo sin sitio, ninguna dirección local tiene razón de existir.
Esta separación evita una contradicción discreta: pedir a las autoridades de certificación o a los receptores DMARC que envíen un informe a un destino que el DNS declara inexistente. La política de seguridad parecería completa en un archivo de zona, pero nadie leería sus alertas.
Dos casos, una base de correo y dos políticas CAA
El sitio HTTPS y el dominio sin sitio comparten Null MX, SPF y DMARC. Su diferencia está en A/AAAA y en la autorización para emitir un certificado.
| Elemento | Sitio sin correo | Dominio sin sitio |
|---|---|---|
| A / AAAA | Presentes según el alojamiento | Ausentes |
| MX | 0 . | 0 . |
| SPF | v=spf1 -all | v=spf1 -all |
| DMARC | p=reject; sp=reject; np=reject | p=reject; sp=reject; np=reject |
| DKIM | Ningún selector | Ningún selector |
| CAA | CA utilizada realmente, más iodef externo | 0 issue ";" |
| Certificado | Permitido y renovable | Prohibido |
CAA para el sitio HTTPS
Un sitio debe autorizar la CA que emite realmente su certificado. Añade también un destino iodef situado en otro dominio receptor. Una política completa puede obtener 100 en el control CAA del pilar DNS, sin que la nota global alcance la banda superior a causa de DKIM.
example.com. IN CAA 0 issue "ca.example.com"
example.com. IN CAA 0 iodef "mailto:security@captaindns.com"
Adapta el identificador a tu CA. Sobre todo, no publiques issue ";" en este sitio: prohibirías la emisión y la próxima renovación podría fallar. La guía CAA detalla la herencia, issuewild y los parámetros ACME.
CAA para el dominio sin certificado
Un dominio sin sitio, sin A/AAAA y sin certificado puede prohibir cualquier CA:
example.com. IN CAA 0 issue ";"
En el análisis de CaptainDNS, esta opción vale 90 para CAA, no 100. Esa diferencia refleja la ausencia de canal iodef, mientras que un dominio cerrado no debe publicar un mailto: local. Nombrar una CA no es una variante intercambiable: reabriría la emisión de certificados.
DNSSEC también protege el sitio de una caída silenciosa
DNSSEC firma las respuestas DNS y permite al resolutor detectar su falsificación. Una cadena rota invalida el dominio ante los resolutores validadores, aunque los registros sigan presentes en el alojamiento.
Para el sitio sin correo, es el único elemento de esta receta que puede dejar el sitio web silenciosamente inaccesible tras una rotación mal hecha. Un DS obsoleto en el registrador, una KSK retirada demasiado pronto o unas firmas caducadas provocan a menudo SERVFAIL. El navegador no dirá "DNSSEC roto"; solo mostrará un error de resolución.
Despliega DNSSEC comprobando la cadena entre la zona hija y la zona padre. Al cambiar de proveedor DNS, coordina las claves y el DS antes de retirar la zona antigua. La guía de activación de DNSSEC cubre esa secuencia.
En el dominio sin sitio, un fallo de DNSSEC no rompe ninguna página web inexistente, pero impide a los destinatarios leer Null MX, SPF y DMARC. La protección contra la suplantación sigue dependiendo, por tanto, de una cadena válida. Vigílala como cualquier otro registro de seguridad.
Lo que mostrará el análisis público
El análisis público evalúa tres pilares: envío 50, recepción 35 y DNS 15. Una zona sin correo bien ajustada obtiene Bueno, normalmente alrededor de 80-85 según la presencia de rua y DNSSEC.
La recepción es completa con un único Null MX. MTA-STS, DANE y TLS-RPT no se piden, ya que el dominio no recibe correo. Al contrario, MXCount == 0 es un error: el repliegue hacia A sigue siendo posible y el cierre no está declarado.
Del lado del envío, el SPF estricto y DMARC reject marcan claramente la ausencia de fuente legítima. Aun así, DKIM y BIMI se quedan a cero en la herramienta pública, con sus recomendaciones. La indicación mostrada explica que esos mecanismos no son necesarios si el dominio no envía y que la nota no cambia. Resultado: la banda superior, a partir de 90, sigue siendo inalcanzable sin DKIM. Es deliberado y visible.
El pilar DNS depende sobre todo de CAA y DNSSEC. El sitio puede obtener el control CAA completo con una CA autorizada y un iodef externo. El dominio sin certificado obtiene 90 en ese control con issue ";". Estas cifras son subnotas de controles, no una promesa de nota global.
La vigilancia cambia únicamente la intención de correo
La casilla "Este dominio no envía correo" es una función de vigilancia. Retira DKIM y BIMI de la nota vigilada y alerta si la zona vuelve a aceptar o firmar correo.
No fabrica una captura halagadora en el análisis público. No cambia ni la necesidad de Null MX, ni SPF, ni DMARC, ni CAA, ni DNSSEC. Su interés es operativo: si un administrador añade un MX real o si reaparece un antiguo selector DKIM, la vigilancia señala que el contrato "sin correo" acaba de romperse.
La primera herramienta de CaptainDNS es gratuita. Empieza por el análisis de la zona, corrige los registros y activa después una vigilancia si el dominio merece una alerta continua. El monitor cuesta 5 euros. Las demás herramientas siguen la tarificación de la cuenta, 3 euros y luego 5 euros, sin oferta aparte dedicada a este caso.
Divergencias entre las recomendaciones publicadas
Las guías disponibles en línea no dan todas la misma receta. Nos quedamos con los textos más recientes y con la semántica de los RFC, y señalamos las diferencias en lugar de ocultarlas.
GOV.UK todavía recomienda un comodín _domainkey que contiene un p= vacío en su página actualizada el 1 de marzo de 2021. EasyDMARC y Mimecast también retoman el BCP de M3AAWG de 2015. No copiamos ese valor: M3AAWG lo retiró en su edición de junio de 2022, mientras que los RFC lo definen como la revocación de una clave antigua. La ausencia de selector es más exacta y no dispara la recomendación crítica dkim.empty_p_tag de nuestro propio análisis.
La condición "Null MX solo si existe un A o AAAA" pertenece a la edición de diciembre de 2015: "M3AAWG recommends the use of a null MX record only if the domain has an A and/or AAAA record", por compatibilidad con los receptores que aún no habían implementado el RFC. La edición de junio de 2022 retiró esa restricción, y su ejemplo "Single Parked Domain", sin A ni AAAA, publica efectivamente example.com. MX 0 .. Seguimos el texto de 2022 y publicamos en ambos casos: ningún MX sigue significando "ningún MX", no "rechazo explícito", y una futura dirección A reactivaría el repliegue SMTP.
internet.nl también recomienda Null MX para un dominio sin servidor de correo y considera varias pruebas de correo como no aplicables a este perfil. CaptainDNS conserva una lectura pública uniforme de los tres pilares: la zona sale Bueno alrededor de 80-85, no en la banda superior. Las dos interfaces describen el mismo objetivo con modelos de puntuación distintos.
Lo que este artículo no es
Esta guía describe una zona que no envía ni recibe correo. No sustituye al generador DMARC, que compone una política según tus opciones, ni al análisis, que lee las respuestas DNS realmente publicadas.
Tampoco es una guía de remitente. No cubre ni la rotación de claves, ni los selectores de los proveedores, ni la entregabilidad de una campaña. Los artículos dedicados a DKIM conservan ese papel. Aquí, añadir una plataforma de envío cambia la necesidad: el dominio deja de estar sin correo y hay que revisar la receta.
El CAA solo se trata en el punto de decisión entre certificado permitido y certificado prohibido. Su herencia y sus variantes pertenecen a la guía CAA. DNSSEC se limita al riesgo de cadena rota; el tutorial completo sigue aparte. Por último, la conservación y la caducidad de los nombres corresponden al ciclo de vida de un dominio, no a la configuración de correo.
Verificación final de la zona
Una zona coherente se comprueba desde el exterior, tras la propagación. Verifica que solo hay visible un MX 0 ., que SPF no contiene más que v=spf1 -all y que _dmarc publica el rechazo esperado.
Busca después cualquier nombre bajo _domainkey: no debe quedar nada, salvo una clave antigua en curso de retirada según un plan fechado. Controla que cada mailto: apunte a otro dominio receptor. Termina con CAA, DNSSEC y los posibles A/AAAA.
Relanza el análisis después del TTL. Espera Bueno y lee las recomendaciones que siguen mostrándose para DKIM y BIMI a la luz de esa indicación. Si activas la vigilancia "Este dominio no envía correo", prueba también la alerta durante una modificación planificada y vuelve luego a la zona de referencia.
FAQ
¿Qué diferencia hay entre Null MX y la ausencia de MX?
Null MX publica un MX explícito con prioridad 0 y destino .. Sin MX, un remitente SMTP puede replegarse hacia A o AAAA; las dos configuraciones no son equivalentes.
¿Hay que publicar un DKIM?
No. No publiques ningún selector bajo _domainkey. Un p= vacío sirve solo para retirar una clave antigua; no es un modelo para declarar que un dominio no envía.
¿Por qué mantener un rua si el dominio no envía?
Los informes agregados revelan las fuentes que intentan usar el dominio, y la ausencia de la etiqueta rua cambia la nota DMARC. Envíalos a una dirección alojada en otro dominio que reciba de verdad.
¿Basta Null MX para impedir la suplantación?
No. Null MX cierra la recepción. SPF v=spf1 -all y DMARC p=reject tratan el envío suplantado; cada mecanismo responde a una dirección distinta.
¿Qué CAA publicar para un sitio sin correo?
Autoriza la CA que emite el certificado del sitio y añade un iodef externo si es posible. No publiques nunca issue ";" en ese sitio, porque bloquearías la renovación del certificado.
¿Qué CAA publicar para un dominio sin sitio?
Publica 0 issue ";" si no debe emitirse ningún certificado. En el análisis de CaptainDNS, esta opción vale 90 para el control CAA, y no 100.
¿Por qué la nota pública se queda en Bueno?
El análisis público mantiene DKIM y BIMI a cero con sus recomendaciones, aunque una indicación explique que aquí son inútiles. La vigilancia marcada los retira de su nota, pero no modifica el análisis público.
