Digamos que una consultora de nueve personas nos escribe porque sus propuestas dejaron de llegar. No cambiaron nada, insisten. El correo corre en Zoho, el dominio está en un registrador que alguien configuró hace años, y en la zona DNS hay un único registro TXT que empieza con v=spf1 y todavía menciona al hosting que dejaron atrás. Zoho no firma nada, porque nadie creó nunca un selector DKIM. Gmail está haciendo exactamente lo que tiene publicado que va a hacer.
Zoho Mail es una opción sensata para una pyme, y te entrega en la Consola de administración todos los controles de autenticación que necesitas. Lo que no hace es activarlos por ti. Esta es la configuración que dejamos en un dominio con Zoho, en el orden en que la hacemos, con las tres fallas que más nos encontramos en el camino.
Empieza por la zona que de verdad lee internet
Antes de tocar un registro confirmamos a dónde apuntan los nameservers del dominio. Un cliente de Zoho suele tener tres paneles de DNS plausibles: el registrador, el hosting web y algún CDN que agregaron después. Solo uno es el autoritativo, y los registros que agregues en los otros dos se ven perfectos y no hacen absolutamente nada. Revisa los nameservers y edita únicamente ahí.
Lo segundo que revisamos es en qué centro de datos de Zoho vive la organización. Zoho opera centros de datos regionales separados, y los registros cambian entre uno y otro. Zoho documenta que el dominio de nivel superior del host MX varía según el centro de datos, y que los valores de DKIM y SPF generados para cada uno son distintos. La sección de Herramientas y configuraciones de la Consola de administración muestra los valores correctos para tu cuenta. Cópialos de ahí, no de un artículo, incluido este.
Primero los MX, y la prioridad que gana en silencio
La autenticación solo importa cuando la entrega ya funciona, así que el enrutamiento va primero. Zoho publica tres hosts de entrada, mx.zoho.com, mx2.zoho.com y mx3.zoho.com, con números de prioridad ascendentes, y el sufijo que corresponde a tu centro de datos aparece en la consola.
Tipo: MX Host: @ Valor: mx.zoho.com Prioridad: 10
Tipo: MX Host: @ Valor: mx2.zoho.com Prioridad: 20
Tipo: MX Host: @ Valor: mx3.zoho.com Prioridad: 50
Aquí la falla son los restos. La guía de Zoho es directa: si sobrevive otro registro MX con un número de prioridad más bajo, por ejemplo 0 o 5, el correo no llega a Zoho. Gana el número menor. Borra todos los MX del proveedor anterior en lugar de dejar uno por si acaso, porque ese "por si acaso" es justo a donde se va el correo.
SPF: un solo registro, y el valor que te da la consola
SPF declara qué servidores pueden enviar en nombre de tu dominio. La documentación de la Consola de administración de Zoho da el valor para Zoho Mail como un único registro TXT en la raíz del dominio.
Tipo: TXT Host: @ Valor: v=spf1 include:zohomail.com ~all
Zoho también documenta una forma más amplia. Si la empresa usa otros productos de Zoho que envían correo, incluir zoho.com cubre los servicios de envío de Zoho en conjunto y no solo Zoho Mail. Elige una de las dos, no las dos.
La regla que rompe más dominios que ninguna otra: un dominio lleva un solo registro SPF. Zoho lo dice sin rodeos, que cada dominio debe tener un único registro SPF que cubra todos los servidores desde los que envía, y que publicar varios registros TXT de tipo SPF interrumpe la entrega. No es una rareza de Zoho. El RFC 7208 define ese comportamiento, y un servidor que encuentra dos políticas trata el resultado como error permanente, es decir que no aplica ninguna. Si ya existe un registro, lo extiendes. No agregas un segundo.
Entonces un dominio con casillas en Zoho y una plataforma de tienda enviando confirmaciones de pedido queda con un solo registro fusionado, con los mecanismos en el medio y un único ~all al final:
v=spf1 include:zohomail.com include:tuplataforma.example ~all
Mientras fusionas, cuida la cuenta. SPF permite un número limitado de consultas DNS por evaluación, y cada include gasta de ese presupuesto. Si te pasas, el registro falla con error permanente aunque se lea perfecto. Contamos cómo volver por debajo del límite en la guía de consultas DNS de SPF.
DKIM: Zoho no firma hasta que creas un selector
Este es el paso que los equipos pequeños se saltan, porque SPF ya se sintió como la parte difícil y el correo parece funcionar igual. Funciona hasta que un receptor decide ponerse estricto, o hasta que alguien reenvía un mensaje y SPF deja de servir.
En la Consola de administración entra a Dominios, elige el dominio, ve a la pestaña Configuración de correo y selecciona DKIM. Agrega un selector, ponle nombre y elige una longitud de clave de 1024 o 2048 bits. Zoho genera el valor TXT y lo muestra junto al selector que creaste.
Publícalo en DNS como un registro TXT cuyo host sigue el formato estándar de selector:
Tipo: TXT
Host: s1._domainkey
Valor: v=DKIM1; k=rsa; p=MIIBIjANBgkq... (el valor completo de la consola)
Dos detalles deciden si esto funciona. El host es <selector>._domainkey seguido de tu dominio, y casi todos los editores de DNS agregan el dominio por ti, así que pegar el nombre completo crea un registro un nivel más abajo que nadie va a leer nunca. Y el valor de la clave pública es largo. Cópialo entero, sin saltos de línea que el pegado haya metido de más.
Después vuelve a la Consola de administración y verifica el selector ahí. Zoho no empieza a firmar hasta que lo hagas, y el registro puede tardar unas horas en propagarse antes de que la verificación funcione. Publicar el registro y olvidarse es la versión de esto que falla en silencio.
Los que envían y no son Zoho
Cuando el dominio de las casillas ya está limpio, inventariamos todo lo demás que envía con la misma dirección de origen. En una pyme típica esa lista es más larga de lo que el dueño espera: la plataforma de facturación, el CRM, el formulario del sitio, la herramienta de citas, el sistema del contador, a veces un escáner o una impresora en la esquina.
Cada uno tiene que estar autorizado en SPF, firmando con DKIM, o mudado a un subdominio propio. Cualquier cosa que envíe como tu dominio sin una de esas tres es un mensaje que falla la autenticación, y en cuanto endureces la política DMARC es un mensaje que desaparece.
Zoho Campaigns lleva sus propios registros
Los equipos asumen que autenticar Zoho Mail cubre el resto de la suite. No es así. Zoho Campaigns tiene su propio flujo de autenticación de dominio: agregas el dominio remitente, copias los registros TXT de SPF y DKIM que genera Campaigns, los publicas en DNS y verificas dentro de Campaigns. Vive en Configuración, en Administrar remitentes debajo de Entregabilidad, y las direcciones remitentes se verifican por correo de confirmación como parte del mismo proceso.
Esto importa más allá de marcar una casilla, y la razón es la alineación. DMARC no pregunta solo si SPF o DKIM pasaron. Pregunta si el dominio que pasó coincide con el dominio que tus destinatarios ven en el remitente. El correo de marketing enviado por una plataforma que firma con su propio dominio pasa DKIM y aun así falla DMARC, y los reportes agregados son el único lugar donde te vas a enterar.
DMARC, y leer de verdad lo que regresa
DMARC amarra los dos anteriores y le dice al receptor qué hacer cuando ninguno alinea. Zoho genera el registro por ti: en la misma pestaña de Configuración de correo elige DMARC, define la acción para las fallas y da una dirección donde recibir los reportes agregados. Hay un botón de regenerar para cambiarlo después, y el registro generado igual tienes que publicarlo tú en tu DNS.
Tipo: TXT Host: _dmarc
Valor: v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com
Arranca en p=none. No cambia nada en la entrega y pone los reportes a fluir, que es todo el objetivo de las primeras dos semanas. Zoho también los muestra dentro de la Consola de administración, en Reportes, en la sección de Cumplimiento, donde la vista de DMARC desglosa qué mensajes pasaron y cuáles fallaron SPF, DKIM y DMARC.
Esos reportes son XML, y el primero es genuinamente incómodo de leer. Desarmamos uno línea por línea en la guía de reportes agregados. Solo cuando cada remitente legítimo de esos reportes está alineado endurecemos la política, y lo hacemos por etapas y no de un salto, que es un proceso con su propio cuidado.
Por qué el plan gratis igual necesita los tres
El plan gratuito de Zoho es lo que atrae a muchas pymes, y viene con límites reales. El acceso es por webmail y las apps móviles, con IMAP, POP y ActiveSync reservados a los planes de pago, junto con cosas como el enrutamiento de correo y el inicio de sesión único.
La autenticación no está en esa lista, y no podría estarlo. SPF, DKIM y DMARC son registros de tu zona DNS, que es tuya pagues lo que pagues en Zoho. Al lado receptor tampoco le consta ni le importa en qué plan estás. Las directrices publicadas de Google para remitentes piden que todo el que envía configure SPF o DKIM, que mantenga la tasa de spam reportada en Postmaster Tools por debajo del 0.3 por ciento, y que el dominio del remitente alinee con el dominio de SPF o el de DKIM. Quienes envían más de 5,000 mensajes al día a Gmail tienen que llevar los tres desde el 1 de febrero de 2024, con una política DMARC que puede ser tan suave como p=none.
Una empresa de diez personas que manda cotizaciones y facturas no está ni cerca de 5,000 al día. Tampoco está exenta del filtrado, y quien envía poco volumen tiene menos historial de reputación en el cual apoyarse, no más. Tres registros DNS son el trabajo de entregabilidad más barato que existe.
Cuándo Zoho deja de ser lo adecuado
No somos religiosos con la plataforma, y parte de un trabajo honesto es decir cuándo la herramienta es el problema. Los puntos de presión de siempre son los clientes de escritorio y los equipos viejos que necesitan IMAP, los calendarios y archivos compartidos cuando el equipo ya superó el compartir improvisado, y los controles de administración cuando la empresa empieza a preocuparse por gestión de dispositivos y retención. Si esas son las restricciones, la conversación es sobre Google Workspace y no sobre otro registro DNS, y la migración es un proyecto aparte con su propio plan de corte.
Si nada de eso aplica, un dominio en Zoho bien autenticado entrega perfectamente, y cambiar de plataforma no arreglaría nada que los tres registros de arriba no arreglen.
Cómo ayuda Guanacos Tech
Hacemos esto de punta a punta para empresas pequeñas y medianas en Norteamérica y Latinoamérica: auditar la zona, arreglar el enrutamiento, publicar y verificar los tres registros, encontrar a los remitentes que nadie recordaba, y luego leer unas semanas de reportes DMARC antes de mover la política a modo estricto. Si tu correo de Zoho está cayendo en spam y prefieres no adivinar, pasa tu dominio por las revisiones de arriba, o agenda una llamada y lo vemos contigo. Más sobre el trabajo completo en entregabilidad de correo.
Fuentes
- Zoho Mail Admin Console Help: SPF configuration
- Zoho Mail Admin Console Help: DKIM configuration
- Zoho Mail Admin Console Help: DMARC policy
- Zoho Mail Admin Console Help: DMARC reports
- Zoho Mail Admin Console Help: Configure email delivery (MX records)
- Zoho Campaigns Help: Steps to authenticate your sender domain
- Zoho Mail: pricing and edition comparison
- Gmail Help: Email sender guidelines
- RFC 7208: Sender Policy Framework (SPF), Version 1
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)