Registros MX y DNS: cómo configurar email con tu dominio propio

Tener correo con dominio propio sigue siendo una de las cosas más importantes para cualquier empresa o marca. Nada dice «amateur» como enviar una propuesta comercial desde una cuenta de @gmail.com o @hotmail.com. Sin embargo, en mis visitas técnicas a PYMES en Bogotá y Caracas, me encuentro con el mismo problema: correos que no llegan, que caen en spam o que simplemente dejan de funcionar de un día para otro.

Cuando el correo falla, normalmente falla por una suma de detalles técnicos ignorados: registros MX mal puestos, falta de autenticación o cambios de DNS que nadie documentó. En esta guía vamos a profundizar en lo que realmente importa para que tu comunicación por email sea sólida en 2026.

El Registro MX: El cartero de tu dominio

El registro MX (Mail Exchanger) le dice al resto del mundo a qué servidor debe enviar los correos dirigidos a tu dominio. Parece sencillo, pero el error común es tener registros MX duplicados de diferentes proveedores (por ejemplo, tener restos de un hosting viejo junto a los de Google Workspace).

Regla de Gabo: Solo debe haber un conjunto de registros MX activo. Si te mudas de Microsoft 365 a Google, borra los registros antiguos de inmediato. La propagación DNS puede tardar, y tener basura en la zona DNS solo causa que algunos correos entren y otros se pierdan en el limbo digital.

La Tríada de la Entregabilidad: SPF, DKIM y DMARC

En 2026, los filtros de spam son implacables. Ya no basta con decir «este es mi servidor». Tienes que demostrarlo con criptografía y políticas claras. Si no tienes estos tres registros TXT bien configurados, tus correos tienen un 70% de probabilidad de ser rechazados por servidores grandes como Gmail o Outlook.

1. SPF (Sender Policy Framework)

Es una lista pública en tus DNS de las direcciones IP que tienen permiso para enviar correos a nombre de tu dominio.
– El error típico: Tener múltiples registros SPF. Solo debe haber uno. Si usas Google Workspace y además envías facturas desde Odoo, tu SPF debe incluir ambos: v=spf1 include:_spf.google.com include:mi-servidor-odoo.com ~all.

2. DKIM (DomainKeys Identified Mail)

Es como un sello de cera digital. Tu servidor firma cada correo con una clave privada, y el receptor usa una clave pública (que tú pusiste en un registro TXT de tu DNS) para verificar que el contenido no fue alterado en el camino. Sin DKIM, es muy fácil suplantar tu identidad (spoofing).

3. DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Este es el registro que le da órdenes al servidor que recibe tus correos. Le dice: «Si el SPF o el DKIM fallan, ¿qué quieres que haga con el mensaje?».
– p=none: Solo monitorea (ideal para empezar).
– p=quarantine: Mándalo a spam.
– p=reject: Recházalo totalmente.
En 2026, Google y Yahoo exigen al menos una política p=none para dominios que envían volumen de correo. No tener DMARC es, literalmente, decirle al mundo que no te importa la seguridad de tus comunicaciones.

Configuración para los grandes: Google Workspace y Microsoft 365

Si estás usando CDMON, GoDaddy o Namecheap, configurar estos servicios suele ser cuestión de usar sus plantillas automáticas. Pero si estás en un panel más manual (como los que solemos ver en infraestructuras locales en Venezuela), asegúrate de:
– Priorizar los MX (normalmente el principal tiene prioridad 1 o 10).
– No olvidar el TTL (Time To Live). Si vas a hacer una mudanza, baja el TTL a 300 segundos un día antes para que los cambios se propaguen rápido.

Gestión de DNS en entornos complejos

En mi experiencia como IT Manager, he visto que el problema no es solo técnico, es organizativo. Alguien cambia el registro A de la web y, sin querer, borra los registros TXT del correo.
– Consejo de Gabo: Usa servicios como Cloudflare para gestionar tus DNS. Te permite ver un historial de cambios, tiene una propagación casi instantánea y te avisa si hay registros en conflicto. Además, añade una capa de seguridad que oculta la IP real de tu servidor de correo, protegiéndote de ataques directos.

Conclusión: Menos dolores de cabeza, más profesionalismo

Si tus registros MX, SPF, DKIM y DMARC están bien puestos, tu dominio se ve más serio, tus correos llegan a la bandeja de entrada y reduces los riesgos de seguridad. No dejes la salud de tu comunicación empresarial al azar. Tómate el tiempo de auditar tus DNS hoy mismo. Tu marca y tu soporte técnico te lo agradecerán.

Cómo detectar rápido si el problema es DNS o del proveedor

Una de las situaciones más comunes en soporte es que el usuario diga «el correo no sirve» sin saber si el problema está en la salida, en la entrada o en una autenticación rota. Mi primera reacción nunca es tocar registros de inmediato. Primero separo el problema:

• ¿No entra correo desde fuera?
• ¿No sale correo hacia ciertos dominios?
• ¿Todo cae en spam?
• ¿Solo falla desde una aplicación o desde todos los clientes?

Con esas cuatro preguntas ya puedes descartar la mitad de los errores típicos. Si solo falla salida, probablemente estás frente a SPF/DKIM/DMARC o reputación. Si falla entrada, suele haber un problema de MX, prioridad o propagación. Si todo parece intermitente, casi siempre hay registros viejos coexistiendo o TTL demasiado alto combinado con cambios recientes.

Herramientas básicas que uso para validar

• dig o nslookup para revisar qué responde el dominio.
• MXToolbox para validar rápidamente MX, SPF, DKIM, DMARC y reputación.
• Gmail u Outlook para leer encabezados completos y ver por qué un mensaje fue rechazado o enviado a spam.
• Cloudflare o el panel DNS para revisar si alguien movió algo sin documentarlo.

Ese flujo ahorra muchísimo tiempo porque evita entrar en pánico por síntomas que en realidad son normales durante una propagación DNS o una política nueva de seguridad.

Buenas prácticas para dominios empresariales en 2026

Hoy no basta con «que mande y reciba». También importa trazabilidad, seguridad y delegación correcta. Si el dominio forma parte de una empresa, yo recomiendo:

1. Tener control del DNS en una cuenta corporativa y no personal.
2. Documentar cada cambio importante con fecha, motivo y responsable.
3. Mantener una política DMARC aunque sea inicialmente en p=none.
4. Revisar periódicamente si siguen existiendo servicios autorizados en SPF que ya no deberían enviar.
5. Evitar tocar la zona DNS en horarios críticos sin respaldo de la configuración anterior.

Parece burocracia, pero cuando una empresa depende del correo para ventas, soporte o facturación, esos controles dejan de ser opcionales.

Errores que sigo viendo y que cuestan caro

El más común sigue siendo tener dos proveedores conviviendo sin querer. Por ejemplo: migraron a Microsoft 365, pero dejaron restos de Google Workspace. O montaron un servidor de aplicaciones que envía correos, pero jamás lo agregaron al SPF. Otro clásico es activar DMARC en modo agresivo sin haber validado antes DKIM, y terminar bloqueando correos legítimos del propio negocio.

Mi recomendación práctica es sencilla: cambia una cosa a la vez, valida, documenta y luego sigues. El correo corporativo parece un tema pequeño hasta que deja de funcionar. Allí uno descubre rápido lo crítico que realmente era.

Mi recomendación final para pequeñas empresas

Si una empresa solo se lleva una idea de este tema, que sea esta: el correo corporativo no se deja en piloto automático. Hay que revisarlo, documentarlo y entender quién está autorizado a enviar en nombre del dominio. Esa pequeña disciplina evita pérdidas de reputación, mensajes extraviados y mucho soporte correctivo después.

En compañías pequeñas conviene además centralizar la gestión DNS, limitar quién toca la zona y mantener una copia simple de la configuración vigente. Parece exagerado hasta que algo se rompe y nadie sabe qué se cambió.

El correo sigue siendo una pieza crítica del negocio. Y como toda pieza crítica, necesita una base técnica seria y no solo «que hoy parece estar funcionando».

Cierre práctico

Algo que intento transmitir siempre en este tipo de artículos es que la tecnología mejora mucho cuando se aterriza a decisiones concretas. No basta con conocer la teoría, la lista de herramientas o el nombre correcto de cada componente. Lo que realmente marca diferencia es tener un criterio de implementación, un pequeño checklist y la disciplina de validar antes de dar algo por cerrado.

En soporte, infraestructura y operaciones web, los problemas más costosos casi nunca vienen de conceptos imposibles. Vienen de detalles básicos ignorados: falta de documentación, cambios sin prueba, configuraciones hechas con apuro o herramientas usadas sin entender bien su impacto. Por eso mi enfoque sigue siendo tan práctico. Prefiero una solución clara, estable y mantenible antes que una idea muy vistosa que después nadie pueda sostener.

Si este tema te toca de cerca, mi recomendación es simple: toma estas ideas, adáptalas a tu realidad y conviértelas en proceso. Cuando una buena práctica deja de depender de la memoria y pasa a formar parte de tu forma de trabajar, los resultados cambian muchísimo.

Artículo original (2010). Actualizado y expandido en 2026 para reflejar las nuevas exigencias de seguridad de los proveedores de correo global.